# 構建全球分布式，關鍵任務應用程序：Trenches 第 2 部分的經驗教訓 > 原文： [http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html](http://highscalability.com/blog/2015/9/2/building-globally-distributed-mission-critical-applications.html)  *這是 [Kris Beevers](https://www.linkedin.com/pub/kris-beevers/4/a5/113) 的創始人和首席執行官， [NSONE](https://nsone.net/) 的來賓帖子的第二部分，下一代智能 DNS 和流量管理平臺的提供者。 這是[第 1 部分](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html)。* ## 集成和功能測試至關重要 在每一個現代軟件開發課程中，單元測試都受到重創。 這是一個好習慣。 無論您是進行測試驅動的開發，還是只是敲出代碼，如果沒有單元測試，您都無法確保一段代碼能夠達到預期的效果，除非您仔細進行測試，并確保這些測試隨著代碼的發展而不斷通過 。 在分布式應用程序中，即使您擁有世界上最好的單元測試范圍，您的系統也會崩潰。 **單元測試還不夠**。 您需要**測試子系統**之間的交互。 如果特定的配置數據發生變化，該怎么辦–對子系統 A 與子系統 B 的通信有何影響？ 如果您更改了消息格式該怎么辦–生成和處理這些消息的所有子系統是否繼續互相通信？ 在最新代碼更改之后，依賴于四個不同后端子系統的結果的特定類型的請求是否仍會導致正確的響應？ 單元測試不能回答這些問題，而集成測試卻可以。 **在集成測試套件**中投入時間和精力，并在開發和部署過程的所有階段都建立了用于集成測試的過程。 理想情況下，始終在您的生產系統上運行集成測試。 ## 沒有服務中斷維護 如果您要構建一個真正的關鍵任務應用程序，那么您的客戶將依靠它來經營自己的業務，那么就沒有關閉開關了。 它永遠不會停止工作。 您永遠不會有服務中斷維護。 **即使最復雜的后端體系結構更改也必須毫不夸張地進行**。 這是您應該**認真思考架構**的原因之一。 數小時的白板可以節省數月的工作量。 一個例子：在 NSONE，我們很幸運地從一開始就掌握了大部分架構。 **一開始我們沒有做對的事情：我們接受平臺中的高頻數據輸入，這會影響我們如何使用復雜的流量管理配置來回答對 DNS 記錄的查詢。** 數據饋送可以應用于多個 DNS 記錄，因此，服務器負載遙測的饋送可以通知與服務器上托管的多個網站有關的流量路由決策。 我們假設您只會將單個數據 Feed 真正連接到一些 DNS 記錄。 因此，我們通過將進入系統的數據饋送擴展為多條消息（每個連接的 DNS 記錄一條消息）并將其推送到我們的邊緣位置，從而節省了一些時間和精力。 我們錯誤地假設了，一些我們最喜歡的客戶將數據源連接到了數千個 DNS 記錄！ 我們早期的懶惰使我們不得不內部進行 DoS，我們知道隨著我們的不斷發展，這種情況只會變得越來越糟。 問題：我們不能僅僅通過發送更少的控制消息來回溯并解決問題。 我們需要更改數據模型和消息傳遞模型，以及 4-5 個交互的始終在線系統。 在**初期需要花費 2-3 個小時的額外思考和精力才能變成為期六周的**馬拉松：集思廣益，深度復雜的重構，大量的正確性測試工作以及一系列精心協調的部署和遷移， 所有人都可以在不中斷服務的情況下解決該問題。 雖然這是極端情況，但**新基礎架構或代碼的每個部署都必須無縫**：精心計劃，滾動重啟，持續集成測試。 為客戶提供服務后，就不會關閉。 ## 極其小心地自動化部署和配置管理 現代化的 devops 生態系統充斥著用于部署自動化和配置管理的工具：Chef，Puppet，Ansible，SaltStack，Terraform，以及似乎更多的東西。 您所使用的工具并不像您想的那么重要–閱讀并確定哪種模型對您有意義。 但是**重要的是您正在使用這些工具**。 即使在公司的早期階段，即使看起來更快或更容易，也不要手工管理您的配置或部署：您會犯錯誤，限制擴展能力，并且將很難進行擴展 以中等規模將自動化改造為移動目標。 但！ 注意：強大的力量帶來巨大的責任。 **部署自動化工具使您可以像其他任何東西一樣**在頭腦中射擊平臺。 使用 Chef 管理所有主機的 iptables 規則？ **一個疲憊的 devops 工程師和一個按鈕操作都可以全局禁用您的平臺**。 推出一個新功能，您保證您在登臺環境中上下左右測試過嗎？ 當您遇到現實流量與模擬流量之間的細微差別時，端到端的自動化部署將使您的產品死光。 明智地使用自動化。 我們使用 **Ansible 管理 NSONE 的配置和部署。 這是一個很棒的工具，具有很多怪癖。** 我們可以自動完成所有操作，并且只需按一下按鈕就可以將新的 DNS 傳遞代碼推送到我們的所有邊緣位置，但是我們絕對不會這樣做。 **我們從最低流量到最高流量按設施推出部署設施。 在一個設施內，我們逐臺服務器甚至逐個核心部署，在此過程的每一步都運行全面的功能測試套件。** 在我們研究指標時，有時可能會影響性能，有時甚至是數小時或數天，然后才轉移到更關鍵的設施上。 在開始部署之前，我們就簽署了全面的代碼審查，不僅是針對我們的應用程序代碼，還包括我們的 Ansible 手冊和配置。 建立適合您的團隊和應用程序的流程，但不要忘記，盡管自動化可以使您快速成長，但也可能使您快速死亡。 ## 進行消防演習 壞事發生了。 每個科技公司都會使服務器發生故障。 自從我們啟動 NSONE **以來，我們已經經歷了各種可以想象到的服務器故障**：磁盤故障，NIC 故障，RAM 損壞，內核崩潰，虛擬環境中嘈雜的鄰居副作用以及兩者之間的一切。 服務器故障很容易發生。 電源將熄滅。 還記得桑迪颶風嗎？ 在 NSONE 目前在曼哈頓下城的辦公室的對面，技術人員正在用柴油在桶中爬樓梯，以保持基礎設施在線。 光纖將被切斷。 BGP 將被劫持。 您將獲得 DoSed，其復雜程度各不相同：從腳本小子從其父母的地下室發送 64k ICMP 數據包到全面的 DNS 和 NTP 反射放大攻擊，每秒可以以數百萬或數億個數據包的速率對您的基礎設施進行 DDoS 處理。 你會怎么做？ **正確的唯一方法是練習。 在壞事情發生之前進行模擬。** Netflix 的 Chaos Monkey 是一個著名的例子。 您不一定總能直接模擬各種事件，但會盡力模擬響應。 這是確保時機成熟時唯一的方法，您可以保持鎮定，使用已安裝的工具并在困難的情況下有效地做出反應。 ## 最小化表面積 隨著您的應用程序分布范圍越來越廣，除非采取謹慎的預防措施，否則遭受惡意攻擊的表面積將急劇增加。 **鎖定您的系統，并最小化暴露給 Internet 的攻擊面。** **體系結構中的每個角色應僅將其提供的服務公開給需要訪問這些服務的系統集。** 您的面向 Internet 的系統應該向您的用戶公開您提供的服務，而別無其他。 在后端，您的系統應盡可能在私有 IP 空間上相互交互，并且在不可行的情況下（例如，跨遠程設施進行通信），數據應流經加密通道。 無論是通過 AWS 安全組之類的提供程序工具，通過 iptables 規則的自動管理，使用路由器 ACL 或硬件防火墻，還是其他某種機制，都可以積極使用防火墻。 **首先拒絕，然后按角色允許特定流量。** **切勿允許操作員通過 ssh 等直接訪問生產系統。** 人們應該通過高度鎖定的堡壘主機進入您的基礎架構，并使用多因素身份驗證，端口敲門，IP 白名單以及其他相當嚴苛的安全策略。 確保您的堡壘主機分布在不同的網絡和地理位置。 進入其余生產基礎架構的操作應僅限于從堡壘主機發起的會話。 有上百萬種策略用于鎖定系統。 我已經介紹了一些我們發現有效的做法，但絕非詳盡無遺。 閱讀并從一開始就考慮安全性：它是體系結構的一部分。 隨著系統擴展，不要浪費時間以節省時間。 ## 了解提供商的情況 幾乎每個現代科技公司都在 AWS，DigitalOcean 或其他一些合理的低成本，低障礙的云基礎架構提供商上構建其產品的第一個版本。 互聯網在 AWS 之前就已經存在，并且基礎設施提供商的多樣性在過去十年中已經擴大。 **大多數公司在擴展規模時都不會急于放棄 AWS。 但是每個公司都應盡可能保留可選性**。 您可能會發現，應用程序中的特定工作負載最好由裸機處理，或者您需要在澳大利亞擁有高吞吐量的 CDN，或者您在沒有 AWS 的情況下在市場上擁有關鍵的一組用戶。 花一些時間來熟悉基礎架構生態系統的各個方面：IaaS 提供程序，托管，DNS，CDN，監視等等。 在早期考慮架構時，有個想法，可能隨著流量的增長和平臺的擴展而需要在哪里尋找。 **準備快速移動**。 在 NSONE，我們運營著一個復雜的全球任播 DNS 交付網絡。 在進行原型設計時，AWS 很有意義，但是在啟動平臺之前，由于網絡需求，我們不得不搬到其他地方。 建立一個具有競爭優勢的任播 DNS 網絡（針對世界一流的可靠性和性能進行調整），很大程度上取決于我們在復雜的托管和運營商環境中的導航能力，推動基礎架構和網絡提供商支持我們所需的控制深度的能力。 在許多情況下，我們對提供者進行了教育，并幫助他們建立了我們需要利用的功能。 **不要忘記：基礎架構運營商也是極客，他們經常對新想法和挑戰持開放態度。** 了解生態系統并參與其中。 ## 總結 我經歷了很多課程，我們學習了構建和擴展分布式，關鍵任務系統的經驗。 從一開始，您將永遠不會把所有事情都做好，但是您可以讓自己處于一個良好的位置，以便隨著公司的發展而優雅而有效地做出反應。 受眾是全球性的。 應用程序交付也緊隨其后，任何建立在線資源的新公司都應考慮如何以分布式方式進行架構和擴展，以向其用戶提供最高質量的服務，從而最大限度地提高性能，可靠性和安全性。 *如果您錯過了這篇文章的第一部分，那么[這是第 1 部分](http://highscalability.com/blog/2015/8/31/building-globally-distributed-mission-critical-applications.html)。*