PDF微服务的隐藏红利
微服务并非适用于每家公司，而且这个过程并非易事。
汤姆·基拉莱亚
微服务是一种构建分布式系统的方法，其中服务仅通过强化的 API 公开；服务本身围绕特定且界限明确的上下文或责任领域具有高度的内部内聚性，并且它们之间的耦合是松散的。这些服务通常很简单，但它们可以组合成非常丰富和精致的应用程序。采用基于微服务的方法所需的工作量相当大，尤其是在涉及从更单体架构迁移的情况下。然而，微服务的显式优势是众所周知的且数量众多，并且可以包括提高敏捷性、弹性、可扩展性和开发者生产力。本文确定了微服务的一些隐藏红利，实施者应有意识地努力收获这些红利。
推动微服务发展势头的最根本好处是关注点的清晰分离，使每个服务的注意力都集中在整个应用程序的某个明确定义的方面。这些服务可以以新颖的方式组合，服务之间采用松耦合，并且可以独立部署。许多实施者都被能够更频繁地进行更改且降低负面影响风险的诱惑所吸引。罗伯特·C·马丁描述了单一职责原则：“将那些因相同原因而改变的事物聚集在一起。将那些因不同原因而改变的事物分开。”5 关注点的清晰分离、跨关注领域的最小耦合以及更高的变更率潜力，可以提高业务敏捷性和工程速度。
马丁·福勒认为，采用持续交付和将基础设施视为代码比转向微服务更重要，一些实施者在实施微服务的过程中采用了这些实践，对弹性、敏捷性和生产力产生了积极影响。微服务的另一个关键好处是，它可以使整个架构的不同部分的拥有者能够在持久性机制选择、一致性和并发性等构建大规模分布式系统的难题方面做出非常不同的决策。这赋予了服务所有者更大的自主权，可以更快地采用新技术，并允许他们追求可能仅对少数甚至仅对一项服务最佳的自定义方法。
红利
虽然基于微服务的方法难以实施，但它可以为付出努力的组织带来红利，尽管其中一些好处并不总是显而易见的。以下是对一些不太明显的红利的描述，这些红利可能使采用微服务值得付出努力。
红利 #1：无许可创新
无许可创新是关于“其他人在我们创建的通信结构之上创建新事物的能力”1，正如 IETF（互联网工程任务组）主席 Jari Arkko 所提出的。当启用时，它可以导致接口的消费者进行创新，而这些接口的设计者可能会发现这些创新令人惊讶甚至困惑。它与那些在考虑集成之前必须咨询守门人（阻碍者的委婉说法）的方法形成对比。
为了确定无许可创新是否已尽可能地释放，一个简单的测试是查看团队之间（与团队内部不同）会议的普遍程度。跨团队会议表明服务接口的协调、耦合以及粒度或功能存在问题。如果工程师可以避免会议，他们就不会寻求会议；此类会议可能意味着服务的 API 并非集成所需的一切。拥抱无许可创新的组织应该具有较高的实验率和较低的跨团队会议率。
红利 #2：容许失败
听到在计算机科学领域，我们仍然不知道如何构建可靠运行的复杂系统，6并且系统的不可靠性随着规模和复杂性的增加而增加，这应该不足为奇。虽然关于微服务是否可以降低整体复杂性的观点各不相同，但值得接受微服务通常会增加故障数量的观点。此外，跨服务边界的故障将更难以排除故障，因为外部调用堆栈本质上比内部调用堆栈更脆弱，并且调试任务受到较差的工具和更具挑战性的临时分析特性的限制。@Honest_Update 的这条推文有时会让人感到非常准确：“我们用微服务取代了我们的单体应用，这样每次宕机都更像是一场谋杀之谜。”4
为故障的必然性和日常性而设计可以引发关于状态持久性、弹性、依赖项管理、共同命运和优雅降级的健康对话。此类对话应通过利用缓存、计量、流量工程、节流、负载脱落和退避等技术来减少任何给定故障的爆炸半径。在成熟的基于微服务的架构中，应该预期单个服务会发生故障，而所有服务的级联故障应该是不可能的。
红利 #3：打破信任
在小型公司或小型代码库中，一些工程师可能对正在部署的内容有强烈的信任感，因为他们会关注每个人的工作并审查每次提交。随着团队规模和总体速度的增加，“邓巴数”开始生效，导致这种信任变得紧张。正如英国人类学家罗宾·邓巴所定义的，这是一个人可以通过个人接触维持社会关系的最大人数。
转向微服务可以迫使这种信任期望浮出水面并受到质疑。一个服务和另一个服务之间的边界变成了一组 API。消费者放弃了对这些 API 背后设计、设计如何演变以及数据如何持久化的影响，以换取一组管理 API 稳定性和运行时特性的 SLA（服务级别协议）。信任可以被自主性和问责制的结合所取代。
正如定义了现在被称为康威定律的梅尔文·康威所说：“任何设计系统的组织都不可避免地会产生一个设计，其结构是该组织沟通结构的副本。”2
微服务可以为超越个人接触限制的不断发展的组织提供有效的模型。
红利 #4：你构建，你拥有
微服务鼓励“你构建，你拥有”模型。亚马逊首席技术官沃纳·沃格尔斯在 2006 年与吉姆·格雷的对话中描述了这种模型，该对话发表在 上：“每个服务都有一个与之相关的团队，该团队完全负责该服务——从确定功能范围，到架构设计，再到构建和运营它。你构建它，你运行它。这使开发人员与他们软件的日常运营联系起来。这也使他们与客户进行日常接触。客户反馈循环对于提高服务质量至关重要。”3
自那次对话以来的十年中，随着越来越多的软件工程师遵循这种模型并承担起微服务的运营和开发责任，他们推动了许多实践的广泛采用，这些实践实现了更高的自动化并降低了运营开销。其中包括持续部署、虚拟化或容器化容量、自动化弹性以及各种自愈技术。
红利 #5：加速弃用
在单体应用中，很难安全地弃用任何东西。借助微服务，可以很容易地清楚地了解服务的调用量，启动不同且可能相互竞争的服务版本，或者构建一个与旧服务没有任何共享的新服务，除了与消费者最关心的那些接口向后兼容之外。
在无许可创新的世界中，服务可以并且应该例行地来来去去。值得投入一些精力来使弃用那些没有有意义地流行起来的服务变得更容易。做到这一点的一种方法是为资源提供足够高的竞争程度，以便任何负责停滞不前的服务的资源受限团队都被吸引将大部分时间花在对客户更重要的其他服务上。随着这种情况的发生，不成功服务的责任应转移给最关心它的消费者。这个团队可能会理所当然地认为自己“接手了烂摊子”，尽管弃用决定也传递到了他们手中。不希望接手烂摊子的其他团队有额外的动力来迁移或终止他们的依赖项。这听起来可能很残酷，但它是“快速失败”的重要组成部分。
红利 #6：结束集中式元数据
在亚马逊的早期，少量的关系数据库被用于公司所有关键的事务数据。为了数据完整性和性能，任何提议的模式更改都必须经过 DB Cabal 的审查和批准，DB Cabal 是一个由善意的企业建模人员、数据库管理员和软件工程师组成的守门团体。借助微服务，消费者不应该知道或关心他们所依赖的一组 API 背后的数据如何持久化，而且实际上应该可以交换一种持久性机制以获得另一种机制，而无需消费者注意到或需要被通知。
红利 #7：集中痛苦
转向微服务应该使组织能够对不同服务的治理期望采取截然不同的方法。这将从公司范围内一致的数据分类模型以及不同业务流程完整性的重要性分类开始。这通常会导致对处理最重要数据和流程的服务进行威胁建模，并实施必要的控制措施以满足公司的安全和合规性需求。随着微服务的激增，可以确保最严格的合规性负担集中在极少数服务中，从而使其余服务能够以更高的创新率发展，相对不受此类问题的困扰。
红利 #8：以不同的方式测试
工程团队通常将转向微服务视为以不同方式思考测试的机会。通常，他们会开始思考如何在设计阶段的早期进行测试，在他们开始构建服务之前。更清晰的所有权和范围定义可以激励实现更高的覆盖率。正如 Yelp 在阐述其服务原则时所说，“你的接口是最重要的测试组件。你的接口测试将告诉你你的客户端实际看到的内容，而你剩余的测试将告诉你如何确保你的客户端看到这些结果。”7
采用持续部署、冒烟测试和分阶段部署等实践可以带来更高保真度的测试，并在生产中发现问题时缩短修复时间。一组测试的有效性可以较少地通过其问题检测率来衡量，而更多地通过它们实现的变更率来衡量。
警告信号
以下指标有助于确定微服务之旅尚未完成。如果你有以下情况，你可能不是在做微服务：
• 不同服务进行协同部署。
• 你交付客户端库。
• 一个服务中的更改会对其他服务产生意外后果或需要更改其他服务。
• 服务共享持久性存储。
• 你无法在无人关心的情况下更改服务的持久性层。
• 工程师需要深入了解其他团队服务的设计和模式。
• 你的合规性控制统一适用于所有服务。
• 你的基础设施不可编程。
• 你无法进行一键部署和回滚。
结论
微服务并非适用于每家公司，而且这个过程并非易事。有时，关于采用微服务的讨论过于热情，侧重于自主性、敏捷性、弹性和开发者生产力。然而，好处不止于此，为了使这个过程值得付出，重要的是收获额外的红利。
参考文献
1. Arkko, J. 2013. 无许可创新。IETF； https://www.ietf.org/blog/2013/05/permissionless-innovation/.
2. Conway, M. E. 1968. 委员会如何发明？Datamation Magazine; http://www.melconway.com/Home/Committees_Paper.html.
3. Gray. J. 2006. 与沃纳·沃格尔斯的对话。 4(4); https://queue.org.cn/detail.cfm?id=1142065.
4. Honest Status Page. 2015. @honest_update; https://twitter.com/honest_update/status/651897353889259520.
5. Martin, R. C. 2014. 单一职责原则； http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html.
6. Perera, D. 2015. 加密战士。Politico; http://www.politico.com/agenda/story/2015/12/crypto-war-cyber-security-encryption-000334.
7. Yelp 服务原则； https://github.com/Yelp/service-principles.
汤姆·基拉莱亚 在亚马逊工作了 16 年，现在担任顾问，并在多家公司董事会任职，包括 Capital One、ORRECO 和 MongoDB。
版权 © 2016 归所有者/作者所有。出版权已许可给 。
queue.acm.org 上的相关内容
与沃纳·沃格尔斯的对话
https://queue.org.cn/detail.cfm?id=1142065
分布式系统的验证
- 凯蒂·麦卡弗里
https://queue.org.cn/detail.cfm?id=2889274
就是无法绕过它：你正在构建一个分布式系统
- 马克·卡瓦格
https://queue.org.cn/detail.cfm?id=2482856
最初发表于 Queue 第 14 卷，第 3 期—
在 数字图书馆 中评论本文
更多相关文章
尼克拉斯·布鲁姆，塞尔日·拉夏佩尔，哈拉尔德·阿尔韦斯特兰德 - WebRTC - 开放 Web 平台的实时通信
在这个疫情时期，世界比以往任何时候都更依赖于基于互联网的 RTC（实时通信）。过去十年中，RTC 产品的数量呈爆炸式增长，这在很大程度上是由于更便宜的高速网络接入和更强大的设备，但也归功于一个名为 WebRTC 的开放、免版税平台。WebRTC 正在从支持有用的体验发展到在疫情期间对于让数十亿人继续工作和教育，并保持重要的人际接触至关重要。WebRTC 未来的机遇和影响确实令人着迷。
本杰明·特雷诺·斯洛斯，沙拉贾·努卡拉，维韦克·劳 - 重要的指标
衡量你的站点可靠性指标，设定正确的目标，并努力准确地衡量这些指标。然后，你会发现你的服务运行得更好，宕机次数更少，用户采用率也更高。
西尔维娅·埃斯帕拉奇亚里，塔尼娅·雷利，阿什利·伦茨 - 跟踪和控制微服务依赖项
如果你曾经把钥匙锁在房子或车里，你就会熟悉依赖循环。没有钥匙你无法打开锁，但没有打开锁你无法拿到钥匙。有些循环很明显，但更复杂的依赖循环可能很难在它们导致宕机之前找到。跟踪和控制依赖项的策略对于维护可靠的系统是必要的。
迪普塔努·贡·乔杜里，蒂莫西·佩雷特 - 为互联网规模的服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的运营商如何配置补救策略，同时帮助租户系统在租户系统所有者进行故障排除期间尽可能保持稳定。
© 保留所有权利。