vlambda博客
学习文章列表

在这个数字化转型时代，企业越来越采用技术作为从根本上增加收入和客户群的关键推动力之一.企业主要使用社交媒体、移动、云、大数据和物联网（IoT ）作为车辆实现颠覆性创新。利用这些技术，企业正在寻找新的方式来快速打入市场，这对传统的 IT 交付机制提出了严峻的挑战。

下图显示了传统开发和微服务在应对新的企业挑战（例如敏捷性、交付速度和规模）时的状态：

企业投资于大型应用程序开发而周转时间为几年的日子已经一去不复返了。企业不再像几年前那样对开发用于管理其端到端业务功能的整合应用程序感兴趣。

下图显示了传统单体应用程序和微服务的状态与周转时间和成本的比较：

例如，今天，航空公司并没有将其核心大型机预订系统作为另一个庞然大物进行投资。金融机构并未重建其核心银行系统。零售商和其他行业并没有重建重量级的供应链管理应用程序，例如他们的传统 ERP。重点已从构建大型应用程序转移到构建以最敏捷的方式满足业务特定需求的速赢单点解决方案。

让我们举一个使用遗留单体应用程序运行的在线零售商的示例。如果零售商想通过根据客户过去的购物偏好等为客户提供个性化的产品来创新他们的销售，或者他们想通过根据购买产品的倾向向客户提供产品来启发客户。

在这种情况下，企业希望根据他们的迫切需求快速开发个性化引擎或报价引擎，并将它们插入到他们的遗留应用程序中，如下所示：

如上图所示，而不是 投资 重建Core Legacy系统，这可以通过将响应传递给新函数来完成，如标记为A的图表所示，或修改Core Legacy System以调出这些 作为处理的一部分起作用，如图标记为 B 所示。这些功能通常被编写为微服务。

这种方法为组织提供了大量机会，可以在实验模式下以较低的成本快速尝试新功能。企业可以稍后验证关键绩效指标是否更改或根据需要替换这些实施。

新兴技术让我们重新思考我们构建软件系统的方式。例如，几十年前，我们甚至无法想象没有两阶段提交的分布式应用程序。后来，NoSQL数据库made我们认为不同。

同样，这些技术范式转变已经重塑了软件架构的所有层次。

HTML 5、CSS3 的出现以及移动应用程序的进步重新定位了用户界面。客户端 JavaScript 框架，例如 Angular、Ember、React、Backbone 等，由于其在响应式和自适应设计方面的能力而非常受欢迎。

随着云采用 steamed 成为主流，平台即服务 (PaaS) 提供商，例如 Pivotal CF、AWS、Sales Force、IBM Bluemix、Redhat OpenShift 等，让我们重新思考我们构建中间件组件的方式。 Docker 引发的容器革命彻底影响了 基础设施空间。 Mesosphere DCOS等容器编排工具，使基础设施管理 容易得多。无服务器进一步简化了应用程序管理。

集成环境也发生了变化随着新兴集成 平台即服务（iPaaS），例如戴尔 Boomi、Informatica、MuleSoft 等。这些工具帮助组织将集成边界扩展到传统企业之外。

NoSQL 和 NewSQL 彻底改变了 空间的数据库。几年前，我们只有几个流行的数据库，全部基于关系 data 建模原则。今天，我们拥有一长串数据库：Hadoop 、Cassandra、CouchDB、Neo 4j 和 NuoDB，name 一些。 这些数据库中的每一个地址< /a> 某些特定的架构问题。

应用程序架构总是随着苛刻的业务需求和技术的发展而发展。

不同的架构方法和风格，例如大型机、客户端服务器、n-tier 和面向服务在不同时期流行。无论选择何种架构风格，我们总是习惯于构建一种或另一种形式的单体架构。微服务架构是现代业务需求的结果，例如敏捷性、交付速度、新兴技术以及从前几代架构中学习：

微服务帮助我们打破单体应用的界限，构建逻辑上独立的更小的系统系统，如上图所示。

单一职责原则是一个原则定义 作为 SOLID 设计模式的一部分。它规定一个单位应该只有 一项职责。

这意味着一个单元，无论是一个类、一个函数还是一个服务，都应该只有一个职责。在任何时候，两个单位都不会分担一项责任，或一个单位履行一项以上的责任。具有多个职责的单元表示紧密耦合：

如上图所示，Customer、Product和Order 是电子商务应用程序的不同功能。与其将它们全部构建到一个应用程序中，不如拥有三个不同的服务，每个服务只负责一项业务功能，这样对一项职责的更改不会损害其他职责。在上述场景中，Customer、Product 和 Order 被视为三个独立的微服务。

微服务是独立的、可独立部署的、自主的服务，对业务能力及其执行承担全部责任。他们捆绑所有依赖，包括库依赖；执行环境，例如 Web 服务器和容器；或抽象物理资源的虚拟机。

微服务和 SOA 之间的主要差异之一在于其自治级别。虽然大多数 SOA 实现提供 服务级抽象，但微服务更进一步抽象实现和执行环境。

在传统的应用开发中，我们build一个war或者aear，然后部署到JEE应用服务器中，比如JBoss、Weblogic、WebSphere 等等。我们可以将多个应用程序部署到同一个 JEE 容器中。在微服务方法中，每个微服务都将构建为嵌入所有依赖项的胖 jar，并作为独立的 Java 进程运行：

微服务也可以有自己的容器来执行，如上图所示。容器是可移植的、可独立管理的、轻量级 运行时环境。 Container 技术（例如 Docker）是微服务部署的理想选择。

在微服务世界中，服务是一等公民。微服务将服务端点公开为 API，并抽象出它们的所有实现细节。 internal 实现逻辑、架构和技术，包括编程语言、数据库、服务质量 机制等完全隐藏在服务 API 后面。

此外，在微服务架构中，不再有应用程序开发，而是组织将专注于服务开发。在大多数企业中，这需要在构建应用程序的方式上进行重大的文化转变。

在客户档案微服务中，数据结构、技术、业务逻辑等内部结构将被隐藏。它不会对任何外部实体公开或可见。访问将通过服务端点或 API 受到限制。例如，客户资料微服务可能会公开注册客户并将客户作为两个 API 供其他人进行交互。

精心设计的微服务 与单一业务能力保持一致；因此，它们只执行一项功能。因此，我们在大多数实现中看到的共同特征之一是占用空间较小的微服务。

在选择支持技术（例如 Web 容器）时，我们必须确保它们也是轻量级的，以便总体占用空间保持可控。例如，与更复杂的传统应用程序服务器（如 Weblogic 或 WebSphere）相比，Jetty 或 Tomcat 作为微服务的应用程序容器是更好的选择。

与 VMware 或 帮助我们将基础架构占用空间尽可能小="strong">Hyper-V。

如上图所示，微服务通常部署在 Docker 容器中，其中封装了业务逻辑和所需的库。这有助于我们在新机器、完全不同的托管环境，甚至跨不同的云提供商之间快速复制整个设置。由于没有物理基础设施依赖，容器化微服务很容易移植。

由于微服务是自治的，并且 abstract 一切都在服务 API 背后，因此不同的微服务可以有不同的架构。我们在微服务实现中看到的一些常见特征如下：

下图描述了一个多语种语言场景：

在前面的示例中，由于 Hotel Search 预计会有高交易量和严格的性能要求，因此实施<一个 id="id326725580" class="indexterm"> 使用 Erlang。为了支持预测搜索，Elastic Search 被用作数据存储。同时，酒店预订需要更多ACID事务性特征。因此，它是使用 MySQL 和 Java 实现的。内部实现 隐藏在定义为基于HTTP 的REST/JSON 的服务端点之后。

大多数微服务实现都是自动化，从开发到生产。

由于微服务将单体应用程序分解为许多较小的服务，因此大型企业可能会看到微服务的激增。除非自动化到位，否则很难管理大量微服务。微服务占用空间更小也有助于我们自动化微服务开发到部署生命周期。一般来说，微服务是端到端自动化的，例如自动化构建、自动化测试、自动化部署和弹性伸缩：

如图所示，自动化通常应用在开发、测试、发布和部署阶段。

上图中的不同块解释如下：

大多数大规模微服务实施都有一个支持生态系统。生态系统功能包括 DevOps 流程、集中式 log 管理、服务注册、API 网关、广泛的监控、服务路由和流量控制机制：

当支持能力到位时，微服务运行良好，如上图所示。

成功的微服务实现encapsulate 逻辑和数据within 服务。这导致了两种非常规的情况：

与将所有逻辑和数据整合到一个应用程序边界的传统应用程序相比，微服务分散了数据和逻辑。每个服务都与特定的业务能力保持一致，拥有自己的数据和逻辑：

上图中的虚线表示逻辑单体应用程序边界。当我们将其迁移到微服务时，每个微服务 A、B 和 C 创建自己的物理边界。

微服务通常不会像在 SOA 中那样使用集中式治理机制。微服务实现的共同特征之一是它们不依赖重量级的企业级产品，例如 Enterprise Service Bus（ESB）。相反，business 逻辑和智能作为服务本身的一部分嵌入。

使用 ESB 的零售示例如下所示：

典型的 SOA 实现如上图所示。 Shopping Logic 通过编排 Customer< /span>、订单和产品。另一方面，在微服务方法中，购物本身将作为一个单独的微服务运行，它与 Customer、Product 和 Order 以一种相当解耦的方式。

SOA 实现在很大程度上依赖于静态注册表和存储库配置来管理服务和其他工件。微服务为此带来了更加动态的性质。因此，静态治理方法被视为维护最新信息的开销。这就是大多数微服务实现使用自动化机制从运行时拓扑动态构建注册表信息的原因。

Antifragility 是一种成功实验过的技术在 Netflix。它是最强大的方法 在现代 软件开发中构建故障安全系统。

在反脆弱性实践中，软件系统一直受到挑战。软件系统通过这些挑战不断发展，并在一段时间内变得越来越好，以应对这些挑战。 Amazon 的 Game Day 演习和 Netflix 的 Simian Army good< /a> 这种反脆弱性实验的例子。

Fail Fast 是另一个概念构建容错、有弹性的系统。这种理念提倡预期失败的系统与构建永不失败的系统。必须重视系统失败的速度，如果失败，它可以多快 recover失败。通过这种方法，重点从 平均故障间隔时间（MTBF< /span>) 到 平均恢复时间 (MTTR) .这种方法的一个关键优势是，如果出现问题，它会自杀，并且不会对下游功能造成压力。

自我修复通常用于微服务部署，系统自动从故障中学习并自我调整。这些系统还可以防止未来的故障。

在第一个示例中，我们将review 一个假日门户网站--Fly By点。 Fly By Points 收集客户通过其在线网站预订酒店、航班或汽车时累积的积分。当客户登录 Fly By Points 网站时，他们将能够看到 points 累积的个性化优惠，可通过兑换积分获得，以及即将到来的旅行（如果有）：

假设前面的页面是登录后的主页。 2 Jeo、4 个性化优惠和 21123 积分。当用户单击每个框时，将查询并显示详细信息。

假日门户有一个基于 Java、Spring 的传统单体应用架构，如下：

如上图所示，Holiday Portal 的架构是基于 Web 的、模块化的，层与层之间有明确的分离。按照惯例，Holiday 门户也部署为部署在 Web 服务器上的单个 war 文件，例如 Tomcat。数据存储在一个包罗万象的后备关系数据库中。当复杂性较低时，这非常适合架构的目的。随着业务的增长，用户群不断扩大，复杂性也随之增加。

这导致交易量成比例增加。此时，企业应寻求将单体应用程序重新架构为微服务，以提高交付速度、敏捷性和可管理性：

在检查此应用程序的简单微服务版本后，我们将立即在此架构中看到一些内容：

假设表示层是使用客户端 JavaScript MVC 框架开发的，例如 Angular JS。这些客户端框架能够直接调用 REST 调用。

加载网页时，所有三个框，Trips，Offers，< /strong> 和 Points 将显示积分、优惠数量和旅行次数等详细信息。这将由每个盒子独立地使用 REST 对各自的后端微服务进行异步调用来完成。服务层的服务之间没有依赖关系。当用户单击任何框时，屏幕将转换并加载单击项目的详细信息。这将通过再次调用相应的微服务来完成。

第三个示例 是一个简单的旅行社门户应用程序。在此示例中，我们将看到同步 REST 调用和异步事件。

在这种情况下，门户只是一个容器应用程序，在门户中具有多个菜单项或链接。当请求特定页面时，例如单击菜单或单击链接时，将从特定微服务加载它们：

Travel Agent Portal 的架构支持 multiple< /a> 微服务如下图所示：

当客户请求预订时，将在内部发生以下事件：

这里有趣的因素是我们可以在不影响任何其他微服务的情况下更改微服务的 用户界面、逻辑和数据。

这是一种干净整洁的方法。可以通过组合来自不同微服务的不同屏幕来构建许多门户应用程序，特别是针对不同的用户社区。总体行为和导航将由门户应用程序控制。

除非页面的设计考虑到这种方法，否则这种方法会面临许多挑战。请注意，网站布局和静态内容将从 Content Management 中加载 System (CMS) 作为布局模板。或者，这可以存储在 Web 服务器中。站点布局可能包含用户界面的片段，这些片段将在运行时从微服务加载。

借助微服务，架构师和 开发人员可以灵活地为给定场景选择最合适的技术和架构。这为以更具成本效益的方式设计更合适的解决方案提供了灵活性。

由于微服务是自治和独立的，因此每个服务都可以使用自己的架构或技术或不同版本的技术运行。

下图显示了一个简单实用的 polyglot 架构与微服务示例：

需要审计所有系统事务并记录事务详细信息，例如请求和响应数据、发起事务的用户、调用的服务等。

如上图所示，虽然 Order 微服务和 Product 微服务等核心服务使用关系数据存储，但 Audit 微服务 persists Hadoop 文件系统 (HDFS) 中的数据。关系数据存储对于存储大量数据（例如审计数据）既不理想也不经济。在单体方法中，应用程序通常使用一个共享的单一数据库来存储 Order、Product 和 审核 数据。

在此示例中，审计服务是使用不同架构的技术微服务。同样，不同的功能服务也可以使用不同的架构。

在另一个示例中，可以在 Java 7 上运行 Reservation 微服务，而在 Java 8 上运行 Search 微服务。类似地，Order 微服务可以使用 Erlang 编写，而 Delivery 微服务可以使用 Go 语言编写。这些都不可能在单体架构中实现。

现代企业正在蓬勃发展向快速 获胜。微服务通过提供实验和快速失败的能力，是企业进行颠覆性创新的关键推动力之一。

由于服务相当简单且规模较小，因此企业可以负担得起尝试新流程、算法、业务逻辑等的费用。对于大型单片应用程序，实验并不容易、直接或成本效益高。企业必须花费大量资金来构建或更改应用程序以尝试新事物。使用微服务，可以编写一个小的微服务来实现目标功能，并以响应式的方式将其插入系统。然后可以用几个月的时间试验新功能。此外，如果新的微服务没有按预期工作，请更改或用另一个微服务替换它。与整体方法相比，变更成本将大大降低：

在航空公司预订网站的另一个示例中，航空公司希望在其预订页面中显示个性化的酒店推荐。建议必须显示在预订确认页面上。

如上图所示，编写一个可以插入到单体应用程序预订流程中的微服务很方便，而不是将这个需求合并到单体应用程序本身中。航空公司可能会选择从简单的推荐服务开始，并不断用更新的版本替换它，直到它满足所需的准确性。

由于微服务更小 工作单元，它启用 我们实现选择性可扩展性 和其他服务质量（QoS）。

对于应用程序中的不同功能，可扩展性要求可能不同。单片应用程序通常被打包为一个单一的战争或耳朵。因此，应用程序只能作为一个整体进行扩展。没有选项可以扩展模块或子系统级别。 I/O 密集型功能在传输高速数据时，很容易降低整个应用程序的服务水平。

在微服务的情况下，每个服务都可以独立地扩大或缩小。由于可以有选择地为每个服务应用可扩展性，因此使用微服务方法的扩展成本相对较低。

在实践中，scale 应用程序有许多不同的方法，这在很大程度上限制了应用程序的架构和行为应用。 Scale Cube 主要定义了三种扩展应用程序的方法：

当 Y 轴缩放应用于单体应用时，它将单体分解为与业务功能一致的更小的单元。许多组织成功地应用了这种技术来摆脱单一应用程序。原则上，生成的功能单元与微服务特性是一致的。

例如，在一个典型的航空公司网站上，统计数据表明航班搜索与航班预订的比率可能高达 500:1。这意味着每 500 次搜索交易就有一次预订交易。在这种情况下，搜索需要比预订功能多 500 倍的可扩展性。这是选择性缩放的理想用例：

解决方案是区别对待搜索请求和预订请求。对于单体架构，这只能通过 Z 在比例立方体中进行缩放。然而，这种方法代价高昂，因为在 Z 规模下，整个代码库都将被复制。

在上图中，Search 和 b 被设计为不同的微服务，因此 Search 的缩放比例与 Booking 不同。在图中，Search 有三个实例，Booking 有两个实例。选择性可扩展性不仅限于实例的 number，如上图所示，还包括微服务是架构的。对于搜索，内存中数据网格（IMDG ) 例如 Hazelcast 可以用作数据存储。这将进一步提高搜索的性能和可扩展性。当一个新的 Search 微服务实例被实例化时，一个额外的 IMDG 节点将被添加到 IMDG 集群中。预订不需要相同级别的可扩展性。对于 Booking，Booking 微服务的两个实例都连接到数据库的同一个实例。

微服务是自包含的独立部署模块，使我们能够替换一个微服务与另一个类似的微服务。

许多大型企业遵循购买与构建策略来实施软件系统。一个常见的场景是在内部构建大部分功能，并从外部专家那里购买某些利基功能。这对传统的单片应用程序提出了挑战，因为这些应用程序组件具有很高的内聚性。尝试将第三方解决方案插入单体应用程序会导致复杂的集成。对于微服务，这不是事后的想法。在架构上，一个微服务可以很容易地被另一个开发的微服务替换，无论是在内部还是由第三方的微服务扩展：

航空业的定价引擎很复杂。不同路线的票价是使用称为定价逻辑的复杂数学公式计算的。航空公司可以选择购买定价 来自市场的引擎，而不是在内部构建产品。在 monolithic 架构中，Pricing 是Fares 和 Booking 的功能。在大多数情况下，定价、票价和预订是硬连线的，几乎不可能分离。

在精心设计的微服务系统中，Booking、Fares 和 Pricing 将是独立的微服务。替换定价微服务对任何其他服务的影响很小，因为它们都是松散耦合和独立的。今天，它可能是第三方服务，明天，它可以很容易地被另一个第三方服务或另一个本土服务取代。

微服务帮助我们构建自然有机的系统。在将单体系统逐渐迁移到微服务时，这一点非常重要。

有机系统是通过向其添加越来越多的功能而在一段时间内横向增长的系统。在实践中，应用程序在其生命周期中变得难以想象，并且在大多数情况下，应用程序的可管理性在同一时间段内急剧下降。

微服务都是关于独立可管理的服务。这使我们能够在需要时不断添加越来越多的服务，而对现有服务的影响最小。建立这样的系统不需要大量的资本投资。因此，企业可以继续建设作为其运营支出的一部分。

一家航空公司的忠诚度系统是多年前建立的，针对个别乘客。在航空公司开始为其企业客户提供忠诚度福利之前，一切都很好。公司客户是归入公司的个人。由于当前系统的核心数据模型是扁平化的，以个人为目标，因此企业需求需要对核心数据模型进行根本性的改变，因此需要进行大量的返工来整合这一需求。

如下图所示，在基于微服务的架构中，客户信息将由 Customer 微服务管理，忠诚度由 Loyalty 微服务管理：

在这种情况下，很容易添加新的 Corporate Customer 微服务来管理企业客户。注册公司后，个人成员将被推送到客户微服务以照常进行管理。 Corporate Customer 微服务通过聚合来自 Customer 微服务的数据来提供企业视图。它还将提供服务来支持企业特定的业务规则。使用这种方法，添加新服务对现有服务的影响很小。

由于微服务的 size 更小并且依赖最小，它们允许迁移使用报废技术的服务以最低的成本。

技术变革是软件开发的障碍之一。在许多传统的单片应用程序中，由于技术的快速变化，今天的下一代应用程序很容易成为遗留应用程序，甚至在发布到生产之前。架构师和开发人员倾向于通过添加抽象层来增加对技术变化的保护。然而，实际上，这种方法并不能解决问题，而是会导致系统过度设计。由于技术升级通常具有风险且成本高昂，并且没有直接的业务回报，因此业务可能不乐意投资于减少应用程序的技术债务。

使用微服务，可以单独更改或升级每个服务的技术，而不是升级整个应用程序。

例如，将具有 500 万行写在 EJB 1.1 和 Hibernate 上的应用程序升级到 Spring， JPA，而 REST 服务几乎就像重写整个应用程序一样。在微服务世界中，这可以逐步完成。

如上图所示，虽然旧版本的服务在旧版本的技术上运行，但新服务的开发可以利用最新的技术。与增强单体应用程序相比，使用报废技术迁移微服务的成本将大大降低。

由于微服务将 service 运行时环境与服务本身打包在一起，因此可以使服务的多个版本在同一环境中共存.

在某些情况下，我们将不得不同时运行同一服务的多个版本。零停机时间提升，即必须从一个版本优雅地切换到另一个版本，就是这种情况的一个例子，因为会有一个时间窗口，两个服务必须同时启动和运行。对于单体应用程序，这是一个复杂的过程，因为在集群的一个节点中升级新服务很麻烦，例如，这可能会导致类加载问题。 Canary 版本（仅向少数用户发布新版本以验证新服务）是多个服务版本必须共存的另一个示例。

使用微服务，这两种场景都很容易管理。由于每个微服务都使用独立的环境，包括嵌入式 Tomcat 或 Jetty 等服务监听器，因此可以发布多个版本并优雅过渡，不会出现很多问题。消费者在查找服务时，会查找特定版本的服务。例如，在金丝雀发布中，向用户 A 发布了一个新的用户界面。当用户 A 向微服务发送请求时，它会查找金丝雀发布版本，而所有其他用户将继续查找上一个生产版本。

需要注意数据库级别，以确保数据库设计始终向后兼容，以避免破坏性更改。

如下图所示，客户服务的版本 V01 和 V02 可以共存，因为它们互不干扰，给定各自的部署环境：

可以在网关设置路由规则，将流量转移到特定实例，如图所示。或者，客户端可以请求特定版本作为请求本身的一部分。在图中，网关根据发出请求的区域选择版本。

微服务帮助我们构建自组织系统。支持自动化部署的自组织系统将具有弹性，并具有自愈和自学习能力。

在架构完善的 microservice 系统中，服务不知道其他服务。它接受来自选定队列的消息并处理该消息。在该过程结束时，它可能会发出另一条触发其他服务的消息。这使我们可以在不分析对整个系统的影响的情况下将任何服务放入生态系统。基于输入和输出，服务将自组织进入生态系统。不需要额外的代码更改或服务编排。没有中央大脑来控制和协调这些过程。

想象一个现有的通知服务，它监听 INPUT 队列并发​​送 通知到简单邮件传输协议（SMTP）服务器如下：

如果稍后需要引入个性化引擎以在将消息发送给客户之前对其进行个性化，则个性化引擎负责将消息的语言更改为客户的母语。

更新后的服务联动如下图：

使用微服务，将创建一个新的个性化服务来完成这项工作。输入队列将在外部配置服务器中配置为 INPUT。个性化服务将从 INPUT 队列中提取消息（之前是通知服务使用的），并将消息发送到 OUTPUT 完成进程后排队。然后通知服务的输入队列将发送到 OUTPUT。从下一刻起，系统自动采用这个新的消息流。

微服务使我们能够开发透明的软件系统。传统系统通过本地协议相互通信，因此表现得像一个黑盒应用程序。除非明确发布，否则业务事件和系统事件很难理解和分析。现代应用程序需要数据进行业务分析，了解动态系统行为，分析市场趋势，还需要对实时事件做出响应。事件是数据提取的有用机制。

架构良好的微服务始终处理输入和输出事件。任何服务都可以利用这些事件。提取后，事件可用于各种用例。

例如，企业希望实时查看按产品类型分类的订单速度。在单体系统中，我们需要考虑如何提取这些事件，这些事件可能会导致系统发生变化。

下图展示了添加了新的事件聚合服务 不影响现有服务：

在微服务世界中，每当创建订单时，Order Event 就已经发布。这意味着只需添加一个新服务来订阅 相同的主题，提取事件，执行请求聚合，并推送另一个事件以供仪表板使用。

微服务是 DevOps 的关键推动力之一。 DevOps 作为一种实践被许多企业广泛采用，主要是为了提高交付和敏捷性的速度。 DevOps 的成功采用需要文化变革和流程变革，以及架构变革。它提倡敏捷开发、高速发布周期、自动测试、自动基础设施供应和自动部署。使用传统的单片应用程序很难实现所有这些过程的自动化。微服务并不是最终的答案，但微服务在许多 DevOps 实施中处于中心阶段。许多 DevOps 工具和技术也在围绕微服务的使用而发展。

考虑到单体应用程序需要数小时才能完成完整构建，启动应用程序需要 20 到 30 分钟，可以看出这种应用程序对于 DevOps 自动化来说并不理想。很难在每次提交时自动进行持续集成。由于大型单体应用程序对自动化不友好，因此也很难实现持续测试和部署。

另一方面，占用空间小的微服务对自动化更加友好，因此它们可以更轻松地支持这些需求。

微服务还支持更小、更专注的敏捷团队进行开发。团队将根据微服务的边界进行组织。