Netflix 是美國在線影(yǐng)片租賃商，曾利用超過 100 億次的用戶觀看紀錄分析觀衆喜好，制(zhì)作(zuò)出熱播劇(jù)集《紙牌屋》。Netflix 還(hái)是業界微服務和(hé) DevOps 組織的楷模，有(yǒu)大(dà)規模生(shēng)産級微服務的成功實踐。本文是作(zuò)者多(duō)年研究 Netflix 技(jì)術(shù)資料的總結，可(kě)以認為(wèi)是對 Netflix 微服務技(jì)術(shù)架構的一次全面系統的反向工程。

Netflix 大(dà)規模生(shēng)産級微服務

微服務很(hěn)多(duō)公司 (Amazon, eBay, BAT) 都有(yǒu)，甚至比 Netflix 做(zuò)得(de)更早，但(dàn) Netflix 大(dà)概是大(dà)規模生(shēng)産級微服務做(zuò)得(de)最傑出的。

100s 範圍的微服務（2016 年的數(shù)據是超過 500 個(gè)），1000s 範圍的每日生(shēng)産變更，10,000s 範圍的實例，1,000,000s 範圍的活躍客戶數(shù)，1,000,000,000s 範圍的度量指标。但(dàn)是隻有(yǒu) 10s 範圍的運維工程師(shī)，沒有(yǒu)自己的數(shù)據中心 NOC，應該算(suàn)微服務和(hé) DevOps 的最高(gāo)境界了。

圖 1，Netflix 生(shēng)态系統

圖 2，Netflix 運維工程師(shī)數(shù)量很(hěn)少(shǎo)

圖 3，Netflix 微服務可(kě)視(shì)化

Netflix 微服務支撐技(jì)術(shù)大(dà)圖

我們可(kě)以通(tōng)過三個(gè)宏觀視(shì)圖，全面理(lǐ)解 Netflix 微服務技(jì)術(shù)架構體(tǐ)系：

從下至上(shàng)的分層視(shì)圖：

圖 4，分層技(jì)術(shù)體(tǐ)系（從下而上(shàng)）

• 第 1 層：IaaS 層，計(jì)算(suàn)，網絡，負載均衡和(hé)存儲等服務，Netflix 沒有(yǒu)自己的數(shù)據中心，依賴 AWS 提供的 IaaS 服務。

• 第 2 層：PaaS 層，平台運行(xíng)時(shí)服務，框架和(hé)庫，監控和(hé)可(kě)靠性，持續交付和(hé)大(dà)數(shù)據等服務。Netflix 平台團隊打造的 PaaS 平台，是支撐微服務的核心基礎設施。該層的大(dà)部分組件開(kāi)源，統稱 NetflixOSS[附錄 1]。

• 第 3 層：應用和(hé)服務層，相當于業務能力交付層，各業務團隊在 PaaS 和(hé) IaaS 平台基礎上(shàng)構建面向內(nèi)外客戶的微服務和(hé)應用。

從外到內(nèi)的分層視(shì)圖：

圖 5，微服務分層視(shì)圖（從外而內(nèi)）

• 第 0 層：端用戶設備層，浏覽器(qì)，手持設備，智能電(diàn)視(shì)，遊戲設備等等。據稱 Netflix 要支持超過 1000 種端用戶設備。

• 第 1 層：接入層，基于 AWS 的 ELB 接入用戶流量。

• 第 2 層：網關層，将外部請(qǐng)求反向路由到內(nèi)部微服務，Netflix 使用自研 Zuul 網關。網關隻負責跨橫切面功能（反向路由，安全，限流熔斷和(hé)日志(zhì)監控等），無業務邏輯。網關無狀态部署，依賴前端 ELB 做(zuò)負載均衡。

• 第 3 層：聚合服務層，負責對後台微服務進行(xíng)聚合裁減加工後暴露給前端設備，在 Netflix 的體(tǐ)系中，該層也稱邊界服務層 (Edge Service)，或者設備适配層。考慮到設備的多(duō)樣性和(hé)前端業務的多(duō)變性，Netflix 前端團隊大(dà)量使用 Groovy 腳本作(zuò)為(wèi)聚合層的主要開(kāi)發語言，同時(shí)兼容 Java 又具有(yǒu)腳本易于變更特性。

• 第 4 層：後台基礎服務層，提供支持 Netflix 業務的核心領域服務（Playback, Member, Review ,Payment etc），在 Netflix 體(tǐ)系中，該層也稱為(wèi)中間(jiān)層服務 (Middle Tier Service)。

• 第 5 層：數(shù)據訪問層，提供對 Cassandra NoSql 數(shù)據存儲（Netflix 的主要數(shù)據持久化方式），後台服務 (Memcached, Zookeeper, S3, SQS 等) 和(hé)大(dà)數(shù)據等的訪問和(hé)工具支持。

另外：

1. 第 3 和(hé)第 4 層統稱為(wèi) Netflix 的微服務，總體(tǐ)實現 Netflix 業務能力輸出。

2. 所有(yǒu)微服務內(nèi)部通(tōng)過服務注冊表 Eureka 做(zuò)自注冊和(hé)自發現，也就是說 Netflix 內(nèi)部服務調用都是通(tōng)過客戶端軟負載直連方式。網關 Zuul 也通(tōng)過 Eureka 發現內(nèi)部服務，将外部請(qǐng)求反向路由到內(nèi)部服務，具體(tǐ)見後面的圖 [7]。

3. 所有(yǒu)微服務依賴縱向的平台支撐服務（平台運行(xíng)時(shí)服務，框架和(hé)庫，監控和(hé)可(kě)靠性服務），以及第 5 層的後台服務和(hé)大(dà)數(shù)據服務等。

4. 所有(yǒu)服務之間(jiān)的調用（包括網關調聚合服務，聚合服務調後台基礎服務，或後台服務相互調用）都置于依賴容錯組件 Hystrix 的保護之下，實現自動化的限制(zhì)、熔斷、隔離和(hé)降級功能，防雪崩效應保障用戶體(tǐ)驗。

部署視(shì)圖：

圖 6，部署視(shì)圖

上(shàng)圖 6 是 Netflix 微服務在一個(gè) AWS Zone 中的簡化部署視(shì)圖，分析如下：

1. 應用和(hé)服務部署在 AWS 的虛拟機中，每個(gè)應用集成平台團隊提供的公共框架和(hé)庫（依賴注入 Governator，配置 Archaius，監控 Servo，服務框架服務器(qì)端 Karyon 和(hé)客戶端 Ribbon，緩存 EvCache/ 消息 SQS/Cassandra Astyanax 等後台服務客戶端，熔斷 Hystrix 等等）。

2. 內(nèi)部微服務通(tōng)過 Eureka 做(zuò)自注冊和(hé)自發現。外部流量通(tōng)過 Zuul 網關接入并反向到內(nèi)部微服務。

3. Netflix 的持久化存儲主要使用 Cassandra，緩存用 Memcached，日志(zhì)用 ElasticSearch，Metrics 用自研 Atlas 時(shí)間(jiān)序列數(shù)據庫，數(shù)據總線采用 Kafka。

4. 代碼通(tōng)過 Nebula 打成包，再通(tōng)過 Aminator 打成 AMI 鏡像，最後使用 Asgard(升級版是 Spinnaker) 發布到 AWS 雲中。發布采用藍(lán)綠和(hé)金絲雀機制(zhì)，每個(gè)發布至少(shǎo)要兩個(gè)發布組 ASG（Auto-Scaling Group）, 通(tōng)過 Eureka 動态調撥流量做(zuò)灰度測試。

5. 各種猴子（Chaos/Latency/Janitor/SecurityMonkey 等）可(kě)以對 Netflix 的服務進行(xíng)随機的抗脆弱測試和(hé)各種檢查。

6. Edda 支持對 AWS 雲資源進行(xíng)變更監控，Ice 支持對 AWS 雲資源的使用成本進行(xíng)監控。

公共運行(xíng)時(shí)服務

下圖 7 是抽象後的 Netflix 微服務總體(tǐ)路由發現體(tǐ)系，服務可(kě)以簡化成前端邊界服務（Edge Services）和(hé)後端中間(jiān)層服務（Middle Tier Services）兩層，Zuul 網關和(hé) Eureka 注冊中心是支撐微服務路由發現的關鍵運行(xíng)時(shí)服務。

服務路由發現體(tǐ)系

• Eureka：內(nèi)部服務的自注冊自發現全部通(tōng)過 Eureka，服務之間(jiān)調用直連。Eureka 提供灰度能力，支持發布系統動态調撥流量做(zuò)藍(lán)綠和(hé)灰度發布。

• Zuul：将外部流量反向路由到內(nèi)部服務（也通(tōng)過 Eureka 發現內(nèi)部服務），同時(shí)兼做(zuò)安全，限流熔斷，日志(zhì)監控等跨橫切面功能，也具備導流，壓側，在線調試，跨數(shù)據中心 HA 等高(gāo)級功能。

• 另外，配置中心也屬于公共運行(xíng)時(shí)服務，支持運行(xíng)期動态配置和(hé)各種業務開(kāi)關。Netflix 開(kāi)源了配置中心的客戶端 Archaius，但(dàn)是沒有(yǒu)開(kāi)源內(nèi)部的服務器(qì)端。

框架和(hé)庫

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

圖 8，服務框架和(hé)庫

服務框架：

1. Karyon 是 Netflix 的服務容器(qì)，是對 Jax-rs 參考實現 Jersey 的一個(gè)封裝，集成了依賴注入 Governator，配置 Archaius，服務發現 Eureka，管理(lǐ)界面 Admin 和(hé)健康檢查 HealthCheck 等能力。Governator 是對 Google Guice 進行(xíng)擴展的類庫，提供了 Classpath 掃描和(hé)自動綁定、生(shēng)命周期管理(lǐ)、成員屬性驗證等功能。

2. RxJava 是 Netflix 的異步化組件，可(kě)實現異步和(hé)基于事件的微服務調用。

3. Hystrix 是 Netflix 的彈性容錯組件，大(dà)部分跨進程調用（服務間(jiān) /DB/ 緩存等）都置于 Hystrix 的保護下，實現熔斷 / 限流 / 隔離 / 降級等功能。Turbine 是和(hé) Hystrix 配套的實時(shí)流聚合服務，配合 Hystrix Dashoard 可(kě)以對服務實時(shí)性能進行(xíng)聚合展示。

4. Ribbon 是 Netflix 的服務調用客戶端，集成 Eureka 的服務發現能力，實現軟負載 SLB，可(kě)以采用不同路由策略（随機 /RoundRobin/ 帶權重 / 甚至跨 AWS Zone HA）訪問目标服務。

數(shù)據訪問層：

1. Curator 是對 Zookeeper 底層 API 的進一步封裝，方便開(kāi)發人(rén)員使用 ZK 的分布式協調能力。

2. EVCache 客戶端方便開(kāi)發人(rén)員接入 Memcached 緩存，支持跨 AWS Zone 的 HA 能力。

3. Astyanax 是 Cassandra Java 客戶端，提供了更高(gāo)層次的 API、客戶端故障轉移、連接池管理(lǐ)、自動重試及發現等功能，還(hái)包含常用 Cassandra 的數(shù)據模型。

監控和(hé)配置

1. Vector 是一個(gè)主機監控框架，可(kě)以将高(gāo)精度的主機指标直接暴露在浏覽器(qì)中，方便研發人(rén)員定位主機性能（內(nèi)存 /CPU/ 網絡 /OS 等）問題。

2. Servo 是 Metrics 客戶端組件，類似 Dropwizard Metrics，方便研發人(rén)員對各種業務 / 應用 / 系統的指标進行(xíng)打點監控，監控類型包括測量 Gauges，計(jì)數(shù)器(qì) Counters 和(hé)計(jì)時(shí)器(qì) Timers。Servo 後台對接 Netflix 時(shí)間(jiān)序列數(shù)據庫 Atlas。

3. Blitz4j 是 Netflix 對 log4j 的異步化改造版，能夠減少(shǎo)争用，在 Netflix 用于監控、商務智能和(hé)調試等衆多(duō)日志(zhì)場(chǎng)景。

4. Archaius 是 Netflix 集中式配置系統的客戶端，支持靈活多(duō)層級的動态配置，支持業務微服務按需調整運行(xíng)期行(xíng)為(wèi)。

監控和(hé)可(kě)靠性工程

監控是微服務閉環治理(lǐ)的重要方面。Netflix 主要使用 Elasticsearch 棧進行(xíng)日志(zhì)監控，日志(zhì)總線采用 Kafka。時(shí)間(jiān)序列數(shù)據庫使用自研的 Atlas，以內(nèi)存方式存儲時(shí)間(jiān)序列，支持高(gāo)速寫入和(hé)查詢。

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

為(wèi)進一步提升微服務系統的可(kě)靠性，Netflix 提出抗脆弱架構理(lǐ)念，開(kāi)發諸多(duō)猴子對生(shēng)産系統進行(xíng)随機的抗脆弱測試，這些(xiē)猴子統稱 Simian Army[圖 9]，包括：

圖 9，Simian Army

1. Chaos Monkey：可(kě)以随機關閉生(shēng)産環境中的實例，确保網站(zhàn)系統能夠經受故障的考驗，同時(shí)不會(huì)影(yǐng)響客戶的正常使用。

2. Latency Monkey：在 RESTful 服務的調用中人(rén)為(wèi)引入延遲來(lái)模拟服務降級，測量上(shàng)遊服務是否會(huì)做(zuò)出恰當響應。通(tōng)過引入長時(shí)間(jiān)延遲，還(hái)可(kě)以模拟節點甚至整個(gè)服務不可(kě)用。

3. Conformity Monkey：查找不符合最佳實踐的實例，并将其關閉。例如，如果某個(gè)實例不在自動伸縮組裏，那(nà)麽就将其關閉，讓服務所有(yǒu)者能重新讓其正常啓動。

4. Doctor Monkey：查找不健康實例的工具，除了運行(xíng)在每個(gè)實例上(shàng)的健康檢查，還(hái)會(huì)監控外部健康信号，一旦發現不健康實例就會(huì)将其移出服務組。

5. Janitor Monkey：查找不再需要的資源，将其回收，這能在一定程度上(shàng)降低(dī)雲資源的浪費。

6. Security Monkey：這是 Conformity Monkey 的一個(gè)擴展，檢查系統的安全漏洞，同時(shí)也會(huì)保證 SSL 和(hé) DRM 證書(shū)仍然有(yǒu)效。

7. 10-18 Monkey：運行(xíng)本地化及國際化的配置檢查，确保不同地區(qū)、使用不同語言和(hé)字符集的用戶能正常使用 Netflix。

8. Chaos Gorilla：Chaos Monkey 的升級版，可(kě)以模拟整個(gè) AWS Availability Zone 故障，以驗證在不影(yǐng)響用戶，且無需人(rén)工幹預的情況下，能夠自動進行(xíng)可(kě)用區(qū)的重新平衡。

持續交付

圖 10，Netflix 持續交付流水(shuǐ)線

Netflix 具備強大(dà)的發布流水(shuǐ)線（CD pipeline，圖 10），支持研發人(rén)員以自助（self-service）方式持續交付微服務，整個(gè)交付體(tǐ)系基于不可(kě)變基礎設施（immutable infrastructure）理(lǐ)念，簡化流程如下：

1. 開(kāi)發人(rén)員使用 Karyon 服務框架開(kāi)發微服務應用，将代碼提交到代碼倉庫。

2. 代碼經過 CI 持續構建流水(shuǐ)線驗證後打成應用包（war 或 jar）。

3. 開(kāi)發人(rén)員使用 Aminator 工具将應用包和(hé)基礎鏡像（Base AMI）打成可(kě)發布 AMI 鏡像，該過程也稱鏡像烘焙（Baking）。

4. 開(kāi)發人(rén)員使用 Asgard（新版升級為(wèi) Spinnaker）發布系統在 AWS 雲中創建新發布組，啓動發布将鏡像推到雲中。服務實例啓動後自注冊到 Eureka 注冊中心，開(kāi)發人(rén)員使用 Asgard 動态調撥流量做(zuò)金絲雀（Canary Testing）測試，測試成功則拉入全部流量，失敗則退回之前版本。

關于 Netflix 微服務持續交付的更多(duō)細節，可(kě)參考其博文 。

Netflix 架構治理(lǐ)理(lǐ)念

上(shàng)面介紹了很(hěn)多(duō) Netflix 微服務的技(jì)術(shù)架構和(hé)各種支持服務或組件，可(kě)以說是 Netflix 微服務架構的形，而其背後的無中心分散式架構治理(lǐ)理(lǐ)念，才是 Netflix 微服務架構的神，是我們架構師(shī)更加應該關注和(hé)領會(huì)的。下面是這些(xiē)理(lǐ)念的總結：

1、讓具有(yǒu)上(shàng)下文的團隊自己去做(zuò)技(jì)術(shù)決策和(hé)試驗，以達成質量目标，要優于高(gāo)度同質化一緻性的系統。Local context and decision，微服務架構賦能團隊做(zuò)民主自治的技(jì)術(shù)決策和(hé)創新。

2、創新和(hé)成長是軟件研發的非常重要的方面，控制(zhì)、集中式計(jì)劃和(hé)對管理(lǐ)透明(míng)顯然是不佳的激勵方式。微服務架構主張分散式治理(lǐ)，有(yǒu)利于團隊的快速創新和(hé)成長。

3、快速開(kāi)發和(hé)交付新功能，要優于完全沒有(yǒu)缺陷和(hé)問題再上(shàng)到生(shēng)産。當然這種快速交付能力有(yǒu)賴于完善的監控和(hé)靈活部署能力。

4、微服務架構的分散式治理(lǐ)方式難免引入一定的冗餘開(kāi)發和(hé)降低(dī)重用度。但(dàn)是為(wèi)了達成最優客戶體(tǐ)驗和(hé)質量（赢得(de)市場(chǎng)競争優勢），适度的冗餘開(kāi)發和(hé)低(dī)重用度是完全 OK 的。

5、微服務架構需要紮實的底層技(jì)術(shù)平台能力 (PaaS/IaaS) 的支撐。但(dàn)是為(wèi)了長期的技(jì)術(shù)棧适用性和(hé)領先，最初在框架、自動化和(hé)基礎設施抽象方面的高(gāo)度投入是完全合理(lǐ)的。

寫在最後

1. 限于篇幅，大(dà)數(shù)據和(hé)安全部分沒有(yǒu)展開(kāi)，它們也是 Netflix 微服務支撐技(jì)術(shù)的重要部分，可(kě)參考 Netflix 開(kāi)源軟件中心 [附錄 1] 和(hé)其技(jì)術(shù)博客 [附錄 5] 了解更多(duō)細節。

2. 限于篇幅，分布式數(shù)據訪問層和(hé)跨數(shù)據中心 HA 等高(gāo)級主題沒有(yǒu)講述，Netflix 在這些(xiē)方面投入巨大(dà)，但(dàn)是大(dà)部分技(jì)術(shù)組織還(hái)不到那(nà)個(gè)階段。

3. 作(zuò)者并沒有(yǒu)在 Netflix 工作(zuò)過，本文主要基于 Github, slideshare 和(hé) Netflix techblog 資料的學習總結，有(yǒu)些(xiē)理(lǐ)解可(kě)能是偏頗的。Netflix 技(jì)術(shù)本身也在快速的演進中，本文中的很(hěn)多(duō)信息可(kě)能已經過時(shí)了，但(dàn)是仍然有(yǒu)借鑒價值。

4. 微服務和(hé) DevOps 在組織的落地，組織架構轉型和(hé)基礎技(jì)術(shù)平台是關鍵，兩條腿走路，不能偏廢。當然組織架構和(hé)技(jì)術(shù)平台都離不開(kāi)人(rén)才密度這個(gè)根本。

5. 考慮到微服務和(hé) DevOps 需要在底層基礎設施 (PaaS/IaaS) 的巨大(dà)投入（本文可(kě)見一斑），如果企業的業務和(hé)團隊規模還(hái)沒有(yǒu)達到一定的量，則要慎重考慮在微服務架構上(shàng)的投入。初創企業重點應該放在驗證業務模式和(hé)謀活，以單塊應用架構起步更合理(lǐ)，等有(yǒu)一天業務團隊規模達到那(nà)個(gè)量，再考慮微服務架構不遲，Netflix 的微服務架構也是從單塊架構開(kāi)始一路演化出來(lái)的。

6. Netflix 微服務技(jì)術(shù)架構隻是一個(gè)參考樣闆，NetflixOSS 中的産品也有(yǒu)很(hěn)多(duō)其它開(kāi)源産品可(kě)以替代，架構師(shī)可(kě)學習吸收 Netflix 微服務架構技(jì)術(shù)體(tǐ)系和(hé)理(lǐ)念，但(dàn)不可(kě)盲從其技(jì)術(shù)，需根據企業實際情況定制(zhì)自己的微服務支撐技(jì)術(shù)體(tǐ)系。