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

寫在前面

作者近期針對企業數字化和架構轉型思考後陸續寫了三篇文章，這篇是第三篇，主題專注微服務和 DevOps 支撐技術，以 Netflix 技術棧為例。第一篇稱為《企業的組織架構是如何影響技術架構的》[附錄 8]，主題是建立背景上下文 (background)。第二篇稱為《將你的組織架構旋轉 90 度》[附錄 9]，主題專注組織架構轉型。

為啥前面要花兩篇講組織架構背景和轉型？因為微服務和 DevOps 在本質上需要組織架構轉型 (Re-org)，組織架構對了，技術架構才能落地下來。如不考慮組織架構，直接切入技術架構（很多架構師的通病），則失敗風險巨大。

為啥要以 Netflix 技術為例？因為 Netflix 是業界微服務和 DevOps 組織的楷模，有大規模生產級微服務的成功實踐。而且其技術棧大部分開源，模組化抽象好，整個體系是一個樣板。相關技術資料也豐富，可以從其公司的 techblog 或者 slideshare 上直接獲得。本文是作者多年研究 Netflix 技術資料的總結，可以認為是對 Netflix 微服務技術架構的一次全面系統的反向工程。

Netflix 大規模生產級微服務

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

100s 範圍的微服務（2016 年的資料是超過 500 個），1000s 範圍的每日生產變更，10,000s 範圍的例項，1,000,000s 範圍的活躍客戶數，1,000,000,000s 範圍的度量指標。但是隻有 10s 範圍的運維工程師，沒有自己的資料中心 NOC，應該算微服務和 DevOps 的最高境界了。下面兩個圖片來自附錄 [2]。

圖 1，Netflix 生態系統

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

下圖 3 是 Netflix 微服務視覺化來自附錄 [3]

圖 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 微服務持續交付的更多細節，可參考其博文 [附錄 6 和 7]。

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

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 開源軟體中心

   https://netflix.github.io/

2. How Netflix Thinks of DevOps

   https://www.slideshare.net/diannemarsh/how-netflix-thinks-of-devops-spoiler-we-dont

3. Mastering Chaos - A Netflix Guide to Microservices

   https://www.slideshare.net/JoshEvans2/mastering-chaos-a-netflix-guide-to-microservices

4. An Inverse Evaluation of Netflix Architecture Using ATAM

   https://resources.sei.cmu.edu/asset_files/Presentation/2016_017_001_454646.pdf

5. Netflix 技術部落格

   http://techblog.netflix.com

6. Preparing the Netflix API for Deployment

   https://medium.com/netflix-techblog/preparing-the-netflix-api-for-deployment-786d8f58090d

7. Deploying the Netflix API

   https://medium.com/netflix-techblog/deploying-the-netflix-api-79b6176cc3f0

8. 企業的組織架構是如何影響技術架構的

   http://www.infoq.com/cn/articles/organization-arch-influence-technology-arch

9. 當技術為組織所累時怎麼辦？將你的組織架構旋轉 90 度！

   https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650998289&idx=1&sn=af27e4141f347d800eb7f00f6d67bcb4&scene=19#wechat_redirect

楊波，具有超過 10 年的網際網路分散式系統研發和架構經驗，曾先後就職於：eBay 中國研發中心（eBay CDC），任資深研發工程師，參與億貝開放 API 平臺研發，攜程旅遊網（Ctrip），任技術研發總監，主導攜程大規模 SOA 體系建設，唯品會（VIPShop），任資深雲平臺架構師，負責容器 PaaS 平臺的調研和架構。