您的位置:网站首页 > net源码 > 正文

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

类别:net源码 日期:2019-3-13 22:26:13 人气: 来源:

  前世死因分析测试Netflix 是美国在线影片租赁商,曾利用超过 100 亿次的用户观看纪录分析观众喜好,制作出热播剧集《纸牌屋》。Netflix 还是业界微服务和 DevOps 组织的楷模,有大规模生产级微服务的成功实践。本文是作者多年研究 Netflix 技术资料的总结,可以认为是对 Netflix 微服务技术架构的一次全面系统的反向工程。

  100s 范围的微服务(2016 年的数据是超过 500 个),1000s 范围的每日生产变更,10,000s 范围的实例,1,000,000s 范围的活跃客户数,1,000,000,000s 范围的度量指标。但是只有 10s 范围的运维工程师,没有自己的数据中心 NOC,应该算微服务和 DevOps 的最高境界了。

  第 1 层:IaaS 层,计算,网络,负载均衡和存储等服务,Netflix 没有自己的数据中心,依赖 AWS 提供的 IaaS 服务。第 2 层:PaaS 层,平台运行时服务,框架和库,和可靠性,持续交付和大数据等服务。Netflix 平台团队打造的 PaaS 平台,是支撑微服务的核心基础设施。该层的大部分组件开源,统称 NetflixOSS[附录 1]。第 3 层:应用和服务层,相当于业务能力交付层,各业务团队在 PaaS 和 IaaS 平台基础上构建面向内外客户的微服务和应用。

  第 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 等) 和大数据等的访问和工具支持。

  第 3 和第 4 层统称为 Netflix 的微服务,总体实现 Netflix 业务能力输出。所有微服务内部通过服务注册表 Eureka 做自注册和自发现,也就是说 Netflix 内部服务调用都是通过客户端软负载直连方式。网关 Zuul 也通过 Eureka 发现内部服务,将外部请求反向由到内部服务,具体见后面的图 [7]。所有微服务依赖纵向的平台支撑服务(平台运行时服务,框架和库,和可靠性服务),以及第 5 层的后台服务和大数据服务等。所有服务之间的调用(包括网关调聚合服务,聚合服务调后台基础服务,或后台服务相互调用)都置于依赖容错组件 Hystrix 的之下,实现自动化的、熔断、隔离和降级功能,防雪崩效应保障用户体验。

  下图 7 是抽象后的 Netflix 微服务总体由发现体系,服务可以简化成前端边界服务(Edge Services)和后端中间层服务(Middle Tier Services)两层,Zuul 网关和 Eureka 注册中心是支撑微服务由发现的关键运行时服务。

  Eureka:内部服务的自注册自发现全部通过 Eureka,服务之间调用直连。Eureka 提供灰度能力,支持发布系统动态调拨流量做蓝绿和灰度发布。Zuul:将外部流量反向由到内部服务(也通过 Eureka 发现内部服务),同时兼做安全,限流熔断,日志等跨横切面功能,也具备导流,压侧,在线调试,跨数据中心 HA 等高级功能。另外,配置中心也属于公共运行时服务,支持运行期动态配置和各种业务开关。Netflix 开源了配置中心的客户端 Archaius,但是没有开源内部的服务器端。

  为了让业务团队专注业务能力交付,Netflix 平台团队提供统一的微服务框架和库(见下图 8),方便业务研发团队集成底层 PaaS 和服务治理能力,包括:

  Vector 是一个主机框架,可以将高精度的主机指标直接在浏览器中,方便研发人员定位主机性能(内存 /CPU/ 网络 /OS 等)问题。Servo 是 Metrics 客户端组件,类似 Dropwizard Metrics,方便研发人员对各种业务 / 应用 / 系统的指标进行打点,类型包括测量 Gauges,计数器 Counters 和计时器 Timers。Servo 后台对接 Netflix 时间序列数据库 Atlas。Blitz4j 是 Netflix 对 log4j 的异步化版,能够减少争用,在 Netflix 用于、商务智能和调试等众多日志场景。Archaius 是 Netflix 集中式配置系统的客户端,支持灵活多层级的动态配置,支持业务微服务按需调整运行期行为。

  是微服务闭环治理的重要方面。Netflix 主要使用 Elasticsearch 栈进行日志,日志总线采用 Kafka。时间序列数据库使用自研的 Atlas,以内存方式存储时间序列,支持高速写入和查询。

  除此以外,Netflix 自研工具 Edda 对 AWS 云资源进行变更,工具 Ice 对 AWS 云资源的使用成本进行。

  为进一步提升微服务系统的可靠性,Netflix 提出抗脆弱架构,开发诸多猴子对生产系统进行随机的抗脆弱测试,这些猴子统称 Simian Army[图 9],包括:

  Chaos Monkey:可以随机关闭生产中的实例,确保网站系统能够故障的,同时不会影响客户的正常使用。Latency Monkey:在 RESTful 服务的调用中人为引入延迟来模拟服务降级,测量上游服务是否会做出恰当响应。通过引入长时间延迟,还可以模拟节点甚至整个服务不可用。Conformity Monkey:查找不符合最佳实践的实例,并将其关闭。例如,如果某个实例不在自动伸缩组里,那么就将其关闭,让服务所有者能重新让其正常启动。Doctor Monkey:查找不健康实例的工具,除了运行在每个实例上的健康检查,还会外部健康信号,一旦发现不健康实例就会将其移出服务组。Janitor Monkey:查找不再需要的资源,将其回收,这能在一定程度上降低云资源的浪费。Security Monkey:这是 Conformity Monkey 的一个扩展,检查系统的安全漏洞,同时也会 SSL 和 DRM 证书仍然有效。10-18 Monkey:运行本地化及国际化的配置检查,确保不同地区、使用不同语言和字符集的用户能正常使用 Netflix。Chaos Gorilla:Chaos Monkey 的升级版,可以模拟整个 AWS Availability Zone 故障,以验证在不影响用户,且无需人工干预的情况下,能够自动进行可用区的重新平衡。

  Netflix 具备强大的发布流水线(CD pipeline,图 10),支持研发人员以自助(self-service)方式持续交付微服务,整个交付体系基于不可变基础设施(immutable infrastructure),简化流程如下:

  开发人员使用 Karyon 服务框架开发微服务应用,将代码提交到代码仓库。代码经过 CI 持续构建流水线验证后打成应用包(war 或 jar)。开发人员使用 Aminator 工具将应用包和基础镜像(Base AMI)打成可发布 AMI 镜像,该过程也称镜像烘焙(Baking)。开发人员使用 Asgard(新版升级为 Spinnaker)发布系统在 AWS 云中创建新发布组,启动发布将镜像推到云中。服务实例启动后自注册到 Eureka 注册中心,开发人员使用 Asgard 动态调拨流量做金丝雀(Canary Testing)测试,测试成功则拉入全部流量,失败则退回之前版本。

  介绍了很多 Netflix 微服务的技术架构和各种支持服务或组件,可以说是 Netflix 微服务架构的形,而其背后的无中心分散式架构治理,才是 Netflix 微服务架构的神,是我们架构师更加应该关注和领会的。下面是这些的总结:

  1、让具有上下文的团队自己去做技术决策和试验,以达成质量目标,要优于高度同质化一致性的系统。Local context and decision,微服务架构赋能团队做自治的技术决策和创新。

  2、创新和成长是软件研发的非常重要的方面,控制、集中式计划和对管理透明显然是不佳的激励方式。微服务架构主张分散式治理,有利于团队的快速创新和成长。

  3、快速开发和交付新功能,要优于完全没有缺陷和问题再上到生产。当然这种快速交付能力有赖于完善的和灵活部署能力。

  4、微服务架构的分散式治理方式难免引入一定的冗余开发和降低重用度。但是为了达成最优客户体验和质量(赢得市场竞争优势),适度的冗余开发和低重用度是完全 OK 的。

  5、微服务架构需要扎实的底层技术平台能力 (PaaS/IaaS) 的支撑。但是为了长期的技术栈适用性和领先,最初在框架、自动化和基础设施抽象方面的高度投入是完全合理的。

  限于篇幅,大数据和分没有展开,它们也是 Netflix 微服务支撑技术的重要部分,可参考 Netflix 开源软件中心 [附录 1] 和其技术博客 [附录 5] 了解更多细节。限于篇幅,分布式数据访问层和跨数据中心 HA 等高级主题没有讲述,Netflix 在这些方面投入巨大,但是大部分技术组织还不到那个阶段。作者并没有在 Netflix 工作过,本文主要基于 Github, slideshare 和 Netflix techblog 资料的学习总结,有些理解可能是偏颇的。Netflix 技术本身也在快速的演进中,本文中的很多信息可能已经过时了,但是仍然有借鉴价值。微服务和 DevOps 在组织的落地,组织架构转型和基础技术平台是关键,两条腿走,不能偏废。当然组织架构和技术平台都离不开人才密度这个根本。考虑到微服务和 DevOps 需要在底层基础设施 (PaaS/IaaS) 的巨大投入(本文可见一斑),如果企业的业务和团队规模还没有达到一定的量,则要慎重考虑在微服务架构上的投入。初创企业重点应该放在验证业务模式和谋活,以单块应用架构起步更合理,等有一天业务团队规模达到那个量,再考虑微服务架构不迟,Netflix 的微服务架构也是从单块架构开始一演化出来的。Netflix 微服务技术架构只是一个参考样板,NetflixOSS 中的产品也有很多其它开源产品可以替代,架构师可学习吸收 Netflix 微服务架构技术体系和,但不可其技术,需根据企业实际情况定制自己的微服务支撑技术体系。作者后续仍将进一步细化详解微服务支撑技术组件和开源实践,读者可以关注 Infoq 号等待后续更新。

  杨波,具有超过 10 年的互联网分布式系统研发和架构经验,曾先后就职于:eBay 中国研发中心(eBay CDC),任资深研发工程师,参与亿贝 API 平台研发,携程旅游网(Ctrip),任技术研发总监,主导携程大规模 SOA 体系建设,唯品会(VIPShop),任资深云平台架构师,负责容器 PaaS 平台的调研和架构。

  

关键词:net技术架构
0
0
0
0
0
0
0
0
下一篇:没有资料

相关阅读

网友评论 ()条 查看

姓名: 验证码: 看不清楚,换一个

推荐文章更多

热门图文更多

最新文章更多

关于联系我们 - 广告服务 - 友情链接 - 网站地图 - 版权声明 - 人才招聘 - 帮助

CopyRight 2002-2012 技术支持 源码吧 FXT All Rights Reserved

赞助合作: