Netflix 微服务架构设计的经验总结!

迁移到微服务架构能够为公司的市场带来激动人心的机会,因为它为用户带来更加快速的新功能发布。你知道未来公司的成功取决于是否迁移到微服务架构,但你该如何去做呢?


幸运的是一些早期的微服务实践者已经慷慨的分享了他们在微服务方面的实践,以及贡献了源代码。Adrian Cockcroft – Netflix 的云架构师,他见证了 Netflix 从100人的传统应用研发团队,研发一个 DVD 租赁系统的巨石应用,演进到多个独立的小团队,支持500个微服务,每天1.2亿人观看的视频网站。


Netflix 微服务架构设计的经验总结!_第1张图片


什么是微服务架构?


Cockcroft 将微服务定义为:A microservices architecture as a service‑oriented architecture composed of loosely coupled elements that have bounded contexts. 这里有两个核心概念,一是 Loosely Coupled,二是 Bounded Context。

 

 Loosely Coupled(松耦合) 意思是:

  1. 可以独立的更新每个服务

  2. 更新一个服务无需要求改变其他服务


如果你有一堆小的服务但不能独立更新,那也不叫微服务,因为这些服务并没有松耦合。原因之一,是有的公司将应用拆分了,但并没有拆分数据库,所有的应用仍然访问同一个数据库,你需要为每个服务拆分数据库。

 

Bounded Contexts  概念来自 Eric Evans 写的 Domain Driven Design 这本书 。微服务需要有明确的边界性,你可以只关注自身软件的发布,而无需考虑谁在依赖你的发布版本,因为微服务和它的消费者严格通过 API 进行交互,不共享数据结构、数据库、POJO 等等。基于契约的微服务规范要求服务接口是稳定的,而且向下兼容。


设计微服务架构的最佳实践


为每个微服务创建一个独立的数据存储


Netflix 微服务架构设计的经验总结!_第2张图片


不要为微服务提供共享的后端数据存储。每个团队有选择最适合数据库的自由。将数据库拆分会让数据管理变得复杂,因为独立的数据存储很容易出现数据不一致的问题,外键很容易被意外的破坏。你需要工具来做主数据管理(MDM),为后端服务修复不一致的问题。例如:你需要检查所有存储用户 ID 的数据库,确保每个数据库都有完整的用户 ID 的记录,不能存在某个数据库没有某个记录的情况。你可以自己实现这个工具,也可以用商业关系数据库的系统工具,但通常这些工具都有很多门槛,并且不易扩容。


将代码的成熟度保持在相同的水平


将代码的成熟度保持在相同的水平,如果你想增加或者重写某个已经稳定服务的微服务,最好的办法,是保留已有稳定运行的服务不变,创建一个新的微服务。这是符合了 Immutable Infrastructure Principle,这本书的不可变基础设施理论。这样你可以递进式的部署和测试新的代码,直到代码足够稳定, 高效运行,没有任何性能问题和部署失败问题的时候,你可以把代码 Merge 回之前的服务,完成新功能的开发。


为每个微服务提供独立的构建


Netflix 微服务架构设计的经验总结!_第3张图片


为每个微服务提供独立的构建,这样每个服务可以构建,独立发布,其他的服务依赖你的知识 Release 仓库里的某一个版本,他可以自行决定是升级你的最新版本,还是继续使用旧版本。这样带来的是小团队的独立性,每个团队可以自己决定发布的周期,自己负责线上的问题。


组织结构变化


Netflix 微服务架构设计的经验总结!_第4张图片


在微服务架构中,除了应用的重构,组织的结构也会发生变化,为了让微服务的团队实现独立自运营,公司必须成立专门的基础平台部门,也叫 SRE,这个部门为公司的研发团队提供统一的制品库管理,CI 工具(Jenkins 等),部署工具和运维,监控平台,以及应用的高可用保障。这样每个团队才能做到独立发布自己的服务。


部署到容器


部署微服务到容器里很重要,因为这意味着你只需要一个工具即可部署所有内容。一旦将微服务放在容器里,容器部署工具便知道如何部署它,无需考虑容器是什么类型。


视服务器为无状态


对待服务器,特别是直接服务于用户的服务器,应该把它看成是一个原子服务里的某个持续变化的成员,你不需要去单独的考虑某个机器的状态,他们都应该提供一样的功能,无需区别对待。


你唯一应该考虑的是他们能否支撑你的业务量。你可以使用自动扩容的方式将这些服务启动或者关闭。如果其中某个服务 Down 掉了,应该由新的实例来进行替代。一定要避免某个服务存在特殊的功能,从而成为单点故障点。


Cockcroft 的理论是:你应该将服务器看成是奶牛场里的牛,而不是宠物。单个的奶牛是用唯一编号标记,而宠物用名字标记。如果你的机器使用名字标记,并且处理某种特殊的应用,如果这个机器 Down 掉了,所有人都会受到影响。


相反,如果你将机器看成是奶牛场里的奶牛, 你只关心每天生产出多少牛奶,如果某天发现牛奶产量比平时少了,你只需找到这头有问题的奶牛,把它替换掉。


基于 NGINX 平台的 Netflix 部署架构


Netflix 是开源版 NGINX 的资深用户。2011年,Netflix 也成为 NGINX 公司的第一个企业用户,作为高性能 HTTP 处理的方案,NGINX and NGINX Plus 已经为 Netflix 公司提供每秒几千-几百万并发请求的支持。


参考资料:

https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/


作者:王青

目前任职 JFrog 中国首席架构师,之前在 IBM,HPE,爱奇艺,新浪,VIPKID 等公司做过研发和架构,是有十多年开发经验的互联网老兵,专注于软件生命周期管理,微服务架构,云原生应用,容器化等领域。

欢迎转载,但转载请注明作者与出处。谢谢!


你可能感兴趣的:(Netflix)