Netflix采用微服务的实践：架构设计经验

NGINX | 2015年2月19日

在近期的一些博客文章中，我们解释了为何认为采用四层应用架构至关重要。在这种架构中，应用以一组微服务的形式进行开发和部署。越来越明显的是，如果继续沿用十年前尚且适用的开发流程和应用架构，就无法足够迅速地采取行动，吸引并持续留住移动用户；而他们可选择的应用数量还在不断增加。

转向微服务架构可为企业带来令人振奋的市场机遇。对于系统架构师和开发人员而言，这有望让他们在为客户提供创新的全新Web体验时，获得前所未有的掌控力和速度。但在如此快的节奏下，似乎几乎没有犯错的余地。实际工作中，在重构应用开发和部署流程的同时，不能停止开发和部署应用。未来的成功取决于向微服务架构转型，但究竟该如何实现？

值得庆幸的是，一些率先采用微服务的企业如今正秉持开源精神，慷慨分享其专业经验，不仅发布代码，还通过会议演讲和博客文章进行分享。Netflix就是其中一个典型案例。Adrian Cockcroft先后担任Web工程总监和云架构师，负责推动公司转型：从由100名工程师采用传统开发模式构建单体DVD租赁应用，转向微服务架构，由多个小型团队负责数百个微服务的端到端开发。这些微服务协同工作，每天为数百万Netflix客户提供数字娱乐流媒体服务。如今，Cockcroft担任Battery Ventures技术研究员，是微服务和云原生架构领域颇具影响力的倡导者，同时也是NGINX技术顾问委员会成员。

在这个分为上下两篇的博客系列中，我们将重点介绍Cockcroft去年两次演讲中的主要观点：一次是10月举行的首届NGINX大会，另一次是几个月前举行的硅谷微服务聚会。（完整的视频录像也很值得观看。）

本文介绍微服务架构的定义，并概述其设计方面的一些良好实践。
Netflix采用微服务：团队与流程设计经验探讨了为何以及如何采用新的软件开发思维，并据此重组团队。

什么是微服务架构？

Cockcroft将微服务架构定义为一种由具有有界上下文的松耦合元素组成的面向服务架构。

松耦合意味着可以独立更新各项服务；更新一项服务不需要更改任何其他服务。如果有许多小型的专用服务，但仍必须一起更新，那么它们就不是微服务，因为它们并非松耦合。在向微服务架构过渡时，人们往往会忽视一种耦合，即数据库耦合。在这种情况下，所有服务都与同一个数据库通信，更新一项服务就意味着需要更改数据库架构。需要拆分数据库并对其进行反规范化。

“限界上下文”这一概念源自Eric Evans所著的《领域驱动设计》。在软件开发中，正确划定上下文边界的微服务是自包含的。无需了解其他微服务的内部机制，即可理解和更新该微服务的代码，因为该微服务与其他微服务仅通过API交互，不共享数据结构、数据库模式或对象的其他内部表示形式。

如果您开发过互联网应用，那么即使叫不出这些概念的名称，也已经在实践中熟悉它们。大多数移动应用都会与多个后端服务通信，让用户无需离开应用即可完成分享到Facebook、通过Google Maps获取路线，以及在Foursquare上查找餐厅等操作。如果移动应用与这些服务紧密耦合，那么每次发布更新前，都必须与所有相关开发团队沟通，确保所做的更改不会导致任何问题。

采用微服务架构时，应将其他内部开发团队视为类似互联网后端的外部服务，您的微服务通过API与这些服务交互。微服务之间普遍认可的“契约”是，其API应保持稳定并具备向前兼容性。正如Google Maps API不能在毫无预警的情况下更改并导致用户应用出现故障一样，您的API可以演进，但必须与先前版本保持兼容。

微服务架构设计实践指南

Cockcroft表示，他作为Netflix云架构师的职责并非控制架构，而是发现并规范Netflix工程师在构建过程中逐步形成的架构。Netflix开发团队总结了多项设计和实施微服务架构的良好实践。

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

不要让多个微服务共用同一个后端数据存储。应让每个微服务的团队选择最适合该服务的数据库。此外，如果只使用一个数据存储，不同团队开发的微服务很容易共用数据库结构，或许是为了减少重复工作。这样一来，如果一个团队更新了某个数据库结构，其他使用该结构的服务也必须随之更改。

拆分数据可能会增加数据管理的复杂性，因为各个独立的存储系统更容易出现不同步或不一致的情况，外键也可能发生意外变化。需要添加一个在后台运行的工具来执行主数据管理（MDM），以发现并修复不一致问题。例如，该工具可以检查存储订阅者ID的每个数据库，验证所有数据库中是否存在相同的ID（即任何一个数据库中都没有缺失或多余的ID）。可以自行开发或购买此类工具。许多商用关系数据库管理系统（RDBMS）都能执行这类检查，但它们通常会提出过多的耦合要求，因此难以扩展。

保持代码成熟度相近

将微服务中的所有代码保持在相近的成熟度和稳定性水平。换言之，如果需要在一个已部署且运行良好的微服务中添加或重写部分代码，通常更合适的做法是为新增或变更的代码创建一个新的微服务，同时保留现有微服务。［编者注：这有时称为“不可变基础设施”原则。］这样，便可反复部署和测试新代码，直至其没有缺陷并达到较高效率，同时避免现有微服务出现故障或性能下降的风险。当新微服务达到与原微服务相同的稳定性后，如果二者确实共同执行一项功能，或者合并能提高其他方面的效率，则可以将它们重新合并。不过，根据Cockcroft的经验，更常见的情况是，微服务变得过于庞大，因此需要将其拆分。

为每个微服务单独构建

为每个微服务单独构建，使其能够从存储库中拉取适合自身修订级别的组件文件。这样有时会导致不同微服务拉取一组相似的文件，但文件的修订级别各不相同。这会增加停用旧文件版本以清理代码库的难度（因为需要更仔细地确认某个修订版本已不再使用），但考虑到构建新微服务时可以轻松添加新文件，这种取舍是可以接受的。这种不对称是有意为之：引入新的微服务、文件或函数应当简单易行，而不应带来风险。

在容器中部署

在容器中部署微服务非常重要，因为这样只需一种工具即可部署所有微服务。只要微服务位于容器中，该工具就知道如何部署，无论使用哪种容器都没有影响。尽管如此，Docker似乎很快就成为了事实上的容器标准。

将服务器视为无状态

将服务器（尤其是运行面向客户的代码的服务器）视为组内可互换的成员。它们执行相同的功能，因此无需逐一关注。只需确保服务器数量足以处理所需的工作负载，并可使用自动扩缩容来增减数量。如果某台服务器停止工作，系统会自动用另一台服务器替换。避免使用依赖单台服务器执行专门功能的“雪花式”系统。

Cockcroft的比喻是，应把服务器视为牲畜，而不是宠物。如果生产环境中有一台机器承担专门功能，大家都知道它的名字，而且它一旦停机，所有人都会难过，那它就是宠物。相反，应把服务器看作一群奶牛。真正需要关注的是能产出多少牛奶。如果有一天发现牛奶产量低于平时，就找出产奶量不佳的奶牛并将其替换。

Netflix交付架构基于NGINX构建

Netflix长期使用NGINX Open Source，并在NGINX, Inc.于2011年成立后成为其首位客户。事实上，Netflix选择NGINX作为其交付基础设施Open Connect的核心。Open Connect是全球规模较大的内容分发网络（CDN）之一。NGINX和NGINX Plus每秒可处理数千甚至数百万个请求，是高性能HTTP交付的理想解决方案，可帮助Netflix等公司每天为数百万客户提供高质量的数字体验。