【初出江湖】SOA 与微服务：哪个最适合您的业务?

面向服务的体系结构 (SOA)

面向服务的架构（SOA）是一种软件开发方法，它使用称为服务的软件组件来创建业务应用程序。SOA 倡导松散耦合的独立服务，彻底改变了软件设计。这意味着，服务彼此之间的依赖性最小，因此更易于开发、部署和维护。

服务也可以在许多应用中重复使用。这些服务通过标准化协议进行通信，从而实现不同系统之间的顺利集成和互操作性。SOA 非常适合大型的复杂企业。

例如，一个组织中的多个业务流程需要用户身份验证功能。您可以创建一项身份验证服务并在所有应用程序中重用，而不是为所有业务流程重写身份验证代码。同样，医疗机构中的几乎所有系统，例如患者管理系统和电子健康记录（EHR）系统，都需要登记患者。这些系统可以调用一项单一的公共服务来执行患者登记任务。

SOA 角色

面向服务的架构的构建模块是由 3 个角色组成的。

1. 服务供应商：服务供应商创建 Web 服务并将其提供给服务注册表。服务供应商对服务的使用条款负责。
2. 服务代理或服务注册表：服务代理或服务注册表负责向请求者提供有关服务的信息。代理可以是公共的或私有的。
3. 服务请求者或服务消费者：服务请求者在服务代理或服务注册表发现服务，然后连接服务供应商以接受服务。

那么它们是如何通信和协同工作的呢？

ESB（Enterprise Service Bus，企业服务总线）把企业中各个不同的服务连接在一起。就像计算机总线一样，把计算机的各个不同的设备连接在一起。

因为不同的服务是使用不同的技术实现的，各个独立的服务是异构的，如果没有统一的标准，则各个异构系统对外提供的接口是各式各样的。SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。ESB通过使用标准网络协议（如 SOAP、XML、JSON、MQ ）来开放服务以发送请求或访问数据，实现与各种系统间的协议转换、数据转换、透明的动态路由等功能，消除了开发人员必须从头开始进行集成的困扰。

采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖，减少各个服务间的依赖和互相影响，做到了松耦合。

如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。

SOA 的优势

SOA 的模块化和标准化协议使服务能够有效通信，从而提高可重用性、互操作性和可扩展性。这些关键优势可以转化为公司的切实优势：

• 可重用性：重复使用现有服务可以减少开发时间和降低开发成本，并提高一致性和质量。公司可以加快开发周期并提高整体效率。
• 互操作性：服务可以通信和交换数据，无论采用何种底层技术或编程语言。这促进了企业范围内的数据集成和协作。互操作性可以简化业务流程，帮助公司适应不断变化的技术。
• 可扩展性：SOA 的模块化设计允许根据不断变化的需求独立扩展服务。它可确保应用能够在不影响性能或稳定性的情况下应对流量激增或不断扩大的用户群。公司可以使其基础架构适应不断变化的需求，而无需投入大量资金重新编写或重新设计。

微服务架构

微服务体系结构采用更精细的方法。它将应用分解为较小的独立服务。每项服务都是独立的，侧重于特定的任务或功能。每项微服务还包含所有必要的代码和数据，无需依赖其他组件即可运行。微服务通过 HTTP 和 REST 等轻量级协议进行通信，从而提高敏捷性和弹性。

微服务体系结构最显著的优势是可实现顺利集成和可重用性。这使其成为快速发展的动态应用的理想选择。

微服务的优势

微服务的精细体系结构和轻量级通信协议可实现无缝集成和可重用性。这可以转化为公司的几项主要优势：

• 可扩展性：微服务是可扩展的。它们可以扩展或收缩以满足不断变化的需求。每项微服务负责特定的业务功能，并且可以独立于其他微服务进行扩展。Docker 和 Kubernetes 通过提供管理和编排微服务容器的工具和基础架构，在该可扩展性方面发挥至关重要的作用。
• 灵活性：微服务的技术独立性使开发人员能够为每项服务选择最佳技术。微服务的松散耦合（这表明它们不依赖特定的技术或编程语言）使开发人员可以在不中断整个应用的情况下试用新技术。通过微服务，可以更轻松地采用新技术，因为只有受影响的微服务需要更新。
• 故障隔离：微服务的松散耦合可限制故障的影响，防止故障级联到整个系统中。这是因为微服务是独立的单元，有自己的数据和代码。如果一项微服务失败，其他微服务可以继续正常运行。故障隔离有助于确保整个系统的稳定和可靠。

SOA 和微服务之间的区别

虽然 SOA 和微服务有一些共同的目标，但也有明显的区别。在比较 SOA 与微服务时，基本的体系结构风格可使这两种方法区分开来。SOA 采用自上而下的集中化方法，而微服务则更喜欢采用自下而上的去中心化模型。

特点	SOA 面向服务架构	微服务架构
体系结构风格	粗粒度、集中化	细粒度的分布式系统
服务粒度	规模较大、更全面的服务	规模较小、有侧重点的服务
独立性	服务是相互依存的	服务高度独立
沟通	同步，通常以消息为导向	异步，通常是 RESTful
数据存储	集中化数据管理	分布式（去中心化）数据管理
可扩展性	水平扩展	水平和垂直扩展
部署	通常涉及将整个应用作为一个单元进行部署	每项服务均独立部署和扩展
耦合	由于资源共享和进行集中通信，服务呈现出一定程度的耦合	松散耦合，服务之间的依赖性最小

这个表格清晰地展示了两种架构在多个维度上的差异，有助于理解和选择适合特定场景的架构风格。

面向服务的体系架构所带来的服务概念已成为现代云计算和虚拟化的核心组成部分，比如中间件和微服务等项目。由于它们的相似性，人们经常将 SOA 和微服务架构相混淆。二者的主要区别是它们的范围：SOA 是一种企业级的架构方案，而微服务则是应用开发团队的一种实施策略。

此外，它们与各自组件进行通信的方式也有所不同：SOA 使用 ESB，而微服务则可以通过与语言无关的 API 彼此进行无状态通信。不仅如此，微服务中与语言无关的 API 还允许开发团队选择自己想用的工具。凡此种种，让微服务变得生存力更强，也更加灵活。

SOA 与微服务：常见问题

采用 SOA 和微服务面临哪些挑战？

选择 SOA 还是微服务会显著影响团队快速灵活地构建和修改软件的能力。

SOA 的较大代码块虽然可以提供更好的控制力，但也会阻碍灵活性。采用 SOA 时，重复使用基于不同技术构建的服务可能具有挑战性。这使得在服务之间连接和共享数据变得很棘手。开发人员必须掌握多种技术才能有效地使用 SOA。

微服务需要管理更多部分，这会增加复杂性。它们需要更标准化的开发策略，以便独立的服务顺畅地协同工作。实现这种程度的组织协调是一项艰巨的任务。

SOA 和微服务是否可以共存？

是的，公司可以在 SOA 上构建传统系统，并逐步将微服务用于新功能或特定组件。这种方法可以实现平稳过渡并利用这两种体系结构的优势。

每种体系结构如何影响部署和 DevOps 实践？

SOA 和微服务部署都受益于 Open DevOps 实践。但是，根据体系结构的不同，具体细节会有所不同。

SOA 通常涉及整体部署，即团队将整个应用作为一个单元进行部署。这种方法需要团队之间的谨慎协调。它可能既耗时又复杂，尤其是对于大型应用来说，更是如此。

DevOps 强调为了应对这些挑战，开发和运营团队之间的协作和自动化。这有助于提高部署频率和可靠性。通过自动执行测试、配置管理和基础设施调配，DevOps 可以帮助简化 SOA 部署并尽可能减少错误。

微服务架构支持更精细的部署。团队独立部署每项微服务。

DevOps 原则对于微服务部署也十分重要。通过持续集成和持续交付等 DevOps 实践，团队可以自动开展测试、部署和构建微服务的流程。这有助于快速频繁地发布。