您是否有兴趣了解我们如何举办 ORCID 注册表和 API? 想知道我们如何在发生灾难时处理高可用性、可扩展性和恢复? 如果是这样,那么这篇文章是给你的!
我们每月处理 XNUMX 万网页浏览量 ORCID Registry,但我们的大部分流量都在 API 上,目前每个月的点击量超过 100 亿次。 我们的核心战略之一是投资开发强大的信息基础设施,因此我们需要确信我们用来支持这种使用的技术是可靠和安全的。
登记处和网站的其余部分 orcid.org 通过内容交付网络 (CDN) 进行路由——这是一个在全球拥有 150 多个数据中心的云服务提供商。 当您的浏览器连接到 orcid.org,站点的静态部分由您附近的本地数据中心提供,以实现更快的加载时间。
CDN 还有一些其他有用的功能,例如防止 分布式拒绝服务 (DDoS) 攻击,以及针对黑客威胁的实时安全扫描。
Registry 页面托管在我们的主数据中心,其中流量在一组应用服务器之间进行负载平衡,而 Registry 数据存储在加密文件系统上的三个强大的数据库服务器的集群中。 一个是主数据库,在其中进行更新,两个是副本服务器,它们实时接收数据的副本。 副本服务器用于注册表和 API 的大部分“读取”操作,但也是热备用服务器,这意味着它们可以在发生故障时提升为主服务器。
我们有各种各样的其他服务器来支持生产系统,这些服务器会混合数据以构建搜索索引,在不同的数据中心保持最新的公共数据转储,并运行计划任务,例如电子邮件提醒。
我们每天自动备份数据库两次,加密转储,并将其推送到不同大陆的另一个云服务提供商,以便在我们的主数据中心发生灾难时,我们可以使用数据库备份来恢复系统。 我们使用临时离线服务器定期测试此过程是否正常工作。
这是一个坚实的基础。 然而, ORCiD 不断增长,我们越来越依赖于研究信息基础设施的一部分。 因此,我们需要做更多工作以确保社区能够继续依赖我们。
我们希望改进什么?
我们希望在多个位置拥有应用服务器和数据库副本,这样我们就不必依赖有些冗长的数据库恢复过程,或者自上次备份以来丢失数据。 我们希望能够在几分钟内而不是几小时内配置新服务器,以防需求突然增加。
我们正在考虑将系统中最关键的部分(例如注册、登录和授权)分离到一个隔离系统,并且还希望确保公共 API 流量问题不会影响 Registry 和 Member API。
我们想要一个更灵活的架构,使用行业标准技术,例如 Docker容器 和 Kubernetes,这将有助于我们进行上述改进。
让我们知道您对我们计划的看法! 我们如何与您自己的组织和您依赖的其他服务进行比较? 我们可以或应该做的还有更多吗? 根据您自己的经验,您对我们有什么建议吗? 联系我们 与您的意见和反馈!