微服务指南

微服务架构风格一直是过去一年的热门话题。在最近的O'Reilly 软件架构大会上，似乎每个会议都在谈论微服务。足以让每个人的过度炒作探测器都亮起来并闪烁。其后果之一是我们看到团队过于渴望拥抱微服务，却没有意识到微服务本身引入了复杂性。这增加了项目的成本和风险溢价，而这往往会使项目陷入严重的麻烦。

当我听到有关团队使用微服务架构的故事时，我注意到一个共同的模式。

1. 几乎所有成功的微服务故事都是从一个变得过大的单体开始的，然后被分解了
2. 几乎所有我听说过的从头开始构建为微服务系统的系统，最终都陷入了严重的麻烦。

这种模式导致我的许多同事认为，即使您确定您的应用程序足够大，值得使用微服务，您也不应该从微服务开始一个新项目。。

在过去的几个月里，我反复听到，获得成功的微服务架构的唯一方法是首先从单体开始。用 Simon Brown 的话说：如果你不能构建一个结构良好的单体，你凭什么认为你可以构建一组结构良好的微服务？最近——和往常一样，非常有说服力——对这一论点的阐述来自 Martin Fowler 在这个网站上的文章。由于我有机会对他早期的草稿发表评论，所以我有一些时间来思考这个问题。我确实这样做了，特别是因为我通常发现自己同意他的观点，而其他一些我通常同意其观点的人似乎也同意他的观点。

我坚信，从单体开始通常是完全错误的做法。

当我与人们谈论使用微服务架构风格时，我听到了很多乐观的声音。开发人员喜欢使用更小的单元工作，并且期望比单体架构更好的模块化。但是，与任何架构决策一样，都需要权衡取舍。特别是对于微服务，运维会产生严重的后果，运维现在必须处理一个小型服务生态系统，而不是一个定义明确的单体。因此，如果您不具备某些基线能力，则不应考虑使用微服务风格。

在 EAA 的 P 中，我说“不要分发你的对象”。这个建议是否与我对微服务的兴趣相矛盾？

goto conferences 邀请我采访 Sam Newman 关于他的书：《从单体到微服务》。这变成了一场关于微服务以及何时使用它们的对话。Sam 认为它们的主要原因是独立部署、数据隔离和反映组织结构。我对第一个原因持怀疑态度，但认为数据和人员是软件开发中复杂的部分。

在过去几年中，基于服务的架构已经转向更小、更集中的“微”服务。这种方法有很多好处，例如能够独立部署、扩展和维护每个组件，并在多个团队之间并行开发。但是，一旦引入了这些额外的网络分区，就需要重新考虑适用于进程内单体应用程序的测试策略。在这里，我们计划讨论一些方法来管理多个独立可部署组件的额外测试复杂性，以及如何在多个团队各自充当不同服务的守护者的同时，保持测试和应用程序的正确性。

随着单体系统变得太大而无法处理，许多企业都被吸引将其分解为微服务架构风格。这是一段值得的旅程，但并不容易。我们已经了解到，要做好这一点，我们需要从一个简单的服务开始，然后提取出基于对业务很重要且经常发生变化的垂直能力的服务。这些服务最初应该很大，并且最好不依赖于剩余的单体。我们应该确保迁移的每个步骤都代表着对整体架构的原子改进。

好的前端开发很难。扩展前端开发以使许多团队能够同时在一个大型复杂产品上工作则更加困难。在本文中，我们将描述最近将前端单体分解成许多更小、更易于管理的部分的趋势，以及这种架构如何提高前端代码团队的工作效率和效率。除了讨论各种好处和成本之外，我们还将介绍一些可用的实现选项，并且我们将深入研究一个完整的示例应用程序来演示该技术。

将单体分解成更小的服务时，最难的部分实际上是分解存储在单体数据库中的数据。要提取数据丰富的服务，最好遵循一系列步骤，这些步骤始终保留数据的单个写入副本。这些步骤首先在现有单体中进行逻辑分离：将服务行为拆分为单独的模块，然后将数据拆分为单独的表。这些元素可以单独移动到一个新的自治服务中。

基础设施即代码是一种通过源代码定义计算和网络基础设施的方法，然后可以像对待任何软件系统一样对待这些源代码。此类代码可以保存在源代码控制中，以允许可审计性和可重复构建，并遵守测试实践和持续交付的完整原则。在过去十年中，这种方法一直被用来处理不断增长的云计算平台，并将成为未来处理计算基础设施的主要方式。

敏捷软件开发打破了需求分析、测试和开发之间的一些隔阂。部署、运营和维护是其他一些活动，它们与软件开发过程的其他部分也存在类似的脱节。DevOps 运动旨在消除这些隔阂，并鼓励开发和运营之间的协作。

软件系统通常会进行远程调用，调用在不同进程中运行的软件，这些软件可能位于网络上的不同机器上。内存调用和远程调用之间的一个显著区别是，远程调用可能会失败，或者在达到某个超时限制之前一直挂起而没有响应。更糟糕的是，如果在无响应的供应商上有许多调用者，那么可能会耗尽关键资源，从而导致跨多个系统的级联故障。Michael Nygard 在他的优秀著作《发布它》中推广了断路器模式，以防止这种灾难性的级联故障。

断路器背后的基本思想非常简单。将受保护的函数调用包装在一个断路器对象中，该对象负责监视故障。一旦故障达到某个阈值，断路器就会跳闸，并且对断路器的所有后续调用都会返回错误，而根本不会进行受保护的调用。通常，如果断路器跳闸，还需要某种监视器警报。