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