Josh Evans 談論了 Netflix 微服務的混亂而多彩的世界，從最基礎的知識開始——微服務的剖析、與分散式系統相關的挑戰及其好處。在此基礎上，他探索了掌握微服務的文化、架構和營運實踐。
與操作漂移不同，引入服務國際化的新語言和容器等新技術是有意識的決定，會增加環境的新複雜性。我的營運團隊對Netflix 的最佳技術路線圖進行了標準化，該路線圖已融入基於Java 和EC2 的預定義最佳實踐，但隨著業務的成長，開發人員開始添加新元件，例如Python、Ruby 、Node-JS 和Docker。
我非常自豪，我們是第一個倡導我們的產品無需等待客戶投訴即可正常運作的公司。一切一開始都很簡單 - 我們有 Python 中的操作程序和 Ruby 中的一些後台應用程序，但是當我們的 Web 開發人員宣布他們將放棄 JVM 並要移動 Web 時，事情變得更加有趣應用程序到Node軟體平台.js。引入 Docker 後，事情變得更加複雜。我們遵循邏輯，當我們為客戶實施這些技術時，我們提出的技術就變成了現實，因為它們很有意義。我會告訴你為什麼會這樣。
API Gateway 實際上能夠整合出色的腳本，這些腳本可以充當 UI 開發人員的端點。他們以這樣的方式轉換每個腳本，在進行更改後，他們可以將它們部署到生產環境，然後部署到用戶設備，並且所有這些更改都與 API 網關中運行的端點同步。
然而，這又重複了創建新整體的問題，其中 API 服務代碼超載，導致各種故障場景。例如，某些端點被刪除，或者腳本隨機產生了太多版本，以至於這些版本佔用了 API 服務的所有可用記憶體。
將這些端點從 API 服務中拉出是合乎邏輯的。為此，我們建立了在 Docker 容器中作為小型應用程式運行的 Node.js 元件。這使我們能夠隔離這些節點應用程式引起的任何問題和崩潰。
這些改變的成本相當大，由以下因素組成：
- 生產力工具。管理新技術需要新工具，因為 UI 團隊使用非常好的腳本來建立高效的模型，不必花太多時間管理基礎架構，他們只需編寫腳本並檢查其功能。
機會洞察與排序 - 一個重要的例子是發現績效驅動資訊所需的新工具。有必要了解處理器的佔用情況、記憶體的使用情況，並且收集這些資訊需要不同的工具。 - 基礎鏡像的碎片化－簡單的基礎 AMI 變得更加碎片化和專業化。
- 節點管理。目前沒有現成的架構或技術可讓您管理雲端中的節點，因此我們建置了 Titus，這是一個容器管理平台，可提供可擴展且可靠的容器部署以及與 Amazon AWS 的雲端整合。
- 庫或平台的重複。提供具有與平台相同核心功能的新技術需要將其複製到基於雲端的 Node.js 開發人員工具中。
- 學習曲線和行業經驗。新技術的引入不可避免地會帶來新的挑戰，必須克服這些挑戰並從中學習。
因此，我們不能將自己限制在一條「鋪好的道路」上，而必須不斷尋找新的方法來推進我們的技術。為了降低成本，我們限制了集中支持，並將重點放在 JVM、新節點和 Docker 上。我們優先考慮有效影響，告知團隊其決策的成本，並鼓勵他們尋找方法來重複使用他們已經開發的高影響力解決方案。我們在將服務翻譯成外語以向國際客戶提供產品時使用了這種方法。例如相對簡單的客戶端程式庫，可以自動生成，因此建立Python版本、Ruby版本、Java版本等相當容易。
我們不斷尋找機會使用已在一個地方和其他類似情況下證明了自己的成熟技術。
讓我們談談最後一個元素——變化或變化。看看我們產品的消耗量在一周中的每一天和一天中的每個小時的變化如何不均勻。可以說，上午 9 點是 Netflix 最困難的時間，此時系統負載達到最大。
如何才能實現軟體創新的高速實施，即不斷對系統進行新的更改，而不造成服務交付的中斷，也不給客戶帶來不便？ Netflix 透過使用 Spinnaker（一個新的基於雲端的全球管理和持續交付 (CD) 平台）實現了這一目標。
至關重要的是，Spinnaker 旨在整合我們的最佳實踐，以便當我們將元件部署到生產中時，我們可以將輸出直接整合到我們的媒體交付技術中。
我們已經能夠將兩種我們高度重視的技術納入我們的交付管道中：自動化金絲雀分析和分階段部署。金絲雀分析意味著我們將一小部分流量引導到新版本的程式碼，並將其餘的生產流量通過舊版本。然後我們檢查新程式碼如何處理任務——比現有程式碼更好或更差。
交錯部署意味著如果一個區域的部署出現問題，我們會轉向另一個區域的部署。在這種情況下，上述檢查清單必須包含在生產管道中。如果您有興趣深入研究這個主題，我會節省您一些時間，並建議您查看我之前的演講《在雲端工程全球 Netflix 營運》。可以透過幻燈片底部的連結查看演講的視訊記錄。
演講的最後我會簡單講一下Netflix的組織和架構。一開始我們有一個名為 Electronic Delivery 的方案，這是 NRDP 1.x 媒體串流的第一個版本。這裡可以使用術語“反向流”，因為最初用戶只能下載內容以便稍後在裝置上播放。 Netflix 的第一個數位交付平台早在 2009 年就看起來像這樣。
用戶設備包含 Netflix 應用程序，該應用程式由 UI 介面、安全模組、服務啟動和播放組成，基於 NRDP 平台 - Netflix Ready Device Platform。
當時的使用者介面非常簡單。它包含所謂的 Queque Reader，用戶可以訪問該網站向 Queque 添加內容，然後在其設備上查看添加的內容。正面的一面是，前端團隊和後端團隊屬於同一個電子交付組織，並且有著密切的工作關係。有效負載是基於 XML 建立的。同時，針對 DVD 業務創建了 Netflix API，鼓勵第三方應用程式將流量引導至我們的服務。
然而，Netflix API 已經做好了充分準備，可以幫助我們提供創新的用戶界面，其中包含所有內容的元數據、有關可用電影的信息，從而創建了生成觀看列表的功能。它有一個基於 JSON 模式的通用 REST API、HTTP 回應程式碼（與現代架構中使用的相同）以及 OAuth 安全模型，這是當時前端應用程式所需要的。這使得從串流內容交付的公共模型轉向私有模型成為可能。
過渡的問題是碎片化，因為現在我們的系統基於完全不同的操作原理運行兩種服務 - 一種基於 Rest、JSON 和 OAuth，另一種基於 RPC、XML 和基於 NTBA 令牌系統的用戶安全機制。這是第一個混合架構。
我們兩個團隊之間本質上存在防火牆，因為最初 API 與 NCCP 的擴展性不太好，這導致了團隊之間的摩擦。差異在於服務、協定、電路、安全模組，開發人員經常必須在完全不同的上下文之間切換。
對此，我與該公司的一位高級工程師進行了交談，我向他提出了一個問題：「正確的長期架構應該是什麼？」他反問：「你可能更關心關於組織後果——如果我們整合這些東西，而它們破壞了我們已經學會做好的事情，會發生什麼事？這種方法與康威定律非常相關：“設計系統的組織受到複製該組織通信結構的設計的限制。”這是一個非常抽象的定義，所以我更喜歡一個更具體的定義：“任何軟體都反映了創建它的組織結構。”這是我最喜歡的 Eric Raymond 的一句話：“如果你有四個開發團隊在開發一個編譯器，那麼你最終會得到一個四遍編譯器。”嗯，Netflix 有一個四遍編譯器，這就是我們的工作方式。
我們可以說，在這種情況下，尾巴在搖狗。我們的首要任務不是解決方案，而是組織；是組織驅動我們擁有的架構。漸漸地，我們從服務的大雜燴轉向了我們稱之為 Blade Runner 的架構，因為這裡我們談論的是邊緣服務以及 NCCP 能夠分離並直接集成到 Zuul 代理、API 網關以及相應功能中的能力。 “碎片”已轉變為具有更先進的安全性、重播、資料排序等功能的新微服務。
因此，可以說，部門結構和公司動態在塑造系統設計方面發揮重要作用，是促進或阻礙變革的因素。微服務架構是複雜而有機的，其健康基於紀律並引入了混亂。
有點廣告
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com