Netflix 是這樣構建微服務技術架構的

Netflix 是美國在線影片租賃商，曾利用超過 100 億次的用戶觀看紀錄分析觀眾喜好，製作出熱播劇集《紙牌屋》。Netflix 還是業界微服務和 DevOps 組織的楷模，有大規模生產級微服務的成功實踐。本文是作者多年研究 Netflix 技術資料的總結，可以認為是對 Netflix 微服務技術架構的一次全面系統的反向工程。

Netflix 大規模生產級微服務

微服務很多公司 (Amazon, eBay, BAT) 都有，甚至比 Netflix 做得更早，但 Netflix 大概是大規模生產級微服務做得最傑出的。

100s 範圍的微服務（2016 年的數據是超過 500 個），1000s 範圍的每日生產變更，10,000s 範圍的實例，1,000,000s 範圍的活躍客戶數，1,000,000,000s 範圍的度量指標。但是只有 10s 範圍的運維工程師，沒有自己的數據中心 NOC，應該算微服務和 DevOps 的最高境界了。

圖 1，Netflix 生態系統

圖 2，Netflix 運維工程師數量很少

圖 3，Netflix 微服務可視化

Netflix 微服務支撐技術大圖

我們可以通過三個宏觀視圖，全面理解 Netflix 微服務技術架構體系：

從下至上的分層視圖：

圖 4，分層技術體系（從下而上）

• 第 1 層：IaaS 層，計算，網路，負載均衡和存儲等服務，Netflix 沒有自己的數據中心，依賴 AWS 提供的 IaaS 服務。
• 第 2 層：PaaS 層，平台運行時服務，框架和庫，監控和可靠性，持續交付和大數據等服務。Netflix 平台團隊打造的 PaaS 平台，是支撐微服務的核心基礎設施。該層的大部分組件開源，統稱 NetflixOSS[附錄 1]。
• 第 3 層：應用和服務層，相當於業務能力交付層，各業務團隊在 PaaS 和 IaaS 平台基礎上構建面向內外客戶的微服務和應用。

從外到內的分層視圖：

圖 5，微服務分層視圖（從外而內）

• 第 0 層：端用戶設備層，瀏覽器，手持設備，智能電視，遊戲設備等等。據稱 Netflix 要支持超過 1000 種端用戶設備。
• 第 1 層：接入層，基於 AWS 的 ELB 接入用戶流量。
• 第 2 層：網關層，將外部請求反向路由到內部微服務，Netflix 使用自研 Zuul 網關。網關只負責跨橫切面功能（反向路由，安全，限流熔斷和日誌監控等），無業務邏輯。網關無狀態部署，依賴前端 ELB 做負載均衡。
• 第 3 層：聚合服務層，負責對後台微服務進行聚合裁減加工後暴露給前端設備，在 Netflix 的體系中，該層也稱邊界服務層 (Edge Service)，或者設備適配層。考慮到設備的多樣性和前端業務的多變性，Netflix 前端團隊大量使用 Groovy 腳本作為聚合層的主要開發語言，同時兼容 Java 又具有腳本易於變更特性。
• 第 4 層：後台基礎服務層，提供支持 Netflix 業務的核心領域服務（Playback, Member, Review ,Payment etc），在 Netflix 體系中，該層也稱為中間層服務 (Middle Tier Service)。
• 第 5 層：數據訪問層，提供對 Cassandra NoSql 數據存儲（Netflix 的主要數據持久化方式），後台服務 (Memcached, Zookeeper, S3, SQS 等) 和大數據等的訪問和工具支持。

另外：

1. 第 3 和第 4 層統稱為 Netflix 的微服務，總體實現 Netflix 業務能力輸出。
2. 所有微服務內部通過服務註冊表 Eureka 做自註冊和自發現，也就是說 Netflix 內部服務調用都是通過客戶端軟負載直連方式。網關 Zuul 也通過 Eureka 發現內部服務，將外部請求反向路由到內部服務，具體見後面的圖 [7]。
3. 所有微服務依賴縱向的平台支撐服務（平台運行時服務，框架和庫，監控和可靠性服務），以及第 5 層的後台服務和大數據服務等。
4. 所有服務之間的調用（包括網關調聚合服務，聚合服務調後台基礎服務，或後台服務相互調用）都置於依賴容錯組件 Hystrix 的保護之下，實現自動化的限制、熔斷、隔離和降級功能，防雪崩效應保障用戶體驗。

部署視圖：

圖 6，部署視圖

上圖 6 是 Netflix 微服務在一個 AWS Zone 中的簡化部署視圖，分析如下：

1. 應用和服務部署在 AWS 的虛擬機中，每個應用集成平台團隊提供的公共框架和庫（依賴注入 Governator，配置 Archaius，監控 Servo，服務框架伺服器端 Karyon 和客戶端 Ribbon，緩存 EvCache/ 消息 SQS/Cassandra Astyanax 等後台服務客戶端，熔斷 Hystrix 等等）。
2. 內部微服務通過 Eureka 做自註冊和自發現。外部流量通過 Zuul 網關接入並反向到內部微服務。
3. Netflix 的持久化存儲主要使用 Cassandra，緩存用 Memcached，日誌用 ElasticSearch，Metrics 用自研 Atlas 時間序列資料庫，數據匯流排採用 Kafka。
4. 代碼通過 Nebula 打成包，再通過 Aminator 打成 AMI 鏡像，最後使用 Asgard(升級版是 Spinnaker) 發布到 AWS 雲中。發布採用藍綠和金絲雀機制，每個發布至少要兩個發布組 ASG（Auto-Scaling Group）, 通過 Eureka 動態調撥流量做灰度測試。
5. 各種猴子（Chaos/Latency/Janitor/SecurityMonkey 等）可以對 Netflix 的服務進行隨機的抗脆弱測試和各種檢查。
6. Edda 支持對 AWS 雲資源進行變更監控，Ice 支持對 AWS 雲資源的使用成本進行監控。

公共運行時服務

下圖 7 是抽象後的 Netflix 微服務總體路由發現體系，服務可以簡化成前端邊界服務（Edge Services）和後端中間層服務（Middle Tier Services）兩層，Zuul 網關和 Eureka 註冊中心是支撐微服務路由發現的關鍵運行時服務。

服務路由發現體系

• Eureka：內部服務的自註冊自發現全部通過 Eureka，服務之間調用直連。Eureka 提供灰度能力，支持發布系統動態調撥流量做藍綠和灰度發布。
• Zuul：將外部流量反向路由到內部服務（也通過 Eureka 發現內部服務），同時兼做安全，限流熔斷，日誌監控等跨橫切面功能，也具備導流，壓側，在線調試，跨數據中心 HA 等高級功能。
• 另外，配置中心也屬於公共運行時服務，支持運行期動態配置和各種業務開關。Netflix 開源了配置中心的客戶端 Archaius，但是沒有開源內部的伺服器端。

框架和庫

為了讓業務團隊專註業務能力交付，Netflix 平台團隊提供統一的微服務框架和庫（見下圖 8），方便業務研發團隊集成底層 PaaS 和服務治理能力，包括：

圖 8，服務框架和庫

服務框架：

1. Karyon 是 Netflix 的服務容器，是對 Jax-rs 參考實現 Jersey 的一個封裝，集成了依賴注入 Governator，配置 Archaius，服務發現 Eureka，管理界面 Admin 和健康檢查 HealthCheck 等能力。Governator 是對 Google Guice 進行擴展的類庫，提供了 Classpath 掃描和自動綁定、生命周期管理、成員屬性驗證等功能。
2. RxJava 是 Netflix 的非同步化組件，可實現非同步和基於事件的微服務調用。
3. Hystrix 是 Netflix 的彈性容錯組件，大部分跨進程調用（服務間 /DB/ 緩存等）都置於 Hystrix 的保護下，實現熔斷 / 限流 / 隔離 / 降級等功能。Turbine 是和 Hystrix 配套的實時流聚合服務，配合 Hystrix Dashoard 可以對服務實時性能進行聚合展示。
4. Ribbon 是 Netflix 的服務調用客戶端，集成 Eureka 的服務發現能力，實現軟負載 SLB，可以採用不同路由策略（隨機 /RoundRobin/ 帶權重 / 甚至跨 AWS Zone HA）訪問目標服務。

數據訪問層：

1. Curator 是對 Zookeeper 底層 API 的進一步封裝，方便開發人員使用 ZK 的分散式協調能力。
2. EVCache 客戶端方便開發人員接入 Memcached 緩存，支持跨 AWS Zone 的 HA 能力。
3. Astyanax 是 Cassandra Java 客戶端，提供了更高層次的 API、客戶端故障轉移、連接池管理、自動重試及發現等功能，還包含常用 Cassandra 的數據模型。

監控和配置

1. Vector 是一個主機監控框架，可以將高精度的主機指標直接暴露在瀏覽器中，方便研發人員定位主機性能（內存 /CPU/ 網路 /OS 等）問題。
2. Servo 是 Metrics 客戶端組件，類似 Dropwizard Metrics，方便研發人員對各種業務 / 應用 / 系統的指標進行打點監控，監控類型包括測量 Gauges，計數器 Counters 和計時器 Timers。Servo 後台對接 Netflix 時間序列資料庫 Atlas。
3. Blitz4j 是 Netflix 對 log4j 的非同步化改造版，能夠減少爭用，在 Netflix 用於監控、商務智能和調試等眾多日誌場景。
4. Archaius 是 Netflix 集中式配置系統的客戶端，支持靈活多層級的動態配置，支持業務微服務按需調整運行期行為。

監控和可靠性工程

監控是微服務閉環治理的重要方面。Netflix 主要使用 Elasticsearch 棧進行日誌監控，日誌匯流排採用 Kafka。時間序列資料庫使用自研的 Atlas，以內存方式存儲時間序列，支持高速寫入和查詢。

除此以外，Netflix 自研工具 Edda 對 AWS 雲資源進行變更監控，工具 Ice 對 AWS 雲資源的使用成本進行監控。

為進一步提升微服務系統的可靠性，Netflix 提出抗脆弱架構理念，開發諸多猴子對生產系統進行隨機的抗脆弱測試，這些猴子統稱 Simian Army[圖 9]，包括：

圖 9，Simian Army

1. Chaos Monkey：可以隨機關閉生產環境中的實例，確保網站系統能夠經受故障的考驗，同時不會影響客戶的正常使用。
2. Latency Monkey：在 RESTful 服務的調用中人為引入延遲來模擬服務降級，測量上游服務是否會做出恰當響應。通過引入長時間延遲，還可以模擬節點甚至整個服務不可用。
3. Conformity Monkey：查找不符合最佳實踐的實例，並將其關閉。例如，如果某個實例不在自動伸縮組裡，那麼就將其關閉，讓服務所有者能重新讓其正常啟動。
4. Doctor Monkey：查找不健康實例的工具，除了運行在每個實例上的健康檢查，還會監控外部健康信號，一旦發現不健康實例就會將其移出服務組。
5. Janitor Monkey：查找不再需要的資源，將其回收，這能在一定程度上降低雲資源的浪費。
6. Security Monkey：這是 Conformity Monkey 的一個擴展，檢查系統的安全漏洞，同時也會保證 SSL 和 DRM 證書仍然有效。
7. 10-18 Monkey：運行本地化及國際化的配置檢查，確保不同地區、使用不同語言和字符集的用戶能正常使用 Netflix。
8. Chaos Gorilla：Chaos Monkey 的升級版，可以模擬整個 AWS Availability Zone 故障，以驗證在不影響用戶，且無需人工干預的情況下，能夠自動進行可用區的重新平衡。

持續交付

圖 10，Netflix 持續交付流水線

Netflix 具備強大的發布流水線（CD pipeline，圖 10），支持研發人員以自助（self-service）方式持續交付微服務，整個交付體系基於不可變基礎設施（immutable infrastructure）理念，簡化流程如下：

1. 開發人員使用 Karyon 服務框架開發微服務應用，將代碼提交到代碼倉庫。
2. 代碼經過 CI 持續構建流水線驗證後打成應用包（war 或 jar）。
3. 開發人員使用 Aminator 工具將應用包和基礎鏡像（Base AMI）打成可發布 AMI 鏡像，該過程也稱鏡像烘焙（Baking）。
4. 開發人員使用 Asgard（新版升級為 Spinnaker）發布系統在 AWS 雲中創建新發布組，啟動發布將鏡像推到雲中。服務實例啟動後自註冊到 Eureka 註冊中心，開發人員使用 Asgard 動態調撥流量做金絲雀（Canary Testing）測試，測試成功則拉入全部流量，失敗則退回之前版本。

關於 Netflix 微服務持續交付的更多細節，可參考其博文 。

Netflix 架構治理理念

上面介紹了很多 Netflix 微服務的技術架構和各種支持服務或組件，可以說是 Netflix 微服務架構的形，而其背後的無中心分散式架構治理理念，才是 Netflix 微服務架構的神，是我們架構師更加應該關注和領會的。下面是這些理念的總結：

1、讓具有上下文的團隊自己去做技術決策和試驗，以達成質量目標，要優於高度同質化一致性的系統。Local context and decision，微服務架構賦能團隊做民主自治的技術決策和創新。

2、創新和成長是軟體研發的非常重要的方面，控制、集中式計劃和對管理透明顯然是不佳的激勵方式。微服務架構主張分散式治理，有利於團隊的快速創新和成長。

3、快速開發和交付新功能，要優於完全沒有缺陷和問題再上到生產。當然這種快速交付能力有賴於完善的監控和靈活部署能力。

4、微服務架構的分散式治理方式難免引入一定的冗餘開發和降低重用度。但是為了達成最優客戶體驗和質量（贏得市場競爭優勢），適度的冗餘開發和低重用度是完全 OK 的。

5、微服務架構需要紮實的底層技術平台能力 (PaaS/IaaS) 的支撐。但是為了長期的技術棧適用性和領先，最初在框架、自動化和基礎設施抽象方面的高度投入是完全合理的。

寫在最後

1. 限於篇幅，大數據和安全部分沒有展開，它們也是 Netflix 微服務支撐技術的重要部分，可參考 Netflix 開源軟體中心 [附錄 1] 和其技術博客 [附錄 5] 了解更多細節。
2. 限於篇幅，分散式數據訪問層和跨數據中心 HA 等高級主題沒有講述，Netflix 在這些方面投入巨大，但是大部分技術組織還不到那個階段。
3. 作者並沒有在 Netflix 工作過，本文主要基於 Github, slideshare 和 Netflix techblog 資料的學習總結，有些理解可能是偏頗的。Netflix 技術本身也在快速的演進中，本文中的很多信息可能已經過時了，但是仍然有借鑒價值。
4. 微服務和 DevOps 在組織的落地，組織架構轉型和基礎技術平台是關鍵，兩條腿走路，不能偏廢。當然組織架構和技術平台都離不開人才密度這個根本。
5. 考慮到微服務和 DevOps 需要在底層基礎設施 (PaaS/IaaS) 的巨大投入（本文可見一斑），如果企業的業務和團隊規模還沒有達到一定的量，則要慎重考慮在微服務架構上的投入。初創企業重點應該放在驗證業務模式和謀活，以單塊應用架構起步更合理，等有一天業務團隊規模達到那個量，再考慮微服務架構不遲，Netflix 的微服務架構也是從單塊架構開始一路演化出來的。
6. Netflix 微服務技術架構只是一個參考樣板，NetflixOSS 中的產品也有很多其它開源產品可以替代，架構師可學習吸收 Netflix 微服務架構技術體系和理念，但不可盲從其技術，需根據企業實際情況定製自己的微服務支撐技術體系。
7. 作者後續仍將進一步細化詳解微服務支撐技術組件和開源實踐，讀者可以關注 Infoq 公眾號等待後續更新。

附錄

1. Netflix 開源軟體中心
2. How Netflix Thinks of DevOps
3. Mastering Chaos - A Netflix Guide to Microservices
4. An Inverse Evaluation of Netflix Architecture Using ATAM
5. Netflix 技術博客
6. Preparing the Netflix API for Deployment
7. Deploying the Netflix API
8. 企業的組織架構是如何影響技術架構的
9. 當技術為組織所累時怎麼辦？將你的組織架構旋轉 90 度！

推薦閱讀：