微服务简介

微服务已经成为了一个越来越受欢迎的架构选择。本文介绍微服务背后的核心思想，以及这些架构被广泛使用的一些原因。

微服务概览

微服务是围绕业务领域建模的独立的可发布服务。服务封装了功能，并使其他服务可以通过网络访问它—-可以从这些构建块构建一个更复杂的系统。一个微服务可能代表库存、一个订单管理和一个发货，但它们一起可以构成整个电子商务系统。微服务是一种架构选择，它致力于提供许多解决可能面临的问题的方案。

它们是一种面向服务的体系结构，尽管这种体系结构对如何绘制服务边界有自己的见解，并且独立的部署能力是关键。它们是技术不可见论者，这也是它们提供的优势之一。

从外部来看，单个微服务被视为一个黑盒子。它承载一个或多个网络端点(例如队列、REST或API，如图1所示)上的业务功能，通过任何最合适的协议。消费者，无论是其他微服务还是其他类型的程序，都通过这些联网的端点来访问这种功能。内部实现细节(例如服务器编写的技术或数据存储的方式)完全不向外部世界透露。这意味着微服务架构在大多数情况下避免使用共享数据库；相反，每个微服务在需要的地方封装自己的数据库。

微服务包含了信息隐藏的概念，信息隐藏意味在组件中隐藏尽可能多的信息，通过外部接口暴露尽可能少的信息。这样就可以清楚地区分哪些是容易改变的，哪些是很难改变的。只要微服务公开的网络接口不以向后不兼容的方式更改，就可以自由更改对外部隐藏的实现。微服务边界内的变化(如图1所示)不应该影响上游消费者，从而实现功能的独立发布。这对于使我们的微服务能过独立开展并按需发布至关重要。拥有清晰、稳定的服务边界(在内部实现更改)，将使系统具有更松的耦合和更强的内聚性。

当我们讨论隐藏内部实现细节时，就不得不提Hexagonal Architecture模式(六边形架构)，该模式最早由Alistair Cockburn详述。此模式描述了保持内部实现与其外部接口分离的重要性，其思想是，你可能希望通过不同类型的接口与相同的功能进行交互。

面向服务的体系结构和微服务有什么不同？

面向服务的体系结构(SOA)是一种设计方法，在这种设计方法中，多个服务协作以提供特定的最终功能集(这里的服务通常意味着一个完全独立的操作系统进程)。这些服务之间的通信是通过网络调用进行的，而不是通过边界内的方法调用进行的。

SOA作为一种应对大型单体应用程序挑战的方法而出现。该方法旨在促进软件的可重用性;例如，两个或多个终端用户应用程序可以使用相同的服务。SOA的目标是使维护或重写软件变得更容易，因为从理论上讲，只要服务的语义不发生太大变化，我们就可以用一个服务替换另一个服务。

SOA存在一些问题，如通信协议(例如SOAP)、供应商中间件、缺乏关于服务粒度的指导，或者在选择系统拆分位置方面的错误指导。供应商选择SOA运动作为销售更多产品的一种方式，而这些相同的产品最终破坏了SOA的目标。

在SOA中，团队努力缩小服务，但他们仍然将所有内容都耦合到数据库中，并且必须将所有内容一起部署。这是面向服务的，但不是微服务。

微服务方法是从现实世界中出现的，利用我们对系统和体系结构的更好理解来做好SOA。应该将微服务视为SOA的特定方法，就像极限编程(Extreme Programming, XP)或Scrum是敏捷软件开发的特定方法一样。

微服务的关键概念

在探索微服务时，必须了解一些核心思想。一下我们进一步探索微服务的概念以理解微服务的工作原理。

独立部署

独立部署是指我们可以对微服务进行更改、部署并将更改发布给用户，而无需部署任何其他微服务。更重要的是，这不仅仅是我们能够做到的事实；而且是在系统中管理部署的方法，是采用的默认发布方法。这是一个简单的想法，但执行起来却很复杂。

确保微服务独立部署的概念。养成这样的习惯：无需部署任何其他内容，就可以将对单个微服务的更改部署并发布到生产环境中。

为了确保独立的可部署性，我们需要确保微服务是松耦合的；我们必须能够更改一个服务而无需更改其他内容。这意味着我们需要明确的、定义良好的和稳定的服务之间的约束。一些实现选择使这变得困难—-例如，数据库的共享。

独立部署本身显然是非常有价值的。但是为了实现独立的部署，还有很多其他的事情需要做得很好，这些事情都有各自的好处。因此，可以将对独立可部署性的关注视为一种强制功能—-通过将其作为一种结果来关注，将获得许多额外的好处。

对于具有稳定接口的松散耦合服务的需求，引导我们思考如何找到微服务边界。

围绕业务领域建模

像领域驱动设计这样的技术可以让你构建你的代码，以更好地表示软件操作的现实领域。在微服务体系结构中，我们使用同样的思想来定义服务边界。通过围绕业务领域建模服务，我们可以更容易地推出新功能，并以不同的方式重新组合微服务，以向用户交付新功能。

推出一个需要对多个微服务进行更改的功能代价是昂贵的。需要跨每个服务(可能跨不同的团队)协调工作，并仔细管理这些服务的新版本部署的顺序。这要比在单个服务(或单个组件)内进行相同的更改花费更多的工作。因此，我们希望找到使跨服务更改尽可能不频繁的方法。

我们经常看到分层架构，如图2中的三层架构所示。在这里，体系架构中的每一层表示不同的服务边界，每个服务边界都基于相关的技术功能。如果需要在本例中对表示层进行更改，那将是相当有效的。然而，经验表明，在这些类型的体系结构中，功能上的更改通常跨越多个层—-需要在表示层、应用程序层和数据层上进行更改。如果架构比图2中的例子分层更多，这个问题就会加剧；通常，每一层都被分成更深层的层。

通过将服务变成业务功能的端到端部分，我们可以确保体系结构被安排得尽可能高效地更改业务功能。可以说，对于微服务，我们已经决定优先考虑高内聚性的业务功能，而不是高内聚性的技术功能。

拥有独立的状态

微服务应该避免使用共享数据库。如果一个微服务想要访问另一个微服务持有的数据，它应该向第二个微服务请求数据。这使微服务能够决定什么是共享的，什么是隐藏的，这使我们能够清楚地将可以自由更改的功能(内部实现)与我们不希望经常更改的功能(消费者使用的外部约束)分开。

如果想要实现独立部署，需要确保限制对微服务的向后不兼容更改。如果破坏了与上游消费者的兼容性，我们将迫使它们也做出改变。在微服务的内部实现细节和外部约束之间有一个清晰的描述可以帮助减少向后不兼容更改的需求。

在微服务中隐藏内部状态类似于面向对象(OO)编程中的封装实践。在OO系统中封装数据就是一个信息隐藏的例子。

除非必要，否则不要共享数据库。如果视图实现独立部署，共享数据库是最糟糕的事情之一。

希望将服务视为业务功能的端到端部分，在适当的地方封装用户界面(UI)、业务逻辑和数据。这是因为希望减少更改业务相关功能所需的工作量。以这种方式封装数据和行为为我们提供了高内聚性的业务功能。通过隐藏支持服务的数据库，我们还可以确保减少耦合。

Size

“微服务应该有多大？”这是经常有人会问的。考虑到“微”这个词，这种问题就不足为奇了。然而，当了解是什么让微服务作为一种架构类型工作时，Size的概念实际上最无意义的话题之一。

你怎么衡量Size?通过数代码行数?这是没什么意义的。在Java中需要25行代码的功能可以用10行Clojure来编写。这并不是说Clojure比Java更好或更差;有些语言只是比其他语言更具有表达能力。

微服务应该保持在易于理解的规模，不同的人理解事物的呢你并不总是相同的，因此你需要自己判断适合你的Size。一个有经验的团队可能比另一个团队更好地管理更大的代码库。

就微服务而言，最接近“Size”含义的是《微服务模式》中介绍的—-微服务的目标是“界面尽可能小”，这符合信息隐藏的概念。

规模的概念是高度相关的。与一个在系统上工作了十几年的人交谈，他们会觉得系统有10万行代码，也很容易理解。如果你问一个对这个项目不熟悉的人，他们会觉得这个项目太大了。同样地，对于一家刚刚开始微服务转型的公司，它的微服务可能只有10个或更少，而如果问一家类似规模的公司，它的微服务多年来一直是常态，现在可能有数百个。

当你开始微服务的时候，最重要的是要专注于两件事。首先，你能处理多少个微服务?随着服务的增加，系统的复杂性也会增加，需要学习新的技能(可能还需要采用新的技术)来应对这种情况。向微服务的转变将带来新的复杂性，以及可能带来的新挑战。提倡增量迁移到微服务架构。其次，如何定义微服务边界以最大限度地利用它们，而不让一切都变成可怕的耦合混乱?

架构与组织的一致性

在线销售CD的电子商务公司MusicCorp使用如图2所示的简单三层架构。有一个基于web的UI，一个单体后端形成的业务逻辑层，以及一个传统数据库中的数据存储。这些层通常由不同的团队拥有。

如果相对功能做一个简单的更新：让客户指定他们最喜欢的音乐类型。这个更新要求改变UI以显示类型选择UI，后端服务以允许类型出现在UI中并改变值，以及数据库接受这种改变。这些更改需要由每个团队管理，并按照正确的顺序部署，如图3所示。

目前来看，这个框架还不错。所有架构最终都会围绕一组目标进行优化。三层架构之所以如此普遍，部分原因在于它的普遍性—-每个人都听说过它。所以，选择一个你可能在其他地方看到过的通用架构的趋势，通常是我们不断看到这种模式的一个原因，它基于我们如何组织团队。

著名的康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构。三层体系结构就是这个法则的一个很好的例子。在过去，IT组织对人员进行分组的主要方式是根据他们的核心能力：数据库管理员与其他数据库管理员在一个团队中;Java开发人员与其他Java开发人员在一个团队中;前端开发人员则属于另一个团队。我们根据人们的核心能力对他们进行分组，因此我们创建可以与那些团队相结合的IT资产。

这就解释了为什么这种架构如此普遍。但形势已经发生了变化。我们对软件的期望已经改变了。我们现在将人员分组在多技能团队中，们想要比以前更快地发布软件。这促使我们在组织团队的方式上做出不同的选择，所以我们按照系统分裂的方式来组织团队。

我们被要求对系统进行的大多数更改都与业务功能的更改有关。但是在图3中，我们的业务功能实际上分布在所有三个层上，增加了功能更改跨层的机会。这是一个具有高内聚相关技术但低内聚业务功能的体系结构。如果想让更改变得更容易，那么需要改变代码分组的方式，选择业务功能的内聚性而不是技术。每个服务最终可能包含也可能不包含这三层的混合，但这是一个本地服务实现关注的问题。

让我们将其与一个潜在的替代体系结构进行比较，如图4所示。我们不采用水平分层的架构和组织，而是沿着垂直的业务线分解组织和架构。在这里，我们看到一个专门的团队，他们对客户概要文件的各个方面进行更改负有完全端到端的责任，这确保了示例中的更改范围仅限于一个团队。

作为一种实现，可以通过配置文件团队拥有的单个微服务来实现，该微服务公开一个UI，允许客户更新他们的信息，客户的状态也存储在这个微服务中。选择最喜欢的类型是与特定用户相关联的，所以这种改变更加本地化。在图5中，还显示了从catalog
微服务获取的可用类型列表。我们看到了一个新的Recommendation
微服务，可以访问我们最喜欢的类型信息，这很容易在后续发布中跟进。

在这种情况下，我们的Customer
微服务封装了三层中的每一层的部分细节—-它有一点UI、一点应用程序逻辑和一点数据存储。我们的业务领域成为驱动我们系统架构的主要力量，希望使变更更容易，并使我们更容易保持团队与组织内的业务线一致。

通常，UI不是有微服务直接提供的，但即使是这样，我们也希望与此功能相关的部分UI仍然由客户概要文件团队拥有，如图4所示。团队拥有面向对象用户功能的端到端部分的概念正在获得关注。

单体架构(Monolith)

上面谈到了微服务，但是微服务最常被当作一个体系结构方法来讨论，它可以替代单体架构。为了清楚地区分微服务体系架构，我们看一下单体架构的确切定义。

当我们提到单体时，主要指的是部署单元。当系统中的所有功能都必须部署在一起时，我们认为它是一个单体。可以说，多个体系结构符合这个定义，最常看到的有：单进程单体、模块化单体和分布式单体。

单进程单体架构

在讨论单体时，最常见的例子是一个系统，其中所有的代码都部署为单个进程，如图6所示。处于健壮性或可伸缩性的原因，可能有多个该流程的实例，但从根本上说，所有代码都打包到一个流程中。实际上，这些单进程系统本身就可以称为简单的分布式系统，因为他们几乎总是要从数据库中读取数据或将数据存储到数据库中，或将信息呈现给web或移动应用程序。

尽管这符合大多数人对经典单体的理解，实际上大多数系统比这更复杂。可能有两个或多个紧密耦合在一体的单体，其中可能包含一些供应商软件。

经典的单流程单体部署对许多规模小的公司适用。这样的架构相对于较小的组织是有意义的，随着组织的增长，整体也可能随之增长，这将我们引入模块化单体。

模块化单体架构

作为单流程单体的子集，模块化单体是单个流程由独立模块组成的变体。每个模块都可以独立工作，但仍然需要将所有模块组合在一起进行部署，如图7所示。将软件分解成模块的概念并不新鲜；模块化软件起源于20世纪70年代围绕结构化编程所做的工作。尽管如此，现实中仍然没有看到足够多的组织恰当地采用这种方法。

对于许多组织来说，模块化单体可能是一个很好的选择。如果模块边界定义得好，它可以允许高度的并行工作，同时通过更简单的部署拓扑来避免分布式的微服务体系结构带来的挑战。Shopify就是一个很好的例子，该公司使用这种技术作为微服务分解的替代方法。

模块化单体的挑战之一是，数据库往往缺乏我们在代码级别中发现的分解，如果你想在未来将整体拆分，这将带来重大挑战。一些团队视图通过将数据库分解成与模块相同的线来进一步推进模块化单体的想法，如图8所示：

分布式单体架构

分布式单体是由多个服务组成的系统，但无论处于什么原因，整个系统都必须部署在一起。分布式整体可能很符合SOA的定义，但它常常无法实现SOA的目标。分布式单体具有分布式系统的所有缺点，以及单进程单体的缺点。

分布式集成块通常出现在对信息隐藏和业务功能内聚等概念关注不够的环境中。相反，高度耦合的体系结构会导致更改在服务边界之间产生连锁反应，并且看起来无关紧要的更改会破坏系统的其他部分。

单体架构交付争用

随着越来越多的团队成员同时维护一个功能，当不同的开发人员想要改变同一段代码，不同的团队想要推动新功能或者推迟部署，这就产生了争用。大量的研究表明了混淆所有边界所带来的挑战称为交付争用。

拥有一个单体并不意味着一定会面临交付争用的挑战，就像拥有一个微服务架构并不意味着永远不会面临这个问题一样。但微服务体系架构确实提供了更具体的边界，在系统中可以围绕这些边界绘制所有权限，从而在减少这个问题时提供了更大的灵活性。

单体架构的优势

一些单体，如单进程单体或模块化单体，也有一整套的优势。它们更简单的部署拓扑结构可以避免与分布式系统相关的许多缺陷。可以使开发人员的工作流程简单得多，而且监视、故障排除和端到端测试等也可以大大简化。

单体还可以简化内部的代码重用，如果我们想在分布式系统中重用代码，我们需要决定是否要复制代码、拆分库或将共享功能推入服务中。有了一个单体，我们的选择就简单多了，许多人喜欢这种简单性—-所有的代码都在那里，只需要调用它。

微服务的优势

微服务的优势是多种多样的。任何分布式系统都有许多这样的好处。然而，微服务往往在更大程度上实现这些好处，主要是因为它们在定义服务边界的方式上采取了更坚定的立场。通过将信息隐藏和领域驱动设计的概念与分布式系统的能力相结合，微服务可以帮助提供比其他形式的分布式体系结构更显著的优势。

技术多样性(Technology Heterogeneity)

在一个由多个协作微服务组成的系统中，我们可以决定在每个微服务中使用不同的技术。这让我们能够为每个工作选择正确的工具，而不是选择一个更标准化的、适用于所有人的方法。

如果系统的某个部分需要改进其性能，我们可能会决定使用能够更好地实现所需性能级别的不同技术堆栈。我们还可能决定存储数据的方式需要针对系统的不同部分进行更改。例如,一个社交网络,我们可以存储用户的交互采用面向图形数据库中,以反映社会的高度互联性质图,但也许帖子的用户可以存储在一个面向文档的数据存储,异构体系结构如图9所示：

有了微服务，我们也能够更快的在系统中采用新技术。尝试和采用新技术的最大障碍之一是与之相关的风险。对于单体应用程序，如果我想尝试一种新的编程语言、数据库或框架，任何更改都会对我的系统产生很大影响。对于一个包含多个服务的系统，我有多个新的地方来尝试一项新技术。我可以选择风险最低的微服务并使用它的技术，因为我知道我可以限制任何潜在的负面影响。许多组织发现这种能够更快地吸收新技术的能力是一个真正的优势。

当然，采用多种技术并不是没有开销的。一些组织选择对语言的选择施加了一些限制。例如，Netflix和Twitter主要使用Java虚拟机(JVM)作为平台，因为这些公司对系统的可靠性和性能有一定的要求。他们还为JVM开发库和工具，使大规模操作变得更加容易，但是对特定于JVM的库的依赖使非基于java的服务或客户机的操作变得更加困难。但无论是Twitter还是Netflix，都不会在所有工作中只使用一种技术堆栈。

对消费者隐藏内部技术实现也可以使技术升级更容易。例如，整个微服务体系结构可能基于Spring Boot，但可以仅更改一个微服务的JVM版本或框架版本，从而更容易管理升级的风险。

鲁棒性(Robustness)

提高应用程序健壮性的一个关键概念是隔离。系统的一个组件可能会出现故障，但只要故障不是串联的，就可以隔离问题，系统的其余部分可以继续工作。服务边界成为了壁垒，在单体服务中，如果服务失败，一切都停止工作。对于单体系统，我们可以在多台机器上运行以减少故障的可能性，但是对于微服务，我们可以构建能够处理某些组成服务的全部故障并相应降低功能的系统。

为了确保我们的微服务系统能够适当地接受这种改进的健壮性，我们需要理解分布式系统必须处理的新的故障来源。网络可能也会失败，机器也一样。我们需要知道如何处理这些故障以及这些故障将对我们软件的最终用户产生的影响。

扩展(Scaling)

对于一个大型的、单体的服务，我们需要一起扩展所有内容。也许我们整个系统的一小部分在性能上受到了限制，但是如果该行为被锁定在一个巨大的单体应用程序中，我们需要将所有东西作为一块来处理。对于较小的服务，我们可以只扩展那些需要扩展的服务，允许我们在更小、功能更弱的硬件上运行系统的其他部分，如图10所示。

在线时尚零售商Gilt正是出于这个原因采用了微服务。Gilt的系统从2007年开始使用一个单体的Rails应用程序，到2009年，它已经无法应付施加在它身上的负载。通过拆分系统的核心部分，Gilt能够更好地应对流量高峰，现在它有超过450个微服务，每一个都运行在多台独立的机器上。

当采用AWS提供的按需供应系统时，我们甚至可以对那些需要它的部分应用这种伸缩。这使我们能够更有效地控制成本。我们可以以多种方式扩展应用程序，而微服务可以成为其中的有效组成部分。

易于部署

对百万在线单体应用程序的一行更改需要部署整个应用程序才能发布更改。这可能是一个大影响，高风险的部署。在实践中，这样的部署最终很少发生。不幸的是，这意味着我们的更改会在不同版本之间继续增加，直到应用程序进入生产环境的新版本有大量的更改。两次发行之间的增量越大，我们出错的风险就越高。

通过微服务，我们可以对单个服务进行更改，并独立于系统的其余部分进行部署。这使我们能够更快地部署代码。如果确实出现了问题，可以将其快速隔离到单个服务，从而轻松实现快速回滚。这也意味着我们可以更快地将新功能提供给客户。这是像亚马逊和Netflix这样的组织使用这些架构的主要原因之一，以确保他们尽可能多地消除软件推出的障碍。

可组合性(Composability)

分布式系统和面向服务的体系结构的关键理念是，我们为功能的重用提供了机会。通过微服务，我们可以根据不同的目的以不同的方式使用我们的功能。当我们考虑消费者如何使用我们的软件时，这一点尤其重要。

我们可以狭隘地考虑桌面网站或移动应用程序的时代已经过去了。现在，我们需要考虑各种各样的方式，以便将网络、本地应用程序、移动网络、平板电脑应用程序或可穿戴设备的功能整合在一起。随着组织从狭隘的渠道思维转向更全面的客户参与概念，我们需要能够跟上的架构。

有了微服务，就可以想象在系统中开辟了可以由外部解决的缝隙。随着环境的变化，我们可以以不同的方式构建应用程序。

微服务的不足

微服务体系结构带来了许多好处，但它们也带来了许多复杂性。下面我们分析下微服务的一些缺陷。

成本(cost)

很有可能，在短期内，你会看到许多因素导致成本增加。首先，微服务架构可能需要运行更多的东西—-更多的进程、更多的计算机、更多的网络、更多的存储和更多的支持软件。

其次，你在团队或组织中引入的任何变化都会在短期内减慢你的进度。学习新想法，并找出如何有效地利用它们需要时间。在此过程中，其他活动也会受到影响。这将导致新功能交付的直接放缓，或者需要增加更多的人员来抵消这一成本。

对于一个主要关注降低成本的组织来说，微服务是一个糟糕的选择，因为削减成本的心态—-IT被视为成本中心而不是利润中心—-将会持续拖累该体系结构的发挥。

报告(Reporting)

对于单体系统，通常有一个单体数据库。这意味着想要一起分析所有数据(通常涉及跨数据的大型连接操作)的涉众有一个现成的模式来运行他们的报告。他们可以直接在单体数据库上运行它们，可能是针对一个读副本，如图11所示。

通过微服务体系结构，我们打破了这个单一的模式。这并不意味着报告我们所有数据的需求已经消失;我们只是让它变得更加困难，因为现在我们的数据分散在多个逻辑上独立的模式上。

更现代的报告方法，如使用流来允许对大量数据进行实时报告，可以很好地与微服务体系结构一起工作，但通常需要采用新的想法和相关技术。或者可能只需要将微服务中的数据发布到中央报告数据库以允许报告用例。

监控和故障诊断

对于标准的单体应用程序，我们可以采用一种相当简单的监控方法。我们需要担心的是少量的机器，并且应用程序的故障模式是二进制的—-应用程序经常要么全部启动，要么全部关闭。在微服务体系结构中，如果服务的单个实例宕机，我们怎么确定它所造成的影响?

对于单体系统，如果我们的CPU长时间停留在100%，我们知道这是一个大问题。对于拥有数十或数百个进程的微服务体系结构，当只有一个进程占用了100%的CPU时，对系统的影响又是多大呢？

安全

在单进程单体系统中，我们的很多信息都在这个过程中流动。现在，更多的信息通过网络在我们的服务之间流动。这可能使我们的数据更容易在传输过程中被观察到，也可能作为中间人攻击的一部分被操纵。这意味着可能需要更加注意保护传输中的数据，并确保微服务端点受到保护，以便只有授权方能够使用它们。

延迟(Latency)

在微服务体系结构中，以前可能在一个处理器上本地完成的处理现在可以在多个独立的微服务中分割。以前仅在单个进程中流动的信息现在需要通过网络进行序列化、传输和反序列化。所有这些都可能导致系统延迟恶化。

尽管在设计或编码阶段很难测量操作延迟的确切影响，但这是以增量方式进行微服务迁移的另一个重要原因。做一个小小的改变，然后衡量它的影响。

数据一致性(Data Consistency)

从一个单体系统(在单数据库中存储和管理数据)到一个分布式的系统(在多进程管理不同数据库中的状态)的转变，可能会导致数据一致性方面的挑战。在过去，可能依赖数据库事务来管理状态更改，但在分布式系统中很难提供类似的安全性。在大多数情况下，分布式事务的使用被证明在协调状态变化方面存在很大的问题。

相反，可能需要开始使用sagas和最终一致性等概念来管理和推断系统中的状态。这些想法可能要求你对系统中的数据进行根本性的修改，这在迁移现有系统时可能非常令人生畏。同样，这也是要谨慎分解应用程序速度的另一个原因。采用增量方法进行分解，以便能够评估变更对生产中的架构的影响，这是非常重要的。

总结

微服务体系结构可以在选择技术、处理健壮性和伸缩性、组织团队等方面为你提供极大的灵活性。这种灵活性是许多人接受微服务的部分原因。但是微服务带来了很大程度的复杂性，需要确保这种复杂性是有保证的。对于许多人来说，它们已经成为了默认的系统架构，在几乎所有的情况下使用。然而，它们是一种架构选择，其使用必须由你视图解决的问题来证明，通常，更简单的方法可以更容易地交付。

尽管如此，许多组织，尤其是大型组织，已经证明了微服务的有效性。当正确理解和实现微服务的核心概念时，它们可以帮助创建赋权的、高效的体系结构，从而帮助系统超越各个部分的总和。

感兴趣的关注如下公众号！