SOA 与微服务：有什么区别？

如果您从事 IT 或云计算领域的工作，可能已经注意到面向服务架构 (SOA) 与微服务的争论。毕竟，现在每个人都在谈论微服务和敏捷应用程序。

乍一看，这两种方法听起来很相似，在某些方面确实如此。两者都涉及用于敏捷应用开发和部署的云或混合云环境，并且都可以扩展以满足大数据的速度和运营需求。两者都将大型复杂应用拆分为更小、更灵活的组件，从而更易于管理。而且与传统的单体架构不同，每个服务都有自己的职责。

然而，即便有这些关键的共同点，对这两种方法的仔细分析仍能发现重要差异。

面向服务的架构 (SOA) 是一种企业范围的应用程序组件软件开发方法，它利用了可重复使用的软件组件或服务。在 SOA 软件架构中，每个服务都由运行特定业务功能所需的代码和数据整合组成，例如，检查客户的信用、登录网站或处理抵押贷款的应用程序。

服务接口提供了松散耦合，这意味着调用它们时几乎不需要了解底层集成的具体实现方式。由于这种松散耦合以及服务的发布方式，开发团队可以通过在企业内的其他应用中重复使用组件来节省时间。这既是一个优势，也是一种风险。由于企业服务总线 (ESB) 提供了共享访问，如果出现问题，也可能影响其他连接的服务。

XML 数据是基于 SOA 架构的解决方案的关键要素。例如，基于 XML 的 SOA 应用程序可用于构建 Web 服务。

SOA 出现于 1990 年代末，标志着应用开发与集成演进中的一个重要阶段。在 SOA 出现之前，将单体应用连接到另一个系统中的数据或功能，需要复杂的点对点集成，开发人员必须为每个新开发项目重新创建这种集成。通过 SOA 暴露这些功能，就不再需要每次都重新进行深度集成。

SOA 提供四种不同的服务类型：

1. 功能服务（即业务服务），对业务应用至关重要。
2. 企业服务，用于实现各类功能。
3. 应用程序服务，用于开发和部署应用程序。
4. 基础设施服务，对后台流程（如安全性和身份验证）起关键作用。

每个服务由三个组件组成：

1. 接口，定义服务提供者如何执行来自服务使用者的请求。
2. 契约，定义服务提供者和服务使用者应如何交互。
3. 实现，即服务代码

SOA 服务可以组合起来，创建更高级别的服务和应用程序。

与 SOA 类似，微服务架构由松散耦合、可重用且专门化的组件组成，这些组件通常能够独立运行。微服务还具有高度内聚性，也称为边界上下文。边界上下文指的是组件与其数据之间作为独立实体或单元的关系，依赖性较少。与在整个企业范围内采用不同，微服务通常通过应用程序接口 (API) 进行通信，用于构建执行特定业务功能的独立应用程序。这种方法使微服务更具敏捷性、可扩展性和弹性，尤其适用于业务的特定领域。通常，开发微服务的首选编程语言是 Java。也可以使用其他编程语言，如 Golang 和 Python。

微服务是一种真正的云原生架构方法，通常运行在容器中，使其在创建独立服务时更具可扩展性和可移植性。团队可以使用微服务更轻松地更新代码，为不同组件使用不同技术栈，并独立扩展各个组件。这种方法减少了因单个功能负载过大而必须扩展整个应用所带来的浪费和成本。由于微服务的独立性，它们生成的服务比其他替代方案更具容错性。

观看以下视频，了解更多有关微服务架构的信息：

这两种方法之间的主要区别在于范围。简而言之，面向服务的架构 (SOA) 适用于企业范围，而微服务架构适用于应用程序范围。

如果忽略这种差异，两种方法的许多核心原则就会变得不兼容。如果您接受范围差异，您可能很快就会意识到两者可能相互补充，而不是竞争。

以下是一些体现这种差异的使用场景：

在面向服务的架构 (SOA) 中，整合的可重用性是主要目标，在企业层面，努力实现一定程度的重用性至关重要。SOA 架构中的可重用性和组件共享提高了可扩展性和效率。

在微服务架构中，如果创建的微服务组件在应用程序运行时被多次重用，会产生依赖关系，从而降低敏捷性和弹性。微服务组件通常倾向于通过复制代码并接受数据重复的方式来重复使用代码，以帮助提高解耦性。

SOA 中的可重用服务可通过主要使用同步协议的方式在企业范围内使用，例如 RESTful APIs。

然而，在微服务应用中，同步调用会引入实时依赖，从而降低系统弹性。这些依赖还可能导致延迟，从而影响性能。在微服务应用中，更倾向于基于异步通信的交互模式，例如事件溯源，会使用发布/订阅模型，使微服务组件能够保持对其他组件中数据变化的实时更新。

在 SOA 中提供服务的一个明确目标是让所有应用程序直接在其主源同步获取和更改数据，这减少了维护复杂数据同步模式的需要。

在微服务应用中，理想情况下，每个微服务都应能本地访问其所需的所有数据，以确保其独立性，不依赖于其他微服务，甚至不依赖于其他应用，即使这意味着在其他系统中存在部分数据重复。当然，这种数据重复会增加复杂性，因此必须权衡其带来的敏捷性和性能收益，但这被视为微服务设计的现实。

• 通信：在微服务架构中，每个服务独立开发，并拥有自己的通信协议。而在 SOA 中，每个服务必须共享一种称为企业服务总线 (ESB) 的通用通信机制。SOA 通过 ESB 管理和协调所提供的服务。然而，ESB 可能成为整个企业的单点故障，如果某个服务变慢，整个系统都会受到影响。
• 互操作性：为了简化操作，微服务使用轻量级消息协议，如 HTTP/REST（表示性状态传输）和 JMS（Java 消息服务）。而 SOA 更加开放，支持异构消息协议，如 SOAP（简单对象访问协议）、AMQP（高级消息队列协议）和 MSMQ（Microsoft 消息队列）。
• 服务粒度：微服务架构由高度专门化的服务组成，每个服务都旨在将某一功能做到极致。而 SOA 组成的服务则范围更广，可以是小型的专门服务，也可以是覆盖整个企业的服务。
• 速度：通过利用共享通用架构的优势，SOA 简化了开发和故障排除。然而，这也使得 SOA 的运行速度往往比微服务架构慢，因为微服务通过减少共享、增加重复来优化性能。
• 治理：SOA 的特性涉及共享资源，使得在所有服务中实施统一的数据治理标准成为可能。而微服务的独立性则无法实现一致的数据治理。这为每个服务提供了更大的灵活性，同时也有助于推动整个组织的更高效协作。
• 存储：SOA 与微服务在存储资源分配方面也存在差异。SOA 架构通常包含一个单一的数据存储层，由给定应用中的所有服务共享，而微服务则会为需要的每个服务分配独立的服务器或数据库进行数据存储。

对于某些组织而言，SOA 架构是替代单体应用的一个过渡方案，提供了更灵活和敏捷的环境。SOA 服务可以在大型环境中开发和使用，但它们无法满足希望在自身职责范围内处理具体业务流程的企业的特定需求。组织可以通过 DevOps 帮助实现从 SOA 架构向微服务的过渡，以满足这些具体需求。

各种架构风格各有优劣，那么如何判断哪种最适合您的需求呢？一般来说，这取决于应用环境有多大以及多样化程度如何。

SOA 和微服务都可以利用自动化加快业务流程。规模较大、环境较为多样化的系统往往倾向于采用面向服务架构 (SOA)，通过企业服务总线 (ESB) 支持异构应用和消息协议之间的集成。而较小的环境，包括 Web 和移动应用，则不需要如此强大的通信层，使用微服务架构更易于开发。

有人可能会指出，SOA 与微服务的争论要复杂得多，确实如此。涉及的内容远不止这些。想要获得更详细的技术解释，可以查阅 SOA 和微服务的 Learn Hub 文章，这些文章提供了大量深入的信息。然而，从业务角度来看，范围是关键的区别。

• 什么是微服务？
• 什么是 SOA（面向服务架构）？
• 敏捷与瀑布式开发

想了解更多关于如何构建敏捷应用的信息，请下载免费的 Agile Applications Architecture ebook。