微服务架构模式是一种将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行，并通过轻量级机制（通常是 HTTP 资源 API）进行通信。这些服务围绕业务能力构建，并通过完全自动化的部署机制独立部署。这些服务的集中管理最少，它们可以使用不同的编程语言编写，并使用不同的数据存储技术。虽然它们的优势使其在过去几年中非常流行，但它们也带来了增加分布、削弱一致性和需要在运营管理方面成熟的成本。

术语“微服务架构”在过去几年中出现，用于描述将软件应用程序设计为独立可部署服务套件的一种特定方式。虽然没有对这种架构风格的精确定义，但围绕业务能力组织、自动化部署、端点智能和语言和数据的分散控制，存在一些共同特征。

与任何新的架构术语一样，很难得到对微服务是什么的明确定义，因此本次演讲从基于我和 James 的文章（帮助推动了人们对微服务的兴趣）来解决这个问题。然后，我将微服务与 SOA 进行比较，将架构与更单一的做法进行比较，并概述在部署微服务应用程序之前必须正确处理的重要事项。

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

goto 大会要求我与 Sam Newman 就他的书“从单体应用程序到微服务”进行访谈。这变成了关于微服务以及何时使用它们的普遍对话。Sam 认为使用微服务的主要原因是独立可部署性、数据隔离以及反映组织结构。我对第一个原因持怀疑态度，但我认为数据和人员是软件开发中复杂的部分。

分布式系统对程序提出了特殊挑战。它们通常要求我们拥有数据的多个副本，这些副本需要保持同步。然而，我们不能依赖于处理节点可靠地工作，网络延迟很容易导致不一致。尽管如此，许多组织仍然依赖于一系列核心分布式软件来处理数据存储、消息传递、系统管理和计算能力。这些系统面临着共同的问题，它们通过类似的解决方案来解决这些问题。2020 年，Unmesh Joshi 开始将这些解决方案收集为模式，并在开发过程中将它们发布到此网站。2023 年，这些模式在《分布式系统模式》一书中出版。此页面链接到每个模式的简短摘要，并提供指向 oreilly.com 上在线电子书出版的相关章节的深度链接。

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

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

许多开发团队发现微服务架构风格优于单体架构。但其他团队发现它们是生产力下降的负担。与任何架构风格一样，微服务也带来了成本和收益。要做出明智的选择，您必须了解这些权衡，并将它们应用于您的特定环境。

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

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

在过去几个月里，我反复听到，获得成功微服务架构的唯一方法是从单体应用程序开始。引用 Simon Brown 的话说：如果你不能构建一个结构良好的单体应用程序，你凭什么认为你能构建一套结构良好的微服务？最近（也是一如既往地令人信服）对这种论点的阐述来自 Martin Fowler 在这个网站上。由于我有机会对早期草稿发表评论，我有一些时间思考这个问题。我确实思考了，尤其是因为我通常发现自己同意他的观点，而一些我通常会分享其观点的其他同事似乎也同意他的观点。

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

康威定律（由 Melvin Conway 于 1968 年提出）指出，系统的设计受其设计人员的沟通模式的约束。Birgitta、Mike、James 和我讨论了这一原则的含义以及我们在职业生涯中如何看到它的体现。我们讨论了它对微服务概念的影响、与业务能力保持一致的重要性以及逆康威操作的作用。

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

微服务架构风格 已经成为过去一年的热门话题。在最近的 O'Reilly 软件架构大会 上，似乎每个会议都在谈论微服务。足以让每个人的过度炒作的胡说八道检测器启动并闪烁。这带来的一个后果是，我们看到团队过于急于拥抱微服务，没有意识到微服务本身会带来复杂性。这会给项目的成本和风险增加溢价——这通常会导致项目陷入严重困境。

当我与人们谈论使用 微服务架构风格 时，我听到很多乐观情绪。开发人员喜欢使用更小的单元，并期望比单体应用程序具有更好的模块化。但与任何架构决策一样，也存在权衡。特别是对于微服务，对运营的影响非常大，他们现在必须处理小型服务的生态系统，而不是单个定义明确的单体应用程序。因此，如果您没有某些基本能力，就不应该考虑使用微服务风格。

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

1. 几乎所有成功的微服务故事都始于一个变得太大而被分解的单体应用程序
2. 几乎所有我听说过从头开始构建为微服务系统的系统，最终都遇到了严重问题。

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