微服务架构核心要素与应用

基于微服务的软件架构与方法

1. 引言

如今，一些趋势正在推动应用程序架构的演进。最终用户和任务期望通过下一代客户端（包括移动设备）获得丰富、交互性强且动态的体验。下一代应用程序必须具备高可扩展性、高可用性，并能够与云环境进行交互。

组织通常希望定期频繁地推出更新。因此，开发仅向桌面浏览器提供HTML的简单单体Web应用程序已不再足够。多年来，大多数企业软件应用程序都是作为单体式架构设计和开发的大型、复杂的单体应用程序。在单体式方法中，应用程序被分解为分层架构，例如模型‐视图‐控制器。然而，应用程序仍然根据各个应用程序所负责的功能级别进行优化，因此导致它们在管理上变得庞大且复杂。单体应用是指所有逻辑都在一个应用服务器中运行的应用程序。

典型的单体应用程序规模较大，由多个团队构建，每次变更都需要精心协调部署。它们通常具有庞大的应用程序代码库，当新开发者加入大型项目团队时，往往面临较大的适应挑战，需要花费大量时间来熟悉代码库。对于单体应用程序而言，即使是很小的更改也可能对回归测试产生广泛的影响。单体应用程序需要积累大量回归测试用例的历史记录，这增加了测试周期以及所需测试人员的数量，但任务和业务部门希望其团队能够快速响应新的需求。微服务架构风格支持更频繁的交付和更快的交付时间，使应用程序所有者能够更快获得反馈并对需求进行调整。大型单体应用程序通常具有广泛的业务范围和众多基础设施接触点，任何应用程序的变更都可能导致多次审查和批准，从而延长部署周期。通过采用基于单一平台的微服务架构风格，服务管理团队可以更轻松地支持多个产品和服务团队。通过对多个微服务项目团队统一实施自动化部署、日志记录和监控实践，可以实现效率提升。因此，迫切需要重新审视软件应用程序的新架构风格。

2. 微服务的要素

微服务的定义

微服务是小型、自治的服务，它们协同工作。[1] 关键在于“小型”和“自治”。微服务是一种架构风格，其中大型复杂的软件应用程序由一个或多个服务组成。微服务可以彼此独立部署，且相互之间松耦合，每个微服务仅专注于完成一项任务。在典型的架构中，微服务支持多个客户端。此外，在基于微服务的典型应用程序中，还需考虑多个因素。称为十二要素应用，将在下一节中进行回顾。

微服务对比

微服务是一个独立的工作单元，在功能上足够小，能够独立运行。微服务之间的部署必须无需任何协调。松耦合使得应用程序能够频繁且快速地部署，从而将消费者急需的功能和能力快速交付。此类比较的示例见表1。

微服务应使用最适合最终目标的编程语言来构建。它们组合在一起形成一个复杂的应用程序，且无需使用同一种编程语言编写。在某些情况下，Java 可能是合适语言，而在其他情况下则可能是 Python。微服务之间的通信通过语言中立的API进行，通常是基于超文本传输协议（HTTP）的资源应用程序编程接口（API），例如 REST。

表1：单体式架构与微服务架构的比较。[2]

特征	单体式架构	微服务架构
组件化	使用库作为组件	使用服务作为组件
部署	整体部署	独立部署
技术多样性	通常使用单一技术栈	支持多语言、多平台
可维护性	修改影响范围大	局部修改不影响整体
扩展性	整体扩展	按服务独立扩展

微服务的特征

在微服务架构中，有几个需要考虑的特性。我们将在下文进行回顾和列举。

微服务需要围绕业务能力进行设计。这种方法针对该业务领域采用全栈式软件实现，包括用户界面、持久化存储以及任何外部协作。因此，团队是跨职能的，具备开发所需的全方位技能：用户体验、数据库和项目管理。[3]

上述特性意味着必须遵循服务的组件化模型。因此，组件是可独立替换和升级的软件单元。[3] 微服务架构可以使用传统库，但其主要方式是通过将软件分解为服务来进行组件化，这些服务是通过 Web 服务请求或远程过程调用等机制进行通信的组件。

使用服务作为组件（而非库）的主要原因是服务可以独立部署。一个应用程序若由多个库组成并运行在单个进程中（可能任何一个组件的更改），都将导致必须重新部署整个应用程序。然而，如果该应用程序被分解为多个服务，则大多数情况下只需重新部署发生变更的单个服务即可。使用服务作为组件的另一个原因是能够提供更明确的组件接口。大多数编程语言缺乏良好的接口定义机制；因此，在微服务架构中，基于接口的组件化是合理的选择。

单体应用的开发工作采用项目模型，其目标是交付软件，交付后即认为软件已完成。完成后，软件被移交给维护团队，项目组则转向新的项目。而微服务方法则采用持续开发和持续集成（CI/CD）流程，软件在此流程中持续开发并不断添加新功能。该流程会持续与开发、测试、预发布和生产环境进行集成。

单体式方法需要为应用层提供智能通信系统，例如企业服务总线（ESB），其中 ESB 产品通常包含用于消息路由、编排、转换和应用业务规则的复杂功能。[2]

微服务采用了一种不同的方法：智能端点和笨管道。[3] 由微服务构建的应用程序将其自身的逻辑解耦，接收请求，适当地应用逻辑，并生成响应。这种通信使用简单的类REST协议，而不是复杂的协议（如WS或BPEL）或通过中央工具进行编排。此外，通常通过轻量级消息总线进行消息传递。所选择的基础设施通常是简单且功能较弱的实现，例如RabbitMQ或ZeroMQ，它们提供可靠的异步架构。而智能仍然存在于服务中负责生成和消费消息的端点上。

采用持续集成/持续交付的微服务需要基础设施自动化技术。在此模式下，开发团队会自动将服务部署到每个新环境。开发团队应用基础设施自动化技术的另一个领域是在生产环境中管理微服务。

由于微服务被设计为服务组件，因此需要将应用程序设计为能够容忍服务故障。任何服务调用都可能因基础设施不可用而失败。与单体设计相比，这是一个缺点，因为它引入了额外复杂性。其结果是微服务团队了解服务故障如何影响最终用户体验。Netflix的猴子军团会在工作日主动引发服务故障，包括数据中心进程的故障，以测试应用程序的弹性和监控能力。[3] 服务可能随时发生故障，因此快速检测故障并自动恢复服务至关重要。微服务应用程序非常重视对应用程序的实时监控，既检查架构元素（例如数据库每秒接收多少请求），也检查业务相关指标（例如每分钟接收多少订单）。微服务团队通常期望为每个单独的服务建立监控和日志记录机制，例如通过仪表板展示状态以及各类运行和业务相关指标。断路器状态、当前吞吐量和延迟等详细信息也是这一特性的体现。

微服务方法在逻辑和数据的去中心化方面表现良好。从抽象层面来看，应用程序被划分为独立的组件。另一种理解去中心化的方式是领域驱动设计（DDD）中的限界上下文概念。[3] 领域驱动设计将复杂领域划分为多个限界上下文，并描绘它们之间的关系。这一过程对于单体式架构和微服务架构都具有实用价值，但服务与上下文边界之间存在一种天然的对应关系，有助于明确并加强分离，正如我们在业务能力一节中所描述的那样。微服务还实现了数据存储决策的去中心化。尽管单体应用倾向于使用单一逻辑数据库来持久化数据，微服务则更倾向于让每个服务管理自己的数据库，这些数据库可以是相同数据库技术的不同实例，也可以是完全不同的数据库系统，后者也称为多语言持久化。虽然可以在单体应用中使用多语言持久化，但它在微服务中出现得更为频繁。

微服务设计规定将应用程序拆分为多个服务组件：同时还需考虑治理和管理方法。单体应用的方法采用集中式治理，这意味着倾向于在单一技术平台上实现标准化。这种方法可能过于受限。通过将单体应用的组件拆分为服务，我们在构建每个组件时可以选择使用的编程语言和风格。开发团队可以使用他们熟悉的语言来编写每个服务——例如 Node.js、Python、Java 或 C++。同样的方法也可应用于数据库平台。构建微服务的团队对标准有着不同的做法。他们更倾向于开发有用的工具，供其他开发者用来解决类似的问题，而不是使用一组既定的标准。这些工具通常从实际实现中提取出来，并与更广泛的团队共享；有时会采用内部开源模式，但不仅限于此。例如 git 和 github 已成为事实上的首选版本控制系统。

十二要素应用方法和微服务

一种被称为十二要素应用方法论的通用方法应运而生，旨在为采用微服务方法构建结构良好且可扩展的应用程序提供指导。应用程序部署过程可能复杂且繁琐。虚拟化、网络和运行时环境的设置仅仅是其中涉及的部分挑战。十二要素应用方法论有助于创建一个框架，以组织该过程，从而维护健康且可扩展的应用程序。[4] 以下段落将解释如何满足十二要素应用方法论的标准，同时应对应用程序基础设施和部署设置。

代码库

一个十二要素应用使用诸如git之类的版本控制系统。用于跟踪修订的数据库副本被称为代码仓库。代码库是指任何单个仓库或共享同一个根提交的一组仓库。[4] 一个十二要素应用要求代码库与应用程序之间具有一一对应关系。如果存在多个代码库，则构成一个包含多个应用程序的分布式系统。分布式系统中的每个组件都是一个应用程序，且每个组件都可以单独符合十二要素原则。多个应用程序共享同一份代码属于违反12-Factor原则。

每个应用程序仅有一个代码库，但该应用程序会有多个部署实例。部署是指应用程序的一个运行实例，通常包括一个生产站点和一个或多个预发布站点。

此外，每位开发者都在其本地开发环境中运行着该应用的一个副本，每个副本也都视为一次部署。

依赖

十二要素应用会声明所有依赖，从不依赖通过依赖声明清单隐式存在的系统级软件包。显式依赖规范应用于生产环境和开发环境。显式依赖声明的优势在于它简化了新开发人员对应用程序的初始化设置。新开发人员可将代码库检出到其开发机器上，仅需预先安装语言运行时和依赖管理器，即可设置运行该应用程序所需的一切。

使用确定性的构建命令进行代码构建。十二要素应用也不依赖于任何系统工具的隐式存在。这些工具可能已经存在于部署和测试系统中，但无法保证它们在应用可能运行的所有系统上都存在。

配置

应用程序的配置通常在不同的部署环境（如预发布环境、生产环境和开发环境）之间有所变化。配置可能包括数据库的资源句柄、外部服务的凭据、主机名等。十二要素应用要求将配置与代码严格分离，因为配置会随着部署而变化，而代码不会。[4] 一种配置管理方法是使用不提交到版本控制中的配置文件。然而，配置文件往往分散在不同的位置并采用不同的格式，导致难以集中查看和管理。另一种方法是将配置存储在环境变量中。环境变量易于在部署之间更改，且无需修改任何代码。此外，还有一种配置管理方法是分组。有时应用程序会将配置批处理到以特定部署命名的命名组中（通常称为“环境”），例如开发、测试和生产环境。在十二要素应用中，环境变量是细粒度的控制，每个环境变量彼此独立。这种模型能够随着应用程序在其生命周期中自然扩展到更多部署而平滑地扩展。

后端服务

后端服务是应用程序在其正常运行过程中通过网络使用的服务。[4] 示例包括数据存储、消息/队列系统、用于出站邮件的SMTP服务以及缓存系统。这也包括第三方和非传统（如云）服务。十二要素应用的代码不会区分本地服务与第三方服务。十二要素应用的一个部署应能够在不修改应用代码的情况下，将本地数据库（MySQL）替换为由第三方管理的数据库（例如亚马逊 S3）。每个独立的后端服务都是一种资源。例如，一个 MySQL 数据库就是一种资源。

十二要素将这些数据库视为附加资源，这意味着松耦合。资源可以随意附加和分离以进行部署。例如，如果应用的数据库由于硬件问题出现异常，应用管理员可能会从最近的备份中恢复并启动一个新的数据库服务器。

构建、发布与运行

一个代码库通过三个阶段交付到部署——构建、发布与运行。第一阶段是构建，它将代码仓库转换为可执行包。使用由部署流程指定的提交版本的代码，构建阶段会收集依赖并编译二进制文件和资源文件。[4] 第二阶段是发布，它将构建阶段生成的构建产物与部署的当前配置相结合。发布版本包含构建产物和配置，已准备好在部署环境中执行。第三阶段是运行，它通过针对选定的发布版本启动一组应用程序来在执行环境中运行应用程序。

十二要素应用严格区分构建、发布和运行这三个阶段。每当部署新代码时，构建阶段由应用程序的开发人员发起。运行时执行会在某些情况下自动进行，例如服务器重启或进程管理器重启崩溃的进程。因此，运行阶段应尽可能简单且稳定，因为任何问题都可能导致应用程序无法运行。构建阶段可以更复杂，因为开发者在管理部署时能立即发现错误。

进程

应用程序在环境中作为一个或多个进程运行。在一端，代码是独立运行的，执行环境是安装了语言运行时的开发者的本地系统。[4] 在另一端，复杂应用的生产部署可能会使用多个进程。12-Factor 进程是无状态且无共享的，因此任何持久化数据都必须存储在后端服务中，通常是数据库。进程的内存空间或文件系统可用于单事务缓存；例如，下载大文件、执行操作，并将操作结果存储到数据库中。十二要素应用假设在内存或磁盘上缓存的任何数据对于作业请求来说都是不可用的。一些基于 Web 的系统依赖于在进程内存中缓存用户会话数据，并期望来自同一访问者的后续请求被路由到同一进程。粘性会话违反了12-Factor 原则，绝不应使用或依赖。会话状态数据适合存储在提供时间过期功能的数据存储中。

端口绑定

十二要素应用有时在Web服务器容器内执行，完全自包含，不依赖于将Web服务器通过运行时注入到执行环境中来创建面向Web的服务。[4] Web应用通过绑定到端口并监听该端口上的请求，以服务的形式导出 HTTP。在本地开发环境中，一个服务URL，例如 http://localhost:5000/ 用于访问服务导出应用。在部署过程中，路由层负责将来自面向公众的主机名的请求路由到绑定端口的Web进程。这是通过依赖声明将Web服务器库添加到应用中实现的。这一过程完全发生在用户空间，即在应用代码内。与执行环境的约定是绑定到端口以响应请求。

并发性

在十二要素应用中，进程是一等公民 [4]。十二要素应用中的进程基于Unix进程模型构建。利用此模型，开发者可以通过为每种类型的工作分配相应的进程类型来设计应用程序以处理多样化的工作负载。例如，HTTP请求可由Web进程处理，后台任务可由工作进程处理。这种进程模型是一种横向扩展的方法。无共享、分区的进程架构为并发性提供了简单的实现方式。十二要素应用的进程应利用操作系统的进程管理器来管理任务输出流，并处理用户发起的重启和关闭。

易处置性

十二要素应用的进程是可处置的，因为它们可以轻松且即时地启动或停止。[4] 这使得代码和配置能够实现快速、弹性的扩展以及快速部署。较短的进程启动时间提供了敏捷扩展能力，并支持将进程迁移至不同的部署环境。通常情况下，一个进程只需几秒钟即可启动，直到进程可以接收请求或任务为止。因此，正确的进程关闭方式是将当前任务返回到工作队列中。推荐的做法是使用健壮的队列后端，在客户端断开连接或超时的情况下将任务重新返回队列。进程还应具备应对底层硬件故障导致突然终止的韧性。十二要素应用的设计需能够处理意外的、非正常终止的情况。

开发与生产环境一致性

开发与生产环境之间的差距通常源于时间差距，即开发人员发布代码而运维人员进行部署，或者源于开发与运维团队之间的工具差距，因为他们可能使用不同的工具。十二要素应用旨在实现持续开发，使环境间的差距最小化。此外，十二要素应用在开发和生产环境中应使用相同的后端服务，即使适配器掩盖了后端服务之间的任何差异。后端服务之间的差异可能导致不兼容性，从而破坏持续部署的目的。针对不同后端服务的适配器仍然有用，因为它们使得迁移到新的后端服务相对简单。但应用程序的所有部署（开发者环境、预发布环境、生产环境）都应使用相同类型和版本的各个后端服务。

日志

日志提供了应用程序的进程和后端服务按时间排序的状态，通常被写入磁盘文件中。十二要素应用不应尝试写入或管理日志文件。在本地开发过程中，开发者通过终端的前台查看进程流以观察进程行为。[4] 在预发布或生产部署中，每个进程流将由执行环境捕获，与其他来自该应用的所有流聚合在一起，并路由到一个或多个最终目的地进行查看和长期归档。这些归档目的地对应用程序不可见，也无法由应用程序配置，而是完全由执行环境管理。

管理流程

在十二要素应用中，管理任务应作为一次性进程运行。开发人员通常会使用一次性管理或维护任务来执行诸如数据库迁移、控制台操作，或检查应用程序模型与生产数据库的一致性等操作。[4] 一次性管理进程应在与应用程序的常规长时进程相同的环境中运行，并针对一个发布版本，使用相同的代码库和配置。管理代码必须随应用程序代码一起发布，以避免同步问题。

额外考虑因素

还需要考虑其他因素，包括通过自动扩展和负载均衡器等机制进行服务扩展。同时，独立服务与外部服务的集成也需要考虑。此外，还需考虑调试技术。最后，在微服务架构中还需要审查安全要求。

3. 微服务架构

微服务架构由多个组件组成。这些组件协同工作，提供之前章节中讨论过的分布式服务。主要组件如下。

容器

容器以Linux容器以及多种商业实现（如Docker）的形式已经部署使用了一段时间。Linux容器是自包含的执行环境，拥有独立的中央处理器、内存、块I/O和网络资源，并共享宿主操作系统的内核。其使用体验类似于虚拟机，但无需客户机操作系统的开销和启动负担。

容器的两个关键要素是 Linux cgroups 和命名空间，它们是 Linux 内核的特性，用于隔离容器以及在主机上运行的其他进程。[5] Linux 命名空间最初由 IBM 开发，将一组系统资源进行封装，并将其呈现给进程，使其看起来这些资源是专用于该进程的。Linux cgroups，最初由谷歌开发，用于控制一组进程对中央处理器和内存等系统资源的隔离和使用。例如，如果你有一个占用大量中央处理器周期和内存的应用程序（如科学计算应用程序），你可以将该应用程序放入一个控制组中，以限制其对中央处理器和内存的使用。命名空间处理单个进程的资源隔离，而控制组则管理一组进程的资源。

基于镜像的容器将应用程序与各自的运行时堆栈打包，从而使生成的容器独立于宿主操作系统。因此，可以运行同一应用程序的多个实例，每个实例为不同的平台开发。[5] 之所以能够实现这一点，是因为容器运行时和应用程序运行时以镜像的形式进行部署。

图4描述了一个典型的基于镜像的容器。容器是运行应用程序的活动组件。每个容器都基于包含必要配置数据的镜像。当从镜像启动容器时，会在该镜像之上添加一个可写层。镜像是容器配置的静态快照，属于只读层。所有更改都在最上层的可写层中进行，并且只能通过创建新镜像来保存更改。每个镜像依赖于一个或多个父镜像。平台镜像是没有父镜像的镜像。平台镜像定义了运行时环境，容器化应用程序运行所需的软件包和实用工具。

服务通信

在单体应用中，组件通过函数调用进行调用。相比之下，基于微服务的服务通过进程间通信（IPC）机制进行交互。在为服务选择IPC机制时，必须考虑服务之间的交互方式。其中一个维度是交互为同步还是异步。在同步交互中，客户端期望服务及时响应，甚至可能在等待期间阻塞。而在异步交互中，客户端在等待响应时不会阻塞。此外，还存在其他类型的一对一交互：请求/响应，即客户端向服务发出请求并等待响应；通知，即客户端向服务发送请求，但不需要也不发送回复；请求/异步响应，即客户端向服务发送请求，服务随后异步回复。一对多交互也有不同类型：发布/订阅，即客户端发布通知消息，由零个或多个感兴趣的服务消费；发布/异步响应，即客户端发布请求消息，然后等待一段时间以接收来自感兴趣服务的响应。每个服务通常会结合使用这些交互方式。接下来，让我们回顾开发者可以在微服务架构中实现的IPC机制。

IPC技术

有多种IPC机制可应用于微服务。服务可以使用基于同步请求/响应的通信机制，例如基于HTTP的REST或Thrift。或者，它们也可以使用异步、基于消息的通信机制，例如高级消息队列协议（AMQP）。[6]

在异步系统中，客户端通过发送消息向服务发出请求。如果服务进行回复，则会向客户端发送一条单独的消息。由于通信是异步的，客户端不会阻塞等待回复，而是基于无法立即收到回复的前提来编写。可选择的开源消息系统有很多，包括 RabbitMQ、Apache Kafka、Apache ActiveMQ。

当使用同步的、基于请求/响应的IPC机制时，客户端向服务发送请求。该服务处理请求并返回响应。在许多客户端中，发出请求的线程在等待响应时会被阻塞。可选择的协议有很多，其中两种流行的协议是REST和Thrift。让我们先来看一下REST。

服务注册与发现

在微服务应用中，运行的服务实例集会动态变化，包括网络位置。因此，为了使客户端能够向服务发出请求，必须使用服务发现机制。服务发现的一个关键部分是服务注册表。服务注册表是可用服务实例的数据库。服务注册表提供管理API和查询API。服务实例通过管理API向服务注册表注册和注销。系统组件使用查询API来发现可用的服务实例。有两种服务发现模式：客户端发现和服务端发现。在采用客户端服务交付的系统中，客户端查询服务注册表，选择一个可用实例并发出请求。在使用服务端发现的系统中，客户端通过路由器发出请求，路由器查询服务注册表并将请求转发到一个可用实例。服务实例向服务注册表注册和注销有两种方法。一种方法是服务实例自行向服务注册表注册，即自注册。另一种方法是由系统组件代表服务处理注册和注销。在某些部署环境中，需要使用如etcd和Apache Zookeeper等服务注册表来搭建服务发现基础设施。而在其他部署环境中，服务发现功能是内置的。例如，Kubernetes会自动处理服务实例的注册和注销。

4. 航空航天应用示例

通过采用基于微服务的方法和架构，可以实现多个航空航天行业特定的用例。本节提供了一些可由航空航天行业以及其他行业利用的用例。

任务数据分析

数据分析传统上具有实时、批处理和归档的特性。从技术上讲，该解决方案涉及从数字源访问航空航天传感器数据。如果传感器是模拟信号，则架构中需要有某个组件将模拟信号转换为数字信号，例如通过现场的模数转换（AD）设备。分析服务可被开发用于执行小型任务，这些任务共同实现任务目标。关键在于，不同的服务可以在多种系统上独立运行并被独立调用。例如，边缘分析服务可在网络边缘设备（如路由器）上运行，而批处理服务则可在数据中心的Hadoop集群上运行。

设备健康监控

设备健康监控和预测性分析技术的部署有望为航空航天与国防公司带来效益。此用例可采用微服务架构来实现。例如，假设一次航天飞行中出现了间歇性液压故障代码。设备健康监控系统执行本地分析服务，并向地面站发送一条通知消息，维护控制人员在地面站运行故障详情服务。在确定可能的问题后，维护控制部门启动缓解流程。当飞机着陆后，地勤人员在计划清洁和加油时间内更换压力变送器。在此用例中，微服务在本地执行了预测性分析，仅将通知传输给地面 crew。因此，设备健康数据可以在本地收集，然后传输到核心数据中心进行批量历史与趋势服务。

制造可见性与管理

基于微服务的架构可为制造业提供航空航天生产线信息，帮助制造工厂员工提升工厂效率。例如，生产现场的车间经理可通过互联车间和可视化工具，获取每台设备的运行效率，从任何位置查看生产情况，并缩短决策和行动所需时间。制造设施和设备装配线可以连接到一个服务，该服务将收集有关工厂状态的实时数据。因此，设施管理人员和生产人员无需再依赖控制室管理，便可轻松获取实时信息并更高效地协作。例如，当生产线上出现质量问题时，他们可以在问题扩大导致所有产品报废之前及时停机。这种架构的优势不仅限于企业内部，还可延伸至各类供应商和第三方服务提供商，涵盖服务、耗材和资本货物等领域。

5. 总结

无论微服务架构未来是否会成为开发者的首选风格，它在应用程序的设计和实现方面显然具有显著优势。然而，与任何新技术的采用一样，也存在一些挑战，例如需求不正确。如果我们从错误的需求出发，那么无论我们开发、部署或扩展系统的速度有多快都无关紧要。此外，目前还缺乏从运行角度支持微服务的框架。同时，维持微服务的运行和可用性需要大量的DevOps技能。最后，当将现有的单体系统拆分为协作组件时，会在它们之间引入接口。每个接口都需要在各个版本发布期间进行维护，尽管通过采用兼容早期版本等最佳实践可以在一定程度上缓解这一问题。未来，我们预计将出现描述微服务的标准。目前，只要通过HTTP暴露JavaScript对象表示法（JSON）或可扩展标记语言（XML）以提供 REST API，就可以使用任何技术来创建微服务。因此，微服务方法的前景是光明的，应用程序将随着时间的推移迁移到这一修订后的架构。