编者按：本文转发自微信公众号“infoq”（infoqchina），作者：杨波，36氪经授权转发。
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的体系中，该层也称边界服务层(edgeservice)，或者设备适配层。考虑到设备的多样性和前端业务的多变性，netflix前端团队大量使用groovy脚本作为聚合层的主要开发语言，同时兼容java又具有脚本易于变更特性。第4层：后台基础服务层，提供支持netflix业务的核心领域服务（playback,member,review,paymentetc），在netflix体系中，该层也称为中间层服务(middletierservice)。第5层：数据访问层，提供对cassandranosql数据存储（netflix的主要数据持久化方式），后台服务(memcached,zookeeper,s3,sqs等)和大数据等的访问和工具支持。
另外：
第3和第4层统称为netflix的微服务，总体实现netflix业务能力输出。所有微服务内部通过服务注册表eureka做自注册和自发现，也就是说netflix内部服务调用都是通过客户端软负载直连方式。网关zuul也通过eureka发现内部服务，将外部请求反向路由到内部服务，具体见后面的图[7]。所有微服务依赖纵向的平台支撑服务（平台运行时服务，框架和库，监控和可靠性服务），以及第5层的后台服务和大数据服务等。所有服务之间的调用（包括网关调聚合服务，聚合服务调后台基础服务，或后台服务相互调用）都置于依赖容错组件hystrix的保护之下，实现自动化的限制、熔断、隔离和降级功能，防雪崩效应保障用户体验。
部署视图：
图6，部署视图
上图6是netflix微服务在一个awszone中的简化部署视图，分析如下：
应用和服务部署在aws的虚拟机中，每个应用集成平台团队提供的公共框架和库（依赖注入governator，配置archaius，监控servo，服务框架服务器端karyon和客户端ribbon，缓存evcache/消息sqs/cassandraastyanax等后台服务客户端，熔断hystrix等等）。内部微服务通过eureka做自注册和自发现。外部流量通过zuul网关接入并反向到内部微服务。netflix的持久化存储主要使用cassandra，缓存用memcached，日志用elasticsearch，metrics用自研atlas时间序列数据库，数据总线采用kafka。代码通过nebula打成包，再通过aminator打成ami镜像，最后使用asgard(升级版是spinnaker)发布到aws云中。发布采用蓝绿和金丝雀机制，每个发布至少要两个发布组asg（auto-scalinggroup）,通过eureka动态调拨流量做灰度测试。各种猴子（chaos/latency/janitor/securitymonkey等）可以对netflix的服务进行随机的抗脆弱测试和各种检查。edda支持对aws云资源进行变更监控，ice支持对aws云资源的使用成本进行监控。
公共运行时服务
下图7是抽象后的netflix微服务总体路由发现体系，服务可以简化成前端边界服务（edgeservices）和后端中间层服务（middletierservices）两层，zuul网关和eureka注册中心是支撑微服务路由发现的关键运行时服务。
服务路由发现体系
eureka：内部服务的自注册自发现全部通过eureka，服务之间调用直连。eureka提供灰度能力，支持发布系统动态调拨流量做蓝绿和灰度发布。zuul：将外部流量反向路由到内部服务（也通过eureka发现内部服务），同时兼做安全，限流熔断，日志监控等跨横切面功能，也具备导流，压侧，在线调试，跨数据中心ha等高级功能。另外，配置中心也属于公共运行时服务，支持运行期动态配置和各种业务开关。netflix开源了配置中心的客户端archaius，但是没有开源内部的服务器端。
框架和库
为了让业务团队专注业务能力交付，netflix平台团队提供统一的微服务框架和库（见下图8），方便业务研发团队集成底层paas和服务治理能力，包括：
图8，服务框架和库
服务框架：
karyon是netflix的服务容器，是对jax-rs参考实现jersey的一个封装，集成了依赖注入governator，配置archaius，服务发现eureka，管理界面admin和健康检查healthcheck等能力。governator是对googleguice进行扩展的类库，提供了classpath扫描和自动绑定、生命周期管理、成员属性验证等功能。rxjava是netflix的异步化组件，可实现异步和基于事件的微服务调用。hystrix是netflix的弹性容错组件，大部分跨进程调用（服务间/db/缓存等）都置于hystrix的保护下，实现熔断/限流/隔离/降级等功能。turbine是和hystrix配套的实时流聚合服务，配合hystrixdashoard可以对服务实时性能进行聚合展示。ribbon是netflix的服务调用客户端，集成eureka的服务发现能力，实现软负载slb，可以采用不同路由策略（随机/roundrobin/带权重/甚至跨awszoneha）访问目标服务。
数据访问层：
curator是对zookeeper底层api的进一步封装，方便开发人员使用zk的分布式协调能力。evcache客户端方便开发人员接入memcached缓存，支持跨awszone的ha能力。astyanax是cassandrajava客户端，提供了更高层次的api、客户端故障转移、连接池管理、自动重试及发现等功能，还包含常用cassandra的数据模型。
监控和配置
vector是一个主机监控框架，可以将高精度的主机指标直接暴露在浏览器中，方便研发人员定位主机性能（内存/cpu/网络/os等）问题。servo是metrics客户端组件，类似dropwizardmetrics，方便研发人员对各种业务/应用/系统的指标进行打点监控，监控类型包括测量gauges，计数器counters和计时器timers。servo后台对接netflix时间序列数据库atlas。blitz4j是netflix对log4j的异步化改造版，能够减少争用，在netflix用于监控、商务智能和调试等众多日志场景。archaius是netflix集中式配置系统的客户端，支持灵活多层级的动态配置，支持业务微服务按需调整运行期行为。
监控和可靠性工程
监控是微服务闭环治理的重要方面。netflix主要使用elasticsearch栈进行日志监控，日志总线采用kafka。时间序列数据库使用自研的atlas，以内存方式存储时间序列，支持高速写入和查询。
除此以外，netflix自研工具edda对aws云资源进行变更监控，工具ice对aws云资源的使用成本进行监控。
为进一步提升微服务系统的可靠性，netflix提出抗脆弱架构理念，开发诸多猴子对生产系统进行随机的抗脆弱测试，这些猴子统称simianarmy[图9]，包括：
图9，simianarmy
chaosmonkey：可以随机关闭生产环境中的实例，确保网站系统能够经受故障的考验，同时不会影响客户的正常使用。latencymonkey：在restful服务的调用中人为引入延迟来模拟服务降级，测量上游服务是否会做出恰当响应。通过引入长时间延迟，还可以模拟节点甚至整个服务不可用。conformitymonkey：查找不符合最佳实践的实例，并将其关闭。例如，如果某个实例不在自动伸缩组里，那么就将其关闭，让服务所有者能重新让其正常启动。doctormonkey：查找不健康实例的工具，除了运行在每个实例上的健康检查，还会监控外部健康信号，一旦发现不健康实例就会将其移出服务组。janitormonkey：查找不再需要的资源，将其回收，这能在一定程度上降低云资源的浪费。securitymonkey：这是conformitymonkey的一个扩展，检查系统的安全漏洞，同时也会保证ssl和drm证书仍然有效。10-18monkey：运行本地化及国际化的配置检查，确保不同地区、使用不同语言和字符集的用户能正常使用netflix。chaosgorilla：chaosmonkey的升级版，可以模拟整个awsavailabilityzone故障，以验证在不影响用户，且无需人工干预的情况下，能够自动进行可用区的重新平衡。
持续交付
图10，netflix持续交付流水线
netflix具备强大的发布流水线（cdpipeline，图10），支持研发人员以自助（self-service）方式持续交付微服务，整个交付体系基于不可变基础设施（immutableinfrastructure）理念，简化流程如下：
开发人员使用karyon服务框架开发微服务应用，将代码提交到代码仓库。代码经过ci持续构建流水线验证后打成应用包（war或jar）。开发人员使用aminator工具将应用包和基础镜像（baseami）打成可发布ami镜像，该过程也称镜像烘焙（baking）。开发人员使用asgard（新版升级为spinnaker）发布系统在aws云中创建新发布组，启动发布将镜像推到云中。服务实例启动后自注册到eureka注册中心，开发人员使用asgard动态调拨流量做金丝雀（canarytesting）测试，测试成功则拉入全部流量，失败则退回之前版本。
关于netflix微服务持续交付的更多细节，可参考其博文。
netflix架构治理理念
上面介绍了很多netflix微服务的技术架构和各种支持服务或组件，可以说是netflix微服务架构的形，而其背后的无中心分散式架构治理理念，才是netflix微服务架构的神，是我们架构师更加应该关注和领会的。下面是这些理念的总结：
1、让具有上下文的团队自己去做技术决策和试验，以达成质量目标，要优于高度同质化一致性的系统。localcontextanddecision，微服务架构赋能团队做民主自治的技术决策和创新。
2、创新和成长是软件研发的非常重要的方面，控制、集中式计划和对管理透明显然是不佳的激励方式。微服务架构主张分散式治理，有利于团队的快速创新和成长。
3、快速开发和交付新功能，要优于完全没有缺陷和问题再上到生产。当然这种快速交付能力有赖于完善的监控和灵活部署能力。
4、微服务架构的分散式治理方式难免引入一定的冗余开发和降低重用度。但是为了达成最优客户体验和质量（赢得市场竞争优势），适度的冗余开发和低重用度是完全ok的。
5、微服务架构需要扎实的底层技术平台能力(paas/iaas)的支撑。但是为了长期的技术栈适用性和领先，最初在框架、自动化和基础设施抽象方面的高度投入是完全合理的。
写在最后
限于篇幅，大数据和安全部分没有展开，它们也是netflix微服务支撑技术的重要部分，可参考netflix开源软件中心[附录1]和其技术博客[附录5]了解更多细节。限于篇幅，分布式数据访问层和跨数据中心ha等高级主题没有讲述，netflix在这些方面投入巨大，但是大部分技术组织还不到那个阶段。作者并没有在netflix工作过，本文主要基于github,slideshare和netflixtechblog资料的学习总结，有些理解可能是偏颇的。netflix技术本身也在快速的演进中，本文中的很多信息可能已经过时了，但是仍然有借鉴价值。微服务和devops在组织的落地，组织架构转型和基础技术平台是关键，两条腿走路，不能偏废。当然组织架构和技术平台都离不开人才密度这个根本。考虑到微服务和devops需要在底层基础设施(paas/iaas)的巨大投入（本文可见一斑），如果企业的业务和团队规模还没有达到一定的量，则要慎重考虑在微服务架构上的投入。初创企业重点应该放在验证业务模式和谋活，以单块应用架构起步更合理，等有一天业务团队规模达到那个量，再考虑微服务架构不迟，netflix的微服务架构也是从单块架构开始一路演化出来的。netflix微服务技术架构只是一个参考样板，netflixoss中的产品也有很多其它开源产品可以替代，架构师可学习吸收netflix微服务架构技术体系和理念，但不可盲从其技术，需根据企业实际情况定制自己的微服务支撑技术体系。作者后续仍将进一步细化详解微服务支撑技术组件和开源实践，读者可以关注infoq公众号等待后续更新。
附录
netflix开源软件中心hownetflixthinksofdevopsmaste...