【注】本文节译自：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 文化

麻利软件开发突破了需要剖析、测试和开发之间的一些孤岛。部署、操作和保护是其余流动，它们与其余软件开发过程有着相似的拆散。DevOps 静止旨在打消这些孤岛，并激励开发与经营之间的合作。
鲁安·威尔森纳赫（Rouan Wilsenach)2015.7.9

熔断器

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