# 構建全球分布式，關鍵任務應用程序：Trenches 部分的經驗教訓 1 > 原文： [http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html)  *這是 [Kris Beevers](https://www.linkedin.com/pub/kris-beevers/4/a5/113) 的創始人和首席執行官， [NSONE](https://nsone.net/) 的來賓帖子的第 1 部分，下一代智能 DNS 和流量管理平臺的提供者。 這是[第 2 部分](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html)。* 每家科技公司都考慮到這一點：隨著業務的增長，擴展其應用程序和系統是不可避免的（實際上是令人羨慕的）挑戰。 **您如何從一開始就考慮擴展規模，并在不進行過早優化的情況下使公司處于良好的地位？** 在以后咬你之前，有哪些值得考慮的關鍵挑戰？ 當您構建關鍵任務技術時，這些是基本問題。 在構建分布式基礎架構時，無論是可靠性還是性能，或者兩者兼而有之，它們都是很難回答的問題。 部署正確的體系結構和流程將使您的系統和公司能夠抵御分布式，高流量應用面臨的常見問題。 這使您能夠超越擴展限制，管理不可避免的網絡和系統故障，保持冷靜并實時調試生產問題，并成功地發展公司和產品。 ## 這是誰？ 我長期以來一直在構建遍布全球的大型應用程序。 在第一次互聯網泡沫時期，我堅持了一年的大學課程，并為一個文件共享創業公司建立了后端基礎架構，該公司成長為數百萬用戶-直到 RIAA 的律師們大吃一驚并將我們打包回到宿舍 。 公司倒閉了，但我卻迷上了規模。 最近，在 Internap 于 2011 年收購的互聯網基礎架構提供商 Voxel 上，我建立了許多大型 Web 公司使用的全球互聯網基礎架構–我們建立了全球分布式公共云，裸機即服務，內容交付 網絡等等。 我們學到了很多擴展課程，并且很難學到它們。 現在，我們在 NSONE 上建立了下一代智能 DNS 和流量管理平臺，該平臺今天為 Internet 上一些最大的屬性提供服務，其中包括許多本身就是關鍵任務服務提供商的公司。 這是真正分布在全球的關鍵任務基礎架構，在我們構建和擴展 NSONE 平臺時，我們在 Voxel 上學到的經驗為我們提供了很好的服務-并一次又一次得到了加強。 現在該分享一些我們所學的知識，并且很幸運，也許您可??以在自己的應用程序中應用這些課程中的一些–而不是艱難地學習它們！ ## 架構優先 編寫代碼時，總是很想集中精力使其變得緊湊和高效，最大限度地減少內存和 CPU 消耗，最大程度地提高軟件的“深度”。 停下來。 在現代的，分布廣泛的系統中，擴展限制幾乎不受系統的垂直“深度”和特定角色內的代碼優化（尤其是早期）的驅動。 相反，它們是管理交互系統之間的通信以及體系結構中每個角色的水平可伸縮性。 **不要優化您的代碼，請優化您的架構。** [微服務](https://en.wikipedia.org/wiki/Microservices) 是個好主意。 它們使應用程序中的獨立角色脫鉤，并使您能夠獨立擴展每個角色或層。 **在擔心深度之前，計劃水平擴展角色。 服務器既便宜又便宜，而且總是越來越便宜。 開發人員時間不是。** 因此，您可以隨時進行水平縮放，而僅在找到真正重要的地方時才擔心代碼優化。 在編寫一行代碼之前，請花時間考慮一下您的體系結構。 繪制圖表，考慮通信和數據約束，并制定計劃。 ## 從角色上考慮您的系統 微服務架構或多或少意味著您正在構建一個由解耦系統組成的應用程序，每個系統都解決一個特定的問題或扮演特定的角色。 但是值得重復的是，您應該以這種方式考慮您的體系結構。 b 不僅因為它**消除了擴展約束，還因為它影響了您開發代碼，部署系統和擴展基礎結構的方式**。 由相互分離，相互通信的角色組成的應用程序可以作為進程，VM 或容器并置放置在單個服務器上。 這使您可以在本地開發環境，小型登臺系統和大型生產基礎架構中部署應用程序。 **隨著應用程序生產基礎架構的發展以及流量和用戶的擴展，您可以剝離需要專用系統或系統集群的角色。** 。但是，在您的 MVP 中，您可以將成本降到最低，并且仍然可以通過并置生產角色來進行擴展。 我們在 NSONE 上發布的最早的 alpha 版本托管在 AWS 中的一個單播 t2.small 實例上。 如今，我們具有與開始時基本相同的角色和子系統集（此后又添加了更多的角色和子系統），我們的生產基礎架構跨越全球各大洲的數百臺服務器和近 30 個不同的生產設施（南極洲除外-抱歉 伙計們）。 隨著我們的成長，我們將關鍵子系統剝離到了它們自己的服務器或群集，并在需要的地方增加了廣度和冗余性。 ## 跨全球分布式系統的通信非常困難 構建和擴展由子系統組成的應用程序是一回事，這些子系統最初并置在單個服務器上，最終并置在單個數據中心中。 完全解決多數據中心應用交付難題是另一回事。 子系統需要在 LAN 外部進行通信時，該通信的可靠性將大大降低，您不僅需要針對服務器故障，而且還要針對通信故障進行周密的計劃。 Internet 上的連接脆弱且不可預測。 在 NSONE，我們設計架構的前提是我們的邊緣 DNS 交付設施將經常失去與核心設施的連接。 在非洲，巴西和印度等困難的市場中，情況尤其如此。 但是我們還需要確保在恢復通信后快速重新收斂。 仔細考慮命令和控制消息傳遞以及消息排隊是關鍵。 對于不同的通信模式，以不同的方式考慮設施間通信也很重要。 **如果要將延遲敏感的關鍵命令和控制消息推送到一個或多個設備，則可能需要查看功能強大的消息隊列系統**（例如，我們大量使用 RabbitMQ）。 如果要將非關鍵遙測回運到儀表板系統，則**可能會考慮減輕重量，但對網絡拆分的影響較小**。 如果您要推送需要在所有交付位置之間緊密同步的持久性應用程序數據，則值得一看。 在設施之間移動鉆頭時，請使用正確的工具完成正確的工作。 ## 一致性哈希是同步&分片的殺手 tool 是時候考慮水平縮放了。 您有一堆子系統，它們都在本地和整個 Internet 上相互通信。 請求飛入您的系統，需要在可以有效地為它們服務的后端節點之間分配，并且您需要一種最大化“請求位置”的方法。 不能期望您所有具有特定角色的服務器都能滿足任何請求，這可能是因為必需的數據不能全部存儲在一個盒子中的 RAM 中，或者您需要在服務器之間有效地分條存儲。 您如何確定水平層中的哪個節點應處理請求或任務？ 天真的，您可以預先配置請求路由：也許您有一個請求 ID，并且所有以 A-M 開頭的請求 ID 都被帶到一臺服務器，而以 N-Z 開頭到另一臺服務器。 那可能行得通，但是難以管理和擴展。 您可以將請求 ID 散列到服務器：類似 hash（id）mod N ，其中 N 是要跨越的服務器數量。 在您添加新服務器并且所有請求重新進行條帶化，破壞數據或緩存局部性并破壞系統之前，這種方法很有效。 您可以為分布式“協議”實施某種復雜的協商-您的各個子系統和服務器相互通信，以確定哪些請求應該發送到哪里-這是我經常看到的一種方法。 這很復雜，事情會破裂。 [一致性哈希](https://en.wikipedia.org/wiki/Consistent_hashing) 是一種強大的方式，使分布式系統無需進行實際通信就可以達成對請求到節點的映射等協議。 它易于實施，并且可以根據您的基礎架構進行適當擴展，從而最大程度地減少了在子系統中添加或刪除節點時的重新分段。 在具有許多交互角色的復雜體系結構中，策略性地使用一致的哈希來跨節點集對消息和請求進行條帶化可能是一個巨大的勝利。 在 NSONE，**我們以多種方式在整個堆棧中使用一致的哈希，例如將 DNS 查詢路由到特定的 CPU 內核以最大化緩存局部性，在不進行顯式通信的情況下協商監視節點的任務，跨層拆分大量數據饋送 聚合節點的數量，還有更多**。 ## 測量并監視所有內容 這是一條很常見的建議，似乎有些陳詞濫調，但它總是值得重復的。 **您沒有測量的內容，您無法理解**。 即使您遠未遇到嚴重的擴展挑戰，對系統行為及其交互的深入了解對于了解隨著增長將面臨的擴展約束也至關重要。 不只是收集系統指標。 **對您的應用程序進行檢測，以了解數據庫響應時間，消息傳遞延遲，高速緩存命中率，內存碎片，磁盤 I / O，以及可能使您洞悉系統性能的所有內容。** 繪制所有圖表，并建立對“名義”行為的基本理解。 如果發生異常情況（例如負載峰值，通信故障，子系統中出現某種異常情況），請回頭查看您的指標并了解事件的“特征”。 這將幫助您識別將來異常情況下正在發生的事情（同樣重要的是，排除不發生的事情）。 它會幫助您了解新型工作負載或其他流量何時給系統帶來了意料之外的壓力，因此您可以在子系統發生故障之前適當地調整架構或擴展子系統。 在 NSONE，**我們研究了指標。** 始終在顯示它們（我們的辦公室到處都是顯示 NOC 儀表板的監視器）。 當我們看到一些突如其來的東西時，我們會問為什么，并進行更深入的挖掘。 從這種方法中獲得的深刻理解意味著我們可以放心地滿足 Internet 上最大客戶的 DNS 和流量管理需求，因為我們知道我們的平臺將如何應對新的流量和工作量。 **與測量同樣重要的是監視**。 這是兩個不同的事物：我們進行測量以了解我們系統的行為，并且進行監視以檢測該行為中的異常。 在您的成長早期就進行監視和警報：它將幫助您了解重要的異常和無關緊要的異常。 您才剛剛開始，可能會錯過一些睡眠。 后來，隨著業務的增長，管理系統變得比馬拉松跑更像一場馬拉松，您將希望減少噪音，著眼于影響服務的異常情況，并對系統進行自動化和重新架構以將其最小化。 **從多個有利位置**進行監視-不僅在物理上（多個地理位置和網絡），而且在邏輯上。 在 NSONE，我們監視內部遙測中的異常情況，利用 Catchpoint 和 Raintank 等第三方服務進行外部監視，并通常利用各種數據源來觀察平臺和網絡事件。 同樣重要的是，**監視的不僅僅是系統**的“正常性”。 系統提供“優質”服務意味著什么？ 低延遲響應時間？ 高緩存命中率？ 監視那些指標并在它們超出范圍時發出警報。 *這是本文的[第 2 部分](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html)。* ## 相關文章 * [關于黑客新聞](https://news.ycombinator.com/item?id=10147420) 很棒的文章！ 我特別指出，內部遙測和外部監視之間存在差異。 這是我最近與一位近視的領導者失去的論點-他關閉了內部遙測系統以節省幾分錢。 但是自那以后，我離開了那家公司，我希望從長遠來看，這將使他們停機。