33、利用微服务构建可扩展的数字图书馆摄入管道

利用微服务构建可扩展的数字图书馆摄入管道

1. 引言

在日常生活的诸多方面,聚合器都发挥着重要作用,从报纸、旅游网站到电影评论和社交网络服务。在不断发展的学术交流环境中,由于每年发表的科学知识数量庞大,以及学者们对发现和提取其中知识的需求,大量聚合器应运而生。此外,科学向跨学科的转变也催生了对一种无缝工具的需求,这种工具能够实现从不同学科领域检索科学文献。

聚合器可以收集、丰富和清理元数据,以协调对它们的访问,允许在各种平台上进行统一搜索,提高内容的可见性,并通过展示科学的新趋势和发展,为最终用户带来高级的发现体验。由于其作用,聚合器必须能够处理大量数据,并在可扩展和可持续的基础设施上进行开发。

以 CORE 项目为例,它是一个全球采集服务,聚合了数百万篇开放获取的研究论文。过去,CORE 的采集基础设施采用的是单体架构。尽管可以进行扩展和继续使用,但该架构存在复杂性和维护问题,尤其是在处理大量数据时,其组件之间的强依赖性也对其可持续性构成了挑战。为了重构当前系统并使其更易于扩展,引入了微服务架构,即由小型、自主的组件在大型基础设施中协同工作。这种技术由于软件和资源的进步而得到广泛应用,其好处是程序员可以高效地专注于单个简短任务的组件实现。

本文的主要贡献包括:
- 定义设计可扩展聚合基础设施的要求。
- 根据这些要求,提出一种基于微服务的设计,可应用于任何聚合和数字图书馆基础设施。
- 描述在 CORE 项目的实际场景中,从单体架构迁移到微服务架构的经验。

2. 相关工作

聚合系统的设计通常需要从头开始,因为每个项目的应用场景各不相同,这取决于资源的可用性和分布的灵活性。目前已经有许多架构解决方案,有些针对特定用例,有些则致力于解决缺乏可重用基础设施的问题。

  • OpenAIRE 项目的 D - NET 组件基础设施 :使用开放存档倡议元数据采集协议(OAI - PMH)进行采集,将采集的元数据转换为 XML 文件,创建图模型信息结构。但其主要目标是连接出版物、数据集存储库和当前研究信息系统,主要关注元数据的收集和丰富,而 CORE 则同时关注元数据页面的爬取和全文发现。
  • SHARE 项目 :其管道和使用的技术与本文描述的过程有主要相似之处,例如使用 RabbitMQ 作为消息系统和 Celery 调度器,通过 ElasticSearch 索引使内容可搜索。但该架构不提供用于爬取和丰富全文文档的工具。
  • BASE 项目 :另一个元数据聚合器,通过 OAI - PMH 端点采集数据,并通过 SOLR 索引使元数据可搜索。
  • 商业解决方案 :如 Google Scholar 和 Microsoft Academic Graph,使用搜索引擎爬取功能识别全文并进行索引,但它们限制了用户对原始数据的访问粒度。
  • CiteSeerX :一个元数据和全文采集服务,定义了一个可扩展系统的三个组件:采集器、文档存档和搜索界面。该系统通过水平镜像服务器和位置来解决可扩展性问题。

这些项目都描述了可扩展的架构,但没有具体说明从单体架构向微服务架构的过渡。而且 CORE 的情况独特,它将元数据采集、全文爬取和丰富功能结合在同一基础设施中,而其他项目的架构大多侧重于聚合和丰富元数据。此外,之前的工作没有从采集和丰富内容的聚合角度提及可扩展性,仅从前端可用性方面描述了可扩展性方法。

3. 实际场景:CORE

CORE 从世界各地采集开放获取(OA)期刊和存储库(包括机构和学科)的内容,为用户提供数百万篇 OA 研究论文的无缝访问。OA 内容是指以数字形式在线提供、免费且大部分不受版权限制的内容。随着 OA 运动的逐渐发展,可用的科学信息量也在增加。截至 2017 年 3 月,CORE 从 6000 种 OA 期刊和 2437 个存储库中采集内容,提供 7000 万条元数据记录和超过 600 万篇全文 PDF 的访问。

CORE 通过三种访问级别提供内容,展示了原始数据、科学论文和集合的整体结构,满足了不同研究利益相关者的需求,包括文本挖掘者、数字图书馆、开发者、研究人员、学生、普通公众、资助者和存储库管理者。

为了收集元数据,CORE 使用 OAI - PMH 协议,大多数元数据采用都柏林核心模式进行格式化,同时也支持其他标准,如元数据编码和传输标准、RIOXX 元数据应用配置文件和 OpenAIRE 文献存储库指南。

CORE 不仅是一个元数据聚合服务,还扩展到聚合和缓存全文。为了解决缺乏统一的全文采集标准的问题,CORE 建立了一套方法并遵循多种程序:
- 识别元数据记录中的全文链接。
- 从在线资源进行爬取以获取特定论文的链接。
- 通过分析数据提供者的结构,使用识别出的模式组合全文链接。
- 采用其他自定义方法,检查特定内容提供者的机器可读结构。

直到最近,CORE 一直采用单体架构。尽管它能够同时处理多个存储库,但采集管道围绕每个存储库进行集中管理。多年来,为了改进采集过程、应对技术进步问题以及集成新服务,应用了各种自定义解决方案。然而,代码的积累和高耦合性使得管理变得困难,需要不断进行修复,这也影响了系统的性能和服务质量。此外,公共服务与采集基础设施的强耦合导致在采集过程中系统过载时,会直接影响服务的整体可用性。

4. 摄入管道

CORE 的摄入管道目前由五个任务组成,原则上可以扩展到更多任务。这个过程可以描述为一个管道,类似于 UNIX 操作系统中引入的概念,并在软件架构模型中得到扩展。每个任务执行特定的操作,其结果构成了 CORE 集合中包含元数据和全文的完整记录。具体任务如下:
1. 元数据下载
- 提取 :将期刊或存储库(以下简称“存储库”)的元数据下载并提取到 CORE 数据库中进行本地存储。
- 清理 :对数据进行清理,如对作者姓名进行规范化处理,并在各种支持的标准之间对数据进行标准化和规范化。
2. 全文下载 :CORE 下载并在其数据库中缓存下载的全文。
3. 信息提取
- 文本提取 :为了实现全文搜索,对下载的 PDF 进行分析,将全文提取到文本文件中。
- 语言检测 :为高级搜索提供过滤选项。
- 引用提取 :CORE 交叉匹配引用的论文是否可用,如果可用则将两篇论文进行链接;如果不可用,则通过 CrossRef 服务获取引用论文的数字对象标识符(DOI)。
4. 丰富
- 重复检测 :CORE 检测重复记录并在数据库中标记这些文件。
- 相关内容识别 :使用信息检索程序,匹配语义相关的论文。CORE 的推荐器(用于存储库和开放期刊系统的插件)高度依赖此任务。
5. 索引 :这是摄入管道的最后一步,增强了搜索功能,同时支持 CORE API 和 CORE 数据集的使用。

5. 可扩展基础设施要求

从实际用例中抽象出一组通用要求,可用于任何聚合或数字图书馆场景。这些要求基于通用分布式系统,并针对遵循特定工作流程且需要与多个外部服务交互的系统进行了扩展:
- 易于维护 :解决方案应易于管理,代码应便于维护、修复和改进。
- 高度自动化 :应能够实现完全自动化的采集过程,同时允许手动交互。
- 快速失败 :管道中的项目应在任务执行后立即进行验证,而不是在管道末尾进行单一的最终验证,以便尽早发现问题并通知程序员。
- 易于故障排除 :代码中的可能错误应易于识别。
- 分布式和可扩展 :系统中添加新节点应允许扩展,且具有透明性和可复制性。
- 无单点故障 :单个崩溃不应影响整个摄入管道,任务应独立工作。
- 高可用性 :包含公共服务的基础设施不应与采集管道绑定,应始终可用。
- 可恢复 :当采集任务因手动或故障停止时,系统应能够自动恢复并继续执行任务。

6. CORE 采集系统(CHARS)

CHARS 的架构设计基于以下主要组件:
1. Worker(Wi) :一个独立的应用程序,能够执行特定任务并通过队列进行通信。
2. 任务协调器(调度器) :在任务开始或结束时激活,协调系统中的任务工作流程。
3. 队列处理系统(Qn) :一个消息系统,协助组件之间的通信。
4. Cron 调度器 :定期排列任务。
5. 采集端点(监督器) :一个 API 端点,便于在系统中提交任务,作为新采集请求的入口点。

所有 Worker 在接收到任务后共享相同的生命周期,如下表所示:
| Item | Description |
| ---- | ---- |
| 0 | 通知开始 |
| 1 | 收集执行任务所需的数据 |
| 2 | 执行任务 |
| 3 | 完成执行并收集指标 |
| 4 | 评估结果(成功或失败) |
| 5 | 通知结束 |

事件调度器决定任务的执行顺序,并选择摄入管道中的下一个任务。如果系统中有足够的空闲 Worker,调度器将根据以下策略添加新的采集任务:首先,将元数据记录超过一定时间窗口的存储库添加到队列中;其次,如果没有其他优先级任务,则添加新的存储库。这样做的目标是高效利用所有可用资源,避免系统过载。为了保持集合内容的新鲜度,会定期重新采集存储库并添加新的存储库,而不会干扰现有程序。

通信基础设施通过发布/订阅模式实现。能够执行元数据下载任务的 Worker 对元数据下载概念表示兴趣,当生产者提交消息时,Worker 将收到通知并采取行动。消息是在组件之间传输的项目,如任务定义或开始/结束事件。当 CORE 工作人员希望采集存储库时,只需在管理控制台中点击按钮,向采集端点发送消息,任务将被创建并提交到队列系统。

以下是 CHARS 架构的 mermaid 流程图:

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(Worker):::process --> B(Queue Handling System):::process
    C(Task Coordinator):::process --> B
    D(Cron Scheduler):::process --> C
    E(Harvesting endpoint):::process --> B
    B --> A
7. CHARS 的实现

在选择用于实现 CHARS 的软件和工具时,考虑了两个要求:即开箱即用的解决方案和易于与现有系统集成。

采用迭代方法实现 CHARS:
- 第一次迭代 :引入新架构,并尽量减少对现有代码库的更改。
- 第二次迭代 :专注于修改采集管道,将一些任务(如信息提取、丰富和索引)从存储库级别转移到文章级别,从而增加了系统的并行深度。
- 第三次迭代 :详细研究每个任务的机制,调查可能存在的低效问题。

基础设施的核心使用 Java 和 Spring 框架编写,但系统同样支持使用多种不同技术来实现 Worker。系统的持久状态已经使用 MySQL 和 ElasticSearch 实现,并从旧基础设施中直接迁移过来,因为它们已经满足了需求。

基础设施通过 SupervisorD 软件进行构建和管理,该软件能够在 Worker 失败时重新启动它们,并允许定义基于事件的操作。SupervisorD 为每台服务器使用静态配置,这意味着可以根据服务器的硬件规格定义在单台服务器上运行的 Worker 数量。作为 SupervisorD 的替代方案,还探索了使用 Docker 和 Kubernetes 采用基于容器的微服务的可能性。基于容器的方法可以实现可重用的微服务,并根据可用资源对 Worker 进行动态和细粒度的管理,但缺点是其配置和使用会增加基础设施的复杂性。最终决定在 CHARS 基础设施的未来迭代中再采用基于容器的微服务方法。

8. 排队系统

对于队列消息系统,考虑了 RabbitMQ 和 Kafka 两种解决方案。尽管 Kafka 在消息速率方面具有更优的性能,但它提供的开箱即用功能较少。由于实际用例不需要每秒处理数百万条消息的系统,因此选择了 RabbitMQ,它比 Kafka 更易于配置,并且可以与现有基础设施和代码库集成。此外,RabbitMQ 还提供了对消息优先级的开箱即用支持,这在采集过程中非常必要,因为经常会收到数据提供者重新采集存储库集合的请求,以捕获记录更新、元数据和全文。在修复和解决技术采集问题时,也需要多次重新采集存储库并跳过现有队列。

利用微服务构建可扩展的数字图书馆摄入管道

9. 总结与展望

通过采用微服务架构,成功地将 CORE 的采集系统从单体架构迁移到了更具可扩展性和分布式的架构。这种转变解决了原有单体架构中存在的复杂性、维护困难以及扩展性不足等问题,为 CORE 的未来发展奠定了坚实的基础。

在实现 CHARS 的过程中,遵循了一系列的设计原则和要求,确保了系统的高可用性、可维护性和可扩展性。例如,通过定义通用的可扩展基础设施要求,使得系统能够适应不断变化的业务需求;采用迭代的开发方法,逐步优化系统的性能和功能;选择合适的软件和工具,如 RabbitMQ 作为队列消息系统,提高了系统的效率和灵活性。

未来,随着科学研究的不断发展和开放获取运动的持续推进,CORE 将面临更多的挑战和机遇。为了更好地应对这些挑战,进一步提升系统的性能和功能,有以下几个方面的工作值得开展:
- 深入优化系统性能 :虽然目前已经通过引入微服务架构和优化采集管道提高了系统的性能,但仍然可以进一步挖掘潜力。例如,对每个任务的执行时间进行详细分析,找出性能瓶颈并进行针对性优化;探索更高效的数据存储和处理方式,提高数据的读写速度和处理能力。
- 拓展功能和服务 :除了现有的元数据采集、全文下载、信息提取、丰富和索引等功能,还可以考虑拓展更多的服务。例如,提供更智能的推荐服务,根据用户的历史行为和偏好,为用户推荐相关的研究论文;开发数据分析工具,帮助用户深入挖掘数据价值,发现科学研究的趋势和热点。
- 加强数据安全和隐私保护 :随着数据量的不断增加和用户对数据安全和隐私的关注度不断提高,加强数据安全和隐私保护至关重要。可以采用先进的加密技术对数据进行加密存储和传输,建立严格的访问控制机制,确保只有授权用户能够访问敏感数据。
- 持续改进系统架构 :技术在不断发展,新的架构和技术不断涌现。为了保持系统的竞争力,需要持续关注行业动态,及时引入新的架构和技术,对系统进行持续改进和升级。

10. 技术分析与关键路径总结

在整个系统的构建和优化过程中,涉及到了多个关键的技术点和操作步骤,下面对这些技术点和关键路径进行总结和分析。

技术点分析
- 微服务架构 :将系统拆分为多个小型、自主的组件,每个组件专注于单一的业务功能,通过轻量级的通信机制进行协作。这种架构提高了系统的可扩展性、可维护性和灵活性,使得各个组件可以独立开发、部署和扩展。
- OAI - PMH 协议 :用于采集元数据的标准协议,被广泛应用于学术资源的共享和交换。通过该协议,CORE 能够从各种期刊和存储库中高效地采集元数据。
- RabbitMQ 消息系统 :作为队列消息系统,提供了可靠的消息传递机制,支持消息的发布/订阅模式和消息优先级。在 CHARS 中,RabbitMQ 用于协调各个组件之间的通信,确保任务的有序执行。
- Java 和 Spring 框架 :作为基础设施的核心技术,Java 提供了强大的面向对象编程能力和丰富的类库,Spring 框架则简化了企业级应用的开发,提高了开发效率和代码的可维护性。
- MySQL 和 ElasticSearch :MySQL 用于存储系统的持久化数据,如元数据和全文记录;ElasticSearch 则作为全文搜索引擎,提供了高效的搜索功能,支持对海量数据的快速检索。

关键路径总结
1. 需求分析和架构设计 :明确系统的功能需求和性能要求,设计基于微服务的架构,定义各个组件的职责和接口。
2. 采集管道设计和实现 :根据摄入管道的任务划分,实现元数据下载、全文下载、信息提取、丰富和索引等功能,确保数据的准确采集和处理。
3. 系统组件开发和集成 :使用 Java 和 Spring 框架开发各个微服务组件,通过 RabbitMQ 实现组件之间的通信和协作,将各个组件集成到一个完整的系统中。
4. 系统测试和优化 :对系统进行全面的测试,包括功能测试、性能测试、安全测试等,发现并解决系统中存在的问题,对系统进行优化,提高系统的性能和稳定性。
5. 上线部署和持续维护 :将系统部署到生产环境中,进行上线运行,并对系统进行持续的监控和维护,及时处理系统中出现的问题,确保系统的正常运行。

11. 操作步骤和流程说明

为了帮助读者更好地理解系统的操作过程,下面详细介绍一些关键操作的步骤和流程。

元数据采集流程
1. 配置采集任务 :在管理控制台中配置需要采集的期刊和存储库信息,包括 OAI - PMH 端点地址、采集频率等。
2. 提交采集请求 :点击管理控制台中的按钮,向采集端点发送采集请求,任务将被创建并提交到队列系统。
3. 任务调度和分配 :任务协调器根据系统资源和任务优先级,将采集任务分配给空闲的 Worker。
4. 元数据下载和清理 :Worker 接收到任务后,根据配置信息从指定的 OAI - PMH 端点下载元数据,并对数据进行清理和标准化处理。
5. 数据存储 :将处理后的元数据存储到 MySQL 数据库中。

全文下载流程
1. 识别全文链接 :在元数据记录中识别全文链接,或者通过爬取技术从在线资源中获取全文链接。
2. 下载全文 :根据全文链接下载论文的全文,并将其存储到本地文件系统或数据库中。
3. 缓存管理 :定期清理过期的全文缓存,释放存储空间。

信息提取流程
1. 文本提取 :对下载的 PDF 文件进行分析,提取其中的全文文本。
2. 语言检测 :检测提取的文本的语言,为后续的搜索和过滤提供支持。
3. 引用提取 :交叉匹配引用的论文,建立论文之间的引用关系。

以下是一个简化的元数据采集流程的 mermaid 流程图:

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(配置采集任务):::process --> B(提交采集请求):::process
    B --> C(任务调度和分配):::process
    C --> D(元数据下载和清理):::process
    D --> E(数据存储):::process
12. 总结与启示

通过对整个系统的构建和优化过程的介绍,我们可以得到以下几点总结和启示:
- 架构设计的重要性 :合理的架构设计是系统成功的关键。在设计系统时,需要充分考虑系统的可扩展性、可维护性和灵活性,选择合适的架构模式和技术栈。
- 技术选型的谨慎性 :在选择技术和工具时,需要综合考虑技术的成熟度、性能、功能和易用性等因素,确保所选技术能够满足系统的需求。
- 迭代开发的优势 :采用迭代的开发方法,逐步推进项目的进展,可以及时发现和解决问题,降低项目风险,提高开发效率。
- 持续优化的必要性 :系统的性能和功能不是一蹴而就的,需要持续进行优化和改进。通过不断地分析和优化系统,才能满足用户不断变化的需求。

总之,利用微服务构建可扩展的数字图书馆摄入管道是一个复杂而又具有挑战性的任务。通过合理的架构设计、先进的技术选型、迭代的开发方法和持续的优化改进,可以构建出一个高效、稳定、可扩展的系统,为学术研究和知识传播提供有力的支持。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值