业界微服务楷模Netflix是这样构建微服务技术架构的

原文：  https://mp.weixin.qq.com/s/C8Rdz9wFtrBKfxPRzf0OBQ

作者｜杨波编辑｜小智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 微服务架构的形，而其背后的无中心分散式架构治理理念，才是 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 平台的调研和架构。