引言：微服务并不适用于每个公司，而且实现微服务化的过程也并不容易。但是，实现微服务除了明显优势之外，还有一些隐性的收益值得关注。本文编译自 Tom Killalea的一篇旧文 https://queue.acm.org/detail.cfm?id=2956643，融入了一点儿个人的理解。
微服务是一种构建分布式系统的方法，在微服务系统中，服务只能通过API来公开，这是一个API的世界(可以参考没有被了解的API?一个老码农眼中的API世界)。在微服务的世界里，服务本身在特定且有良好界限的场景下或职责区域具有高度的内聚性，而且服务之间是松耦合的。这样的微服务通常很简单，但是它们可以组合成非常丰富且复杂的应用。采用微服务的构建方法所需的工作量相当大，特别是从单体架构迁移的时候。然而，微服务的好处众多，众所周知的优势包括敏捷性的增强、弹性、可伸缩性和开发人员的生产力。本文指出了微服务的一些隐性收益，我们或许应该有意识地努力收获这些收益。
微服务带来的最基本好处是明确地分离服务，将每个服务的关注点集中在整个应用中的某个明确定义的位置。这些服务可以通过服务之间的松耦合以新颖的方式组合，并可以独立部署。清晰的关注点分离，跨领域的最小耦合，以及更高变化率的潜力导致业务灵活性和工程速度的提高。许多人都被微服务架构能够更频繁地做出改变且减少负面影响的诱惑所吸引。
通过持续交付和基础设施的可编程化，这些实践在实现微型服务的过程中对弹性、敏捷性和生产力产生了积极的影响。微服务的另一个关键好处是，它们可以使整个体系结构的不同部分的所有者在持久性机制选择、一致性和并发性方面对构建大规模分布式系统做出非常不同的决策。这给了服务所有者更大的自主权，可以导致更快地采用新技术，并且可以允许他们追求定制的方法，这些方法可能只对少数服务，甚至只对一个服务是最佳的。
虽然微服务有实现上的难度，但是可以为那些麻烦的组织带来好处，尽管其中一些收益并不是显而易见的。下面是一些不那么明显的好处，这些因素可能是采用微服务的额外收益。
隐性收益 # 1: 无许可创新
关于创新，可以参考《隄上创新谁述记——老码农的“创新”漫谈》和《斯须改变如苍狗——一张图的随想》，那么，什么是无许可创新呢?无许可创新是指“其他人在我们创造的通信结构之上创造新事物的能力”。
一旦启用了微服务，它可以引导业务方创新一系列的接口，应用这些接口可能使得设计者都会感到惊讶。为了确定无许可创新是否已经到了可能的程度，一个简单的测试是观察团队间会议的流行程度。跨团队会议表明了协调、耦合以及服务接口的粒度或功能问题。一个热爱无许可创新的组织应该有较高的实验率和较低的跨团队会议率。
隐性收益 # 2: 可预料的故障
在IT领域，我们仍然不知道如何构建一个工作可靠的复杂系统，这一点不足为奇，系统的不可靠性随着规模和复杂程度的增加而增加。虽然对于微服务是否能够降低整体复杂性的看法不一，但是微型服务通常会增加故障的数量是肯定的。此外，跨服务边界的故障更难以排除，因为外部调用堆栈本身比内部调用堆栈更脆弱，而且调试任务受到更糟糕的工具和更具挑战性的特定功能分析的限制。有人说：“我们用微型服务替换了原来的单体结构，于是每一次断电都可能更像是一场谋杀之谜。”
为不可避免性失败的常态而设计，可以引发关于状态持久性、弹性、依赖管理、共同命运和优雅降级的常态讨论。这样的讨论通常利用缓存、监控、分流与限流、负载减少等技术来减少任何给定故障的爆炸半径。在一个成熟的微服务体系结构中，应该预料到单个服务的故障，而所有服务的级联故障应该是不可能的。
隐性收益 # 3: 突破信任
在小公司或小型代码库中，一些工程师可能对部署的内容有强烈的信任感，因为他们会review每一个提交内容。随着团队规模的增加，“邓巴数”开始发挥作用，导致这种信任变得越来越紧张。关于邓巴数，可以参考《有意义的不只是邓巴数》。
向微服务的转型可以迫使这种信任浮出水面并面对现实。一个服务和另一个服务之间的边界是一组API。我们放弃了对这些API背后的设计、如何开发实现以及数据如何持久化的影响，以换取一组服务质量等级(SLA)来管理API的稳定性及其运行时的特性(关于SLA可以参考浅析面向云架构的SLA 以及性能，10点系统性思考)。信任可以用自治和责任的结合来取代。
微服务可以为不断发展的组织提供一个有效的模式，它的规模远远超出了“邓巴数”的限制。
隐性收益 # 4: 构建并拥有
微服务鼓励“构建并拥有它”的模式。亚马逊 CTO Werner Vogels 在2006年与 Jim Gray 的一次对话中描述了这个模型: “每个服务都有一个与之相关的团队，这个团队完全负责这个服务——从确定功能的范围，到构建它，再到运行它。也就是说，开发者建造并运行它。这使得开发人员能够接触到这些软件的日常操作，也使他们与客户进行日常接触。客户反馈回路对于提高服务质量至关重要。”
在之后的十年里，随着越来越多的软件工程师遵循这种模式，并承担起运营和开发微服务的责任，已经推动了一系列实践的广泛应用，这些实践能够实现更大程度的自动化，并降低运营成本。其中包括持续部署、虚拟化或容器化、自动弹性和各种自我修复技术。
隐性收益 # 5: 加速废弃
在一个巨型单体架构体系中，很难安全地反对任何东西。使用微型服务，则很容易获得服务调用量的清晰视图，支持服务的不同版本和潜在的竞争版本，或者建立一个除了向后兼容那些用户最关心的接口之外与旧服务不共享任何东西的新服务。
在一个无许可创新的世界里，服务可以而且应该经常变来变去。需要投入一些努力，使那些没有真正流行起来的服务变得更加容易使用。解决这个问题的一个方法是对资源进行高度的竞争，任何资源有限的团队，只要负责一项不景气的服务，就会把大部分时间花在对客户更重要的其他服务上。当这种情况发生时，服务的不成功责任应该转移到最关心它的用户身上。这个团队可能理所当然地认为自己是被留下来“顶锅扛雷” ，其他团队则不希望保留对他们的依赖关系，这样就有了迁移或终止依赖服务的额外动机。这听起来可能很残酷，但这是“快速失败”的一个重要部分。
隐性收益 # 6: 终止数据库瓶颈
在亚马逊的早期，少量的关系数据库被用于公司所有关键的事务数据。为了保证数据的完整性和性能，任何提议的模式更改都必须经过 DBA团队的审查和批准。
使用微服务后，服务使用者不应该关心数据在一组API背后是如何持久化的，而且实际上，在不需要通知的情况下，将一种持久化机制替换为另一种持久化机制应该是可能的。
隐性收益 # 7: 集中面对痛苦
向微型服务的转型应该使组织能够采取非常不同的方法来满足其对不同服务的治理期望。这将从一个一致数据分类模型和不同业务流程完整性的关键度划分开始。这通常会导致为处理最重要数据和流程的服务建立安全模型，并实施必要的控制以满足公司的安全和合规需求。
随着微服务的激增，可以确保最重要的合规负担集中在极少数服务上，从而使剩余的服务有更高的创新率，相对没有这些问题的负担。
隐性收益 # 8: 不同的测试
工程团队经常把迁移到微服务视为一个机会，可以从不同的角度考虑测试。通常，在开始构建服务之前，会开始考虑如何在设计的早期阶段进行测试。更明确地界定所有权和范围可以鼓励实现更大测试的覆盖面。正如 Yelp 在阐述其服务原则时所说的，“接口是测试中最重要的组件。接口测试将告诉客户端实际看到了什么，而其余的测试将告诉如何确保客户端看到这些结果。”
采用持续集成、持续部署、冒烟测试和灰度部署等实践，可以导致在生产中发现问题时进行高保真和低修复时间的测试。一组测试的有效性不能用发现问题的速度来衡量，而更多的是用它们所带来的变化速度来衡量。
微服务转型中的危险指标
如果我们遇到了如下的情景，说明我们的微服务转型是不完整的，甚至是危险的。这些指标至少包括包括:
- 不同的服务进行协调部署。
- 需要提供客户端库。
- 一个服务的改变会产生意想不到的后果，或甚至需要修改其他服务。
- 服务共享同一个持久性存储。
- 在没人帮助的情况下，你不能改变自己服务的持久化层。
- 工程师需要对其他团队服务的设计和模式有深入的了解。
- 有一个统一适用于所有服务的合规控制。
- 基础设施不可编程。
- 不能进行一键式的部署和一键式回滚。
结束语
微服务并不适用于每个公司，这个微服务的实现过程也并不容易。因此，关于采用微服务的讨论往往非常热烈，主要集中在自主性、敏捷性、弹性和开发人员的生产力上。然而，好处并不仅限于此，为了让微服务之旅更有价值，有意识地获得额外收益也很有意义。
【本文来自51CTO专栏作者“老曹”的原创文章，作者微信公众号：喔家ArchiSelf,id:wrieless-com】
