您是否有興趣了解我們如何舉辦 ORCID 註冊表和 API? 想知道我們如何處理災難發生時的高可用性、可擴展性和恢復? 如果是這樣,那麼這篇文章適合您!
我們每月處理 XNUMX 萬次頁面瀏覽量 ORCID 註冊中心,但我們的大部分流量來自 API,目前每月的點擊量超過 100 億次。 我們的核心戰略之一是投資開發強大的信息基礎設施,因此我們需要確信我們用於支持這種使用的技術是可靠和安全的。
登記處和網站的其餘部分位於 orcid.org 通過內容交付網絡 (CDN) 進行路由,CDN 是一家在全球擁有 150 多個數據中心的雲服務提供商。 當您的瀏覽器連接到 orcid.org,網站的靜態部分由您附近的本地數據中心提供服務,以實現更快的加載時間。
CDN 還有一些其他有用的功能,例如防止 分佈式拒絕服務 (DDoS) 攻擊,以及針對黑客威脅的實時安全掃描。
註冊表頁面託管在我們的主數據中心,其中流量在應用程序服務器集群之間進行負載平衡,而註冊表數據存儲在加密文件系統上的三個強大數據庫服務器的集群中。 一個是主數據庫,在其中進行更新,兩個是副本服務器,實時接收數據的副本。 副本服務器用於註冊表和 API 的大部分“讀取”操作,但也是熱備用服務器,這意味著在發生故障時它們可以提升為主服務器。
我們有各種各樣的其他服務器支持生產系統,它們會整理數據以構建搜索索引,在不同的數據中心保存最新的公共數據轉儲,並運行電子郵件提醒等計劃任務。
我們每天自動備份數據庫兩次,加密轉儲,並將其推送到不同大陸的另一個雲服務提供商,以便在我們的主數據中心發生災難時,我們可以使用數據庫備份來恢復系統。 我們定期使用臨時離線服務器測試此過程是否正常運行。
這是一個堅實的基礎。 然而, ORCiD 不斷發展,我們作為研究信息基礎設施的一部分越來越受到依賴。 因此,我們需要採取更多措施來確保社區能夠繼續依賴我們。
我們想改進什麼?
我們希望在多個位置擁有應用程序服務器和數據庫副本,這樣我們就不必依賴有點冗長的數據庫恢復過程,也不必丟失自上次備份以來的數據。 我們希望能夠在幾分鐘而不是幾小時內配置新服務器,以防需求突然增加。
我們正在考慮將系統中最關鍵的部分(例如註冊、登錄和授權)分離到一個獨立的系統中,並且還希望確保公共 API 流量問題不會影響註冊中心和會員 API。
我們想要一個使用行業標準技術的更靈活的架構,例如 Docker容器 和 Kubernetes,這將有助於我們做出上述的改進。
讓我們知道您對我們計劃的看法! 我們與您自己的組織和您依賴的其他服務相比如何? 我們還可以或應該做更多的事情嗎? 根據您的親身經歷,您對我們有什麼建議嗎? 聯絡我們 與您的意見和反饋!