微服务指南

【注】本文节译自： Microservices Guide (martinfowler.com)

简而言之，微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小服务都在自己的进程中运行，并与轻量级机制（通常是 HTTP 资源 API）进行通信。这些服务围绕业务功能构建，并且可以通过全自动部署机制独立部署。这些服务可以用不同的编程语言编写，使用不同的数据存储技术，只要进行最小化的集中管理。
– 詹姆斯·刘易斯和马丁·福勒（2014）

martinfowler.com上有关微服务的材料指南。
马丁·福勒2019.8.21

2013年底，在我的圈子里听到了有关微服务的所有讨论后，我开始担心微服务的定义不明确（这种命运给SOA带来了许多问题）。因此，我和同事詹姆斯·刘易斯（James Lewis）聚在一起，他是这种风格的资深从业者之一。 我们一起写

  我们写这篇文章是为了对微服务风格提供一个明确的定义，我们通过列出我们在该领域中看到的微服务架构的共同特征来实现这一点。

• 通过服务实现组件化
• 围绕业务能力进行组织
• 产品不是项目
• 智能端点和哑管道
• 分散治理
• 分散数据管理
• 基础设施自动化
• 故障设计
• 进化设计

  我们还研究了一些常见问题，例如“微服务的规模有多大”以及“微服务与面向服务的体系结构之间的区别是什么”。这篇文章激发了人们对微服务的兴趣。
“我们使用它，我们不使用它？
……这到底是什么呢？”

  在简短的介绍性演讲（约25分钟）中，我选择了最重要的定义特征，将微服务与整体组件进行了比较，并概述了将第一个微服务系统投入生产之前要做的重要工作。

我们什么时候应该使用微服务？

  任何架构风格都需要权衡：我们必须根据它所使用的上下文来评估其优缺点。微服务肯定是这种情况。尽管它是一种有用的体系结构，但实际上，大多数情况下，使用整体组件会更好。

微服务提供优势…

• 强大的模块边界：微服务加强了模块化结构，这对于大型团队而言尤其重要。
• 独立部署：简单服务更易于部署，并且由于它们是自治的，因此出错时不太可能导致系统故障。
• 技术多样性：使用微服务，您可以混合使用多种语言、开发框架和数据存储技术。

…但要付出代价

• 分布式：分布式系统较难编程，因为远程调用速度很慢，并且总是面临失败的风险。
• 最终一致性：对于分布式系统而言，保持强一致性非常困难，这意味着每个人都必须管理最终一致性。
• 运营复杂性：您需要一个成熟的运营团队来管理大量服务，这些服务会定期重新部署。

微服务高级版

在过去的一年里，微服务架构风格一直是热门话题。在最近的 O’Reilly 软件架构会议上，似乎每个会议都在谈论微服务。足以使每个人的“过度炒作检测器”启动并闪烁起来。其后果之一是，我们已经看到团队太渴望接受微服务，而没有意识到微服务会给自己带来复杂性。这给项目的成本和风险增加了额外的费用—这通常会使项目陷入严重的麻烦。
马丁·福勒（Martin Fowler）2015.5.13

整体优先

  当我听到团队使用微服务架构的故事时，我注意到了一种常见的模式。

1. 几乎所有成功的微服务故事都始于一个庞大的整体，并且被分解了
2. 我听说过的从头构建为微服务系统的系统都遇到了严重的麻烦。

不要从整体开始

在过去的几个月中，我反多次听到这样的说法：获得成功的微服务架构的唯一方法就是首先从整体开始。用西蒙·布朗（Simon Brown）的话来说：如果您无法构建结构良好的整体，那么为什么您认为可以构建一组结构良好的微服务呢？最近（通常是非常有说服力的）的论点来自该站点上的马丁·福勤。当我有机会对早期的草案发表评论时，我有一些时间来考虑这一点。 我之所以这样做，尤其是因为我通常会发现自己与他一致，而其他一些我通常分享的观点似乎也同意他。我坚信从整体开始通常是错误的做法。
斯蒂芬·蒂尔科夫（Stefan Tilkov）2015.6.9

微服务先决条件

当我与人们谈论使用微服务架构风格时，我听到了很多乐观情绪。开发人员喜欢使用较小的单元，并且期望比整体组件具有更好的模块化。但是，与任何架构决策一样，都需要权衡取舍。尤其是对于微服务而言，这给运营带来了严重后果，运营者现在必须处理小型服务的生态系统，而不是一个定义良好的单一整体。因此，如果你没有某些基本能力，就不应该考虑使用微服务风格。
马丁·福勒（Martin Fowler）2014.8.28

微服务和分布式对象的第一定律

在 EAA 的 P 中，我说“不要分发您的对象”。 这个建议是否与我对微服务的兴趣相矛盾？
马丁·福勒（Martin Fowler）2014.8.13

与萨姆·纽曼（Sam Newman）关于微服务的访谈

goto会议要求我对萨姆·纽曼的书《Monoliths to Microservices》进行采访。这变成了有关微服务及其何时使用它们的一般性讨论。萨姆认为它们的三个主要原因是独立的可部署性、数据的隔离性和反映组织结构。我对第一个更为怀疑，但认为数据和人员是软件开发的复杂部分。
马丁·福勒（Martin Fowler）2020.9.4

构建微服务

  微服务架构是相当新的，但我很幸运，自从最早出现以来，我们就一直在 ThoughtWorks 与它们合作。关于如何最好地与他们合作的最好描述，最好的介绍是萨姆·纽曼（Sam Newman）的书《构建微服务》，他根据我们的经验和其他已发表的经验撰写了这本书。

微服务架构中的测试策略

在过去的几年中，基于服务的架构已转向更小、更集中的“微”服务。这种方法有很多好处，例如能够独立部署、扩展和维护每个组件，并使多个团队之间的开发并行化。但是，一旦引入了这些额外的网络分区，就需要重新考虑应用于单片进程应用的测试策略。在这里，我们计划讨论一些方法，用于管理多个可独立部署的组件的额外测试复杂性，以及在多个团队各自充当不同服务的监护人的情况，如何让测试和应用保持正确。
托比·克莱姆森（Toby Clemson）2014.11.18

如何将单体应用分解为微服务

随着整体系统变得太大而无法处理，许多企业倾向于将其分解为微服务架构风格。 这是一次值得的旅程，但并不容易。 我们已经了解到，要做到这一点，我们需要从简单的服务开始，然后再基于对业务很重要并且会经常更改的垂直功能来提供服务。这些服务起初应该很大，最好不依赖于其余的整体。我们应该确保迁移的每一步都代表了整个体系结构的原子性改进。
扎马克·德加尼（Zhamak Dehghani）2018.4.24

微前端

好的前端开发很难。扩展前端开发，使许多团队可以同时处理大型复杂产品，这变得更加困难。在本文中，我们将描述最近的一种趋势，即将前端整体拆分成许多更小、更易于管理的部分，以及这种架构如何提高前端代码团队的效率。除了讨论各种收益和成本外，我们还将介绍一些可用的实现选项，并深入研究演示该技术的完整示例应用。
卡姆·杰克逊（Cam Jackson）2019.6.19

如何从整体中提取数据丰富的服务

当将整体式服务器拆分成较小的服务时，最困难的部分实际上是拆分存在于整体式数据库中的数据。要提取数据丰富的服务，遵循一系列步骤始终保持数据的单个写副本是很有用的。这些步骤首先在现有的整体中进行逻辑分离：将服务行为拆分为单独的模块，然后将数据拆分为单独的表。这些元素可以分别移动到新的自治服务中。
普拉富尔·托德卡尔（Praful Todkar）2018.8.30

基础设施即代码

基础架构即代码是通过源代码定义计算和网络基础架构的方法，然后可以像对待任何软件系统一样对待它们。可以将此类代码保留在源代码控制中，以允许可审核性和可复制的构建，服务从于测试实践，以及持续交付的完整规范。在过去的十年中，这种方法已用于应对不断增长的云计算平台，并且将成为下一个处理计算基础架构的主要方法。
马丁·福勒（Martin Fowler）2016.3.1

DevOps 文化

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o4Wi9k8n-1614931016347)(https://p6-tt.byteimg.com/origin/pgc-image/f123d08914e14eaca8324cd0ddfe3025?from=pc)]

敏捷软件开发打破了需求分析、测试和开发之间的一些孤岛。部署、操作和维护是其他活动，它们与其余软件开发过程有着类似的分离。DevOps 运动旨在消除这些孤岛，并鼓励开发与运营之间的协作。
鲁安·威尔森纳赫（Rouan Wilsenach)2015.7.9

熔断器

对于软件系统，通常是远程调用运行在不同进程中的软件，可能是在网络中的不同计算机上。内存内调用和远程调用之间的最大区别之一是，远程调用可能会失败，或者挂起而没有响应，直到达到某个超时限制。更糟糕的是，如果您在没有响应的供应商上有许多调用者，那么您可能会耗尽关键资源，从而导致多个系统之间的级联故障。 迈克尔·尼加德（Michael Nygard）在他的优秀著作《释放它》（Release It）中推广了断路器模式，以防止这种灾难性的连锁反应。 熔断器的基本原理非常简单。将受保护的函数调用包装在熔断器对象中，该对象将监视故障。 一旦故障达到某个阈值，熔断器将跳闸，并且所有进一步的熔断器调用都会返回错误，而根本不会进行受保护的调用。通常，如果熔断器跳闸，您还需要某种监控器警报。
马丁·福勒（Martin Fowler）2014.3.