本文讲的是微服务的隐性红利：你不知道的8个好处【编者的话】微服务未必适用于所有公司，实施过程也并非易事。之前大家讨论是否采用微服务时的重点主要在于它的自主性、敏捷性、弹性和开发者的生产能力。但这并不是微服务的所有优点，本文中提到的这些额外的好处也是值得利用的。
微服务未必适用于所有公司，实施也并非易事 。
作为构建分布式系统的一种方式，微服务可以做到只用hardened API提供服务。围绕特定、有界的上下文或责任范围，这些服务具有高内聚低耦合的特点。这些服务通常很简单，但却可以构成非常丰富和复杂的应用。采用基于微服务的新方式需要付出相当大的努力，特别是从monolithic架构迁移过来的例子就更加麻烦。微服务有很多优点都是众所周知，其中不乏敏捷性、弹性、可伸缩性、可扩展性和开发效率高。本文将指微服务不为人所知的一些优点，或者说是隐性的红利，实施者应该有意识的去利用。
在微服务背后最基本的利益驱动是清晰地分离关注点，将每项服务的注意力集中在应用的某些定义清晰（well-defined）的地方。这些服务能以低耦合的方式组合，并具有独立部署能力。许多人都被其能够频繁、低风险改动的性能吸引。Robert C. Martin这样描述单一职责原则（ single responsibility principle ）：“ 将改变原因相同的聚一起，将改变原因不同的相分离 。”明确的分离关注点，关注点间的耦合最小化，以及潜在的高变动率导致业务敏捷性和工程速度的提升。
Martin Fowler认为，比起迁移到微服务上去，持续交付和用代码处理基础设施更重要。一些人在实施过程中采取了这些方法，由此带来了有弹性，灵活性和生产力较高的积极影响。微服务的另一个好处是，它允许架构各部分的拥有者在构建大规模分布式系统时选择不同的机制，同时顾及到持久性机制的选择、一致性和并发。这给各服务更多自主权，有助于快速适用新技术，允许仅向一部分或者某一个服务提供定制方法。
有一个简单的测试可以分辨“无需许可的创新”已经达到的程度，那就是跨团队会议（和队内会议不同）的流行程度。跨团队会议意味着服务接口的协调、耦合和粒度或功能问题。工程师们会尽量避免开会，这样的会议意味着需要整合的并不只是某服务的API。接受了”无需许可的创新 ”概念的团队应该具有高实验率和低跨团队会议率。
不可避免的、常规的故障会引起人们关于状态持久性、弹性、依赖管理、功能降低等方面的探讨。通过利用高速缓存、计量、流量控制、节流、减负荷和回退等技术，这些探讨可以减少特定故障的影响范围。在基于微服务的成熟架构中，个别服务的故障应该是意料之中的，但所有服务的级联故障应该不可能出现。
微服务可能会让团队信任面临新的问题。服务之间的边界变成一组API。用户不再影响API背后的设计、设计如何演变以及数据如何存在，而是要获取一组SLA（service-level agreement 服务层协议）来控制API的稳定性和运行特征。原来的信任可能会被自治权和问责制所取代。
Conway定律的定义者Melvin Conway说, “任何组织设计出的系统最终都会与该组织的沟通结构相匹配。”
微服务可以为组织提供一个高效模型，使其规模远大于个人接触范围的限制。
此番谈话之后的十年中，越来越多的软件工程师按照这个模型工作，也担上了更多责任，于此同时 ，随着微服务的发展，他们采取了一些方法去获得更高的自动化程度，并降低运营开销。 这些方法中就有持续部署、虚拟化或容器化，增强弹性，以及各种自修复技术。
在无需许可的情况下，服务的变更应该是常规化的。我们要努力将关闭不常用服务变得更简单。一种方法是，有足够高的资源竞争水平，这样才能保证在资源有限的团队中，可以把更多精力从衰败的服务中抽离出来，放到对用户来说更重要的服务中去。这种情况下，需要对这些不成功的服务负责的人，就变成了最在意这些服务的用户。被关掉服务的团队理所当然的认为这种情况实属无奈，尽管他们也参与了关闭服务的决定。而不希望遇到这种无奈情况的团队则会主动迁移或者终止依赖。听起来很残酷，但这是“快速失败”很重要的一部分。
亚马逊的早期，少量的关系数据库被用于公司的所有关键的交易数据。在数据的完整性和性能的利益，任何提出的架构更改必须审查和批准的DB集团，一个守门组好心的企业建模、数据库管理员、软件工程师。与精卫，消费者不知道或关心数据如何坚持背后的一套API它们所依赖的，确实应该可以换出另一个持久化机制没有消费者注意或者需要被通知。
采用诸如持续部署，烟雾测试和阶段部署等方法可以使测试保真度更高，同时降低生产问题出现时的修复时间。测试的效率更多的是由可以由修复问题的速度来描述，而不是发现问题的速度。
微服务未必适用于所有公司，实施也并非易事 。
作为构建分布式系统的一种方式，微服务可以做到只用hardened API提供服务。围绕特定、有界的上下文或责任范围，这些服务具有高内聚低耦合的特点。这些服务通常很简单，但却可以构成非常丰富和复杂的应用。采用基于微服务的新方式需要付出相当大的努力，特别是从monolithic架构迁移过来的例子就更加麻烦。微服务有很多优点都是众所周知，其中不乏敏捷性、弹性、可伸缩性、可扩展性和开发效率高。本文将指微服务不为人所知的一些优点，或者说是隐性的红利，实施者应该有意识的去利用。
在微服务背后最基本的利益驱动是清晰地分离关注点，将每项服务的注意力集中在应用的某些定义清晰（well-defined）的地方。这些服务能以低耦合的方式组合，并具有独立部署能力。许多人都被其能够频繁、低风险改动的性能吸引。Robert C. Martin这样描述单一职责原则（ single responsibility principle ）：“ 将改变原因相同的聚一起，将改变原因不同的相分离 。”明确的分离关注点，关注点间的耦合最小化，以及潜在的高变动率导致业务敏捷性和工程速度的提升。
Martin Fowler认为，比起迁移到微服务上去，持续交付和用代码处理基础设施更重要。一些人在实施过程中采取了这些方法，由此带来了有弹性，灵活性和生产力较高的积极影响。微服务的另一个好处是，它允许架构各部分的拥有者在构建大规模分布式系统时选择不同的机制，同时顾及到持久性机制的选择、一致性和并发。这给各服务更多自主权，有助于快速适用新技术，允许仅向一部分或者某一个服务提供定制方法。
好处
虽然很难实现，但基于微服务的方法还是给组织带来了很多好处，尽管有些并不明显。以下将列出一些不那么明显的好处，但足以说明采用微服务时付出的努力都是值得的。好处1：无需许可的创新（Permissionless Innovation）
无需许可的创新即“ 他人在我们创造的通信结构之上进行创新的能力 ”，这个概念由IETF (Internet Engineering Task Force)的主席，Jari Arkko提出。如果一切成熟，接口用户的创新将震惊接口的设计者。这与那些整合前需要咨询 gatekeeper （ blocker 的委婉用法）的方法不同。有一个简单的测试可以分辨“无需许可的创新”已经达到的程度，那就是跨团队会议（和队内会议不同）的流行程度。跨团队会议意味着服务接口的协调、耦合和粒度或功能问题。工程师们会尽量避免开会，这样的会议意味着需要整合的并不只是某服务的API。接受了”无需许可的创新 ”概念的团队应该具有高实验率和低跨团队会议率。
好处2：常规故障（Enable Failure）
计算机科学中，我们仍不知道如何构建能够稳定工作的复杂系统，而且不稳定性和系统的规模和复杂性成正比。 尽管在关于微服务是否能够减少整体复杂性上有所争议，但微服务将会增加故障的次数，这个观点还是值得接受的。进一步来说，跨服务边界的故障将更难修补，因为外部调用堆栈本质上就比内部调用更加脆弱，而且调试任务会受限。 @ honest_update的一条推文有时会让人感到不舒服： “我们用微服务替代了monolith，搞得现在每次中断都像一次神秘谋杀。”不可避免的、常规的故障会引起人们关于状态持久性、弹性、依赖管理、功能降低等方面的探讨。通过利用高速缓存、计量、流量控制、节流、减负荷和回退等技术，这些探讨可以减少特定故障的影响范围。在基于微服务的成熟架构中，个别服务的故障应该是意料之中的，但所有服务的级联故障应该不可能出现。
好处3：不再依赖小团队间的信任（Disrupt Trust）
在小公司或者代码基础较小的情况下，工程师们对部署工作心怀信任，因为他们可以查看每一个人的每一次交付。当团队规模和总速度增加时，“邓巴数字”（即150定律）就开始起作用了，这种信任也开始变得紧张。正如英国人类学家Robin Dunbar所定义的那样，这是个人通过直接接触可以维持的最大社交关系数量。微服务可能会让团队信任面临新的问题。服务之间的边界变成一组API。用户不再影响API背后的设计、设计如何演变以及数据如何存在，而是要获取一组SLA（service-level agreement 服务层协议）来控制API的稳定性和运行特征。原来的信任可能会被自治权和问责制所取代。
Conway定律的定义者Melvin Conway说, “任何组织设计出的系统最终都会与该组织的沟通结构相匹配。”
微服务可以为组织提供一个高效模型，使其规模远大于个人接触范围的限制。
好处4：负责到底（You Build It, You Own It）
微服务宣扬“谁构建，谁负责”这样的模型。亚马逊CTO Werner Vogels在2006年与Jim Gray的谈话中这样描述该模型，这段对话在 ACM Queue 上刊登过。 “每一个服务都有一个对应的团队，这个团队对该服务完全负责，从琢磨功能，设计结构，实现，到运营。谁构建，谁运行。这让开发者们日复一日的与软件之间发生联系，也让他们日复一日地与用户发生着联系。用户们的反馈对推动服务质量来说至关重要。”此番谈话之后的十年中，越来越多的软件工程师按照这个模型工作，也担上了更多责任，于此同时 ，随着微服务的发展，他们采取了一些方法去获得更高的自动化程度，并降低运营开销。 这些方法中就有持续部署、虚拟化或容器化，增强弹性，以及各种自修复技术。
好处5：加速关闭（Accelerate Deprecations）
在monolith架构中，很难安全关闭某一部分。但在微服务中，可以清晰提取出服务中的某列，建立起更有竞争潜力的新版本服务，或者构建一个与原版本完全不同但向后兼容重要接口的新服务。在无需许可的情况下，服务的变更应该是常规化的。我们要努力将关闭不常用服务变得更简单。一种方法是，有足够高的资源竞争水平，这样才能保证在资源有限的团队中，可以把更多精力从衰败的服务中抽离出来，放到对用户来说更重要的服务中去。这种情况下，需要对这些不成功的服务负责的人，就变成了最在意这些服务的用户。被关掉服务的团队理所当然的认为这种情况实属无奈，尽管他们也参与了关闭服务的决定。而不希望遇到这种无奈情况的团队则会主动迁移或者终止依赖。听起来很残酷，但这是“快速失败”很重要的一部分。
好处6：端集中式元数据（End Centralized Metadata）
在亚马逊的早年，一小部分关系型数据库用来存储种鸽公司的关键交易数据。考虑到数据的完整性和性能利益，任何提交的架构更改都需要经过DB Cabal的审核通过。DB Cabal是由一群企业建模精英，数据库管理员和软件工程师组成的把关团队。有了微服务，用户不需要也不用再关心API背后的数据是如何持久存在的。事实上，置换持久机制这种事可能并不需要用户洞悉。亚马逊的早期，少量的关系数据库被用于公司的所有关键的交易数据。在数据的完整性和性能的利益，任何提出的架构更改必须审查和批准的DB集团，一个守门组好心的企业建模、数据库管理员、软件工程师。与精卫，消费者不知道或关心数据如何坚持背后的一套API它们所依赖的，确实应该可以换出另一个持久化机制没有消费者注意或者需要被通知。
好处7：集中痛点（Concentrate the Pain）
采用微服务的组织可以按需以不同方式处理不同服务。这需要公司整体的数据分类模型保持一致，并与公司不同业务的完整性关键流程分类。这对服务建模来说是个挑战，毕竟服务要处理重要的数据和过程，实施控制对公司安全性和必要的合规性来说都非常重要。随着微服务的增长，最受规则限制的负担可以集中于一小部分服务上，从而放松了创新率更高的其他服务。好处8：新的测试方式（Test Differently）
工程师们经常将实施微服务看做改变测试方式的契机。通常，他们会开始思考，在构建服务之前，怎样在设计阶段开始早期测试。所有权和范围的清晰定义有助于扩大覆盖范围。正如Yelp在阐述服务原则时所说， “你的接口是测试中最终要的部分。你的接口测试会告诉你用户真正看到的东西，但其他测试会告诉你怎样保证用户能够看到这些结果。”采用诸如持续部署，烟雾测试和阶段部署等方法可以使测试保真度更高，同时降低生产问题出现时的修复时间。测试的效率更多的是由可以由修复问题的速度来描述，而不是发现问题的速度。
提示
以下指标可以判断你采用的微服务是否完整。如果发现有下列问题，那么你还没有做到真正的微服务：- 不同服务需要协调部署。
- You ship client libraries。
- 一个服务中的变动会引起其他服务中的变动或导致意料外的后果。
- 多个服务共享持久存储。
- 不能随意更改服务持久层。
- 工程师需要精通其他团队服务的设计和架构。
- 你拥有适用于所有服务的合规控制权。
- 基础设施不可编程。
- 不能一键部署和复原。
结论
微服务未必适用于所有公司，实施过程也并非易事。之前大家讨论是否采用微服务时的重点主要在于它的自主性、敏捷性、弹性和开发者的生产能力。但这并不是微服务的所有优点，本文中提到的这些额外的好处也是值得利用的。原文链接：The Hidden Dividends of Microservices（翻译：马远征）
原文发布时间为：2016-08-29
本文作者：马远征
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：微服务的隐性红利：你不知道的8个好处
