微服务架构学习与思考(16)：SOA架构与微服务架构对比分析？它们之间区别是什么?

什么是 SOA 架构

SOA（Service-Oriented Architecture）架构是面向服务的架构，是一种将单体应用粗粒度的划分为服务的架构，其核心是将业务功能抽象为独立、可重用、松耦合的服务，也就是将业务功能通过 IT 技术封装为服务，并通过标准化的接口

进行发布、查找和调用，从而达到构建灵活的企业 IT 应用系统。

从应用技术开发层面来看，就是将应用程序的功能模块以独立、分布式、可复用的服务的形式组织起来，然后通过标准的接口和契约，使不同的服务能够跨平台、跨语言、跨系统集成，组成企业的各种应用系统。

集成通常是依赖企业服务总线（ESB）来实现服务间的通信和集成。

这里的 "服务"，业务层面指的是能执行完整的、独立的业务功能；程序层面指的是包含完整的代码和数据，是一个独立的功能单元。

SOA 的目标是提高企业 IT 资产的重用性，降低企业 IT 系统集成成本，提高业务灵活性和 IT 响应速度。

在 SOA 架构中，所有组件都是独立自主的，能为其它组件提供服务。

SOA 架构示意图：

SOA 架构发展三阶段

SOA（Service-Oriented Architecture，面向服务的架构）的概念最早由 Gartner 公司在 1996 年提出。

当时，软件技术和市场环境尚未成熟，SOA 并未被广泛实施和关注。

随着互联网的兴起和电子商务的快速发展，企业业务逐渐向互联网迁移，推动了对灵活、可复用服务的需求。

Web 服务的出现为 SOA 的实现提供了技术基础，尤其是基于 XML、SOAP、WSDL 等标准的 Web 服务技术，使得跨平台、跨语言的服务调用成为可能。

第一阶段：孕育阶段

SOA（Service-Oriented Architecture，面向服务的架构）的概念最早由 Gartner 公司在 1996 年提出，但是当时技术尚不成熟，未被广泛实施。

第二阶段：标准化阶段

随着 Web 服务标准的确立（如 SOAP、WSDL、UDDI），SOA 开始被企业关注和应用，形成较为成熟的技术规范体系。

第三阶段：成熟应用阶段

2005 年以后，SOA 推广加速，厂商联合制定中立标准（如 WS-Policy），并将关注点扩展到安全、业务流程和事务处理等领域。

单体架构出现的问题

对于小型项目或初创项目，单体架构具有开发速度快、修改简单、部署方便等优点。

但是，随着业务的快速发展，业务的复杂性也随着增加，单体架构的弊端也逐渐显现：

代码库膨胀

随着业务功能不断增加，单体代码库的代码量会随之增加，直到膨胀。这也会导致代码结构变得复杂、代码间的耦合也越来越紧密。

可用性受限

任何小的改动都可能影响到整个系统的可用性，一个小的代码修改可能导致整个系统出现问题，"牵一发而动全身"。

代码维护困难

第一新加入的开发人员需要花费大量的时间来理解整个系统，代码量大理解代码变的困难。

第二修改 bug 时，一个小的错误可能导致整个系统崩溃，影响系统可用性。

扩展性瓶颈

单体架构通常只能进行整体扩展，无法针对某个高负载的业务功能模块进行独立扩展，因为整个系统功能代码都是耦合在一起。

开发与部署效率低下

多个团队同时在一个大型代码库中开发，修改、增加代码，容易产生代码冲突。
每次功能更新都需要重新构建、测试和部署整个应用，发布周期长，效率低下。

为了解决单体架构在大型企业应用中日益突出的问题，面向服务的架构（SOA）就应运而生。

SOA 如何解决单体架构问题

SOA 通过将单体应用拆分成松耦合、自治的服务单元来解决上述问题：

服务封装与松耦合：SOA 将业务功能封装成独立的服务，服务之间通过标准接口和协议来通信，降低模块之间耦合度，便于维护和升级。
复用性：将公共业务功能封装为独立服务可以被多个业务模块、应用复用，业务应用通过服务编排灵活组合，支持企业业务快速发展。
业务敏捷性：业务功能变化时，只需要修改相关的服务，不影响系统其它部分。
独立部署与扩展：虽然 SOA 的服务粒度较粗，但是服务可以独立部署，也支持热点服务的扩展，提升系统的伸缩性。
技术异构：服务之间的通信遵循一些协议标准，比如 SOAP 、WSDL 等，能够实现技术异构系统之间的通信。
集中治理和标准化：通常通过企业服务总线（ESB）统一治理、安全、路由等，SOA 推动了服务标准的制定。

SOA 架构出现的问题

ESB 复杂度高：ESB 本身可能成为单点故障和性能瓶颈，其开发、部署和维护成本高。

部署与扩展困难：SOA 架构中的服务划分比较粗粒度，导致服务间的强依赖，部署和独立扩展较为困难，灵活性没有微服务高。

服务治理复杂：在大型 SOA 系统中，服务的版本管理、依赖管理、监控等治理工作面临挑战。

SOA 中的规范定义带来过度的复杂性，落地成本非常之高。SOAP 实现的 Web Service，在性能上和易用性上并不完美。

虽然定义了庞大的 Web Service 协议家族，通过标准协议实现了不同系统之间的通信，但是它们的学习、使用成本都非常高。

微服务架构

微服务架构可以看作是在 SOA 基础上的一种更细粒度的服务拆分和实现方式。它也是将单体应用拆分为多个更小的、自治的服务，每个服务围绕独立的业务功能构建，独立部署和运行，

服务间通过轻量级通信协议（如 HTTP 、gRPC ）进行通信。

它去掉了厚重繁琐的 ESB ，没有采用 SOAP 、WSDL 等复杂的标准和协议。

随着技术发展，与微服务架构配套的技术发展也突飞猛进，出现了链路追踪、API Gateway、服务注册和发现、配置中心、CICD、Docker 容器等等技术，

为微服务架构的快速发展奠定了基础。

SOA 架构与微服务架构的区别

架构概述对比

SOA 面向服务的架构：SOA 是将应用程序拆分为粗粒度、可复用、可独立部署的服务，然后通过接口、协议规范来实现跨平台、多语言、多系统集成的架构，通常依赖企业服务总线（ESB）来实现服务间的通信与集成。

微服务架构（Microservices Architecture） ：微服务架构是在 SOA 基础上的一种更细粒度的服务拆分和实现方式。它是将应用拆分为多个更小、自治的服务，每个服务围绕独立的业务能力构建，独立部署、独立运行、独立小团队负责。

服务之间通信协议使用轻量级的协议（如 HTTP、gRPC 等）进行通信。

服务拆分粒度

SOA 服务粒度较粗：SOA中的服务往往是较大的业务模块或功能单元。比如：电商系统中的 "商品管理系统" 即为一个 SOA 服务。
微服务服务粒度较细：微服务强调将业务拆分为更小的、具体的功能服务。比如："商品管理系统" 可能拆分为 "商品基本信息管理"、"供应商管理"、"库存管理"等多个微服务。

通信机制与技术实现

SOA 通信依赖 ESB：SOA 架构通常使用企业服务总线（ESB）作为服务间通信的核心，ESB 负责路由、消息转换、协议适配等功能，属于较为重量级的实现。在搭配 SOAP（XML 格式，消息体数据量大）等比较重的标准协议。ESB 易成为系统瓶颈。
微服务采用轻量级通信：微服务架构丢掉了 ESB，采用轻量级协议如 HTTP、RPC 进行服务间通信，强调去中心化，避免单点瓶颈。

服务自治与独立部署

SOA服务依赖共享资源：SOA 服务往往共享数据库或其他资源，服务间存在一定耦合，部署和扩展相对集中。
微服务完全自治：每个微服务拥有独立的数据库和运行环境，支持独立部署和扩展，能够根据业务需求灵活伸缩资源。

技术栈与运维实践

SOA 偏向传统技术：SOA 多采用传统的企业级中间件和技术，注重系统集成和兼容已有系统，运维相对复杂。
微服务利用现代技术：微服务架构广泛采用容器化（如Docker）、自动化部署、DevOps、链路追踪等现代技术，支持快速迭代和持续交付。

团队组织

SOA 架构：通常是按技术分层的团队（如UI团队、业务逻辑团队、数据库团队）。
微服务架构：通常是全功能团队（Cross-functional teams），围绕业务能力构建。

SOA和微服务架构对比总结

重要的区别

特性	SOA	微服务
粒度	粗粒度服务，通常代表一个完整的业务流程或领域	细粒度服务，每个服务只关注一个单一的业务能力
耦合度	相对松耦合，服务通过ESB进行协调，但ESB可能导致中心化依赖和单点故障	高度松耦合，服务独立运行，通过轻量级机制通信，去中心化
集成方式	依赖ESB进行服务的路由、转换和编排，实现集中式集成	采用API Gateway、服务注册与发现、轻量级通信（HTTP REST/消息队列）进行集成，去中心化集成
技术栈	倾向于统一的技术栈和协议（如XML、SOAP、WSDL），通常由集中团队管理	可技术异构性，每个服务可自由选择最适合的技术栈
数据存储	通常共享集中式数据库，或通过ESB协调多个数据库	每个微服务拥有独立的数据存储，强调数据自治
部署方式	倾向于单体部署或少量大型服务部署，独立部署能力有限	强调独立部署，每个服务可独立上线、回滚
团队组织	通常是按技术分层的团队（如UI团队、业务逻辑团队、数据库团队）	通常是全功能团队（Cross-functional teams），围绕业务能力构建
演进目标	提高企业级服务重用性，降低集成成本	提高系统可伸缩性、灵活性、高可用性，加速产品迭代

一些联系的点

尽管 SOA 和微服务存在显著差异，但它们并非完全独立的概念，而是有着密切的联系，甚至可以说微服务是 SOA 在特定背景下的一种演进和发展。

1、共同的服务化思想：两者都基于 "服务化" 的核心思想，即将业务功能抽象为独立的服务，并通过接口对外暴露。这是它们共同的基石。
2、松耦合目标：两者都追求服务间的松耦合，以提高系统的灵活性、维护性、伸缩性。
3、分布式系统范畴：两者都属于分布式系统架构的范畴，需要处理分布式环境下的通信、事务、数据一致性等问题。
4、演进关系：微服务可以看作是 SOA 在互联网时代、云计算环境下的一种 "进化"。SOA 在早期解决了企业级应用集成的痛点，但随着业务的快速变化和复杂性增加，其中心化的 ESB 和粗粒度服务逐渐暴露出部署、扩展和运维上的瓶颈。微服务则通过更细粒度的服务划分、去中心化的治理和独立部署的特性，解决了这些痛点，更好地适应了敏捷开发和DevOps的实践。
5、并非完全替代关系：微服务并非完全取代 SOA。在某些传统企业、业务流程相对稳定、集成复杂度较高的场景下，SOA 仍然有其价值。例如，一些遗留系统的集成，ESB 的集中化管理能力仍然是有效的选择。微服务更适用于需要快速迭代、高度可伸缩、容错性强的互联网应用和新业务系统。微服务也不是万能银弹，需要综合考虑使用。

我现在把微服务架构相关的博客文章也发布到了 github 上，便于阅读(左边栏打开可以看到全部的标题)，还有历史修改追踪。

当然也希望大家能点个✨ 星 star 鼓励鼓励。