我现在把微服务架构所有的博客文章也发布到了 github 上，便于阅读(左边栏打开可以看到全部的标题)，还有历史修改追踪。
当然也希望大家能点个✨ 星 star 鼓励鼓励。
什么是 SOA 架构#
SOA（Service-Oriented Architecture） 架构是面向服务的架构，是一种将单体应用粗粒度的划分为服务的架构，其核心是将业务功能抽象为独立、可重用、松耦合的服务，也就是将业务功能通过 IT 技术封装为服务，并通过标准化的接口
进行发布、查找和调用，从而达到构建灵活的企业 IT 应用系统。
从应用技术开发层面来看，就是将应用程序的功能模块以独立、分布式、可复用的服务的形式组织起来，然后通过标准的接口和契约，使不同的服务能够跨平台、跨语言、跨系统集成，组成企业的各种应用系统。
集成通常是依赖企业服务总线（ESB）来实现服务间的通信和集成。
这里的 “服务”，业务层面指的是能执行完整的、独立的业务功能；程序层面指的是包含完整的代码和数据，是一个独立的功能单元。
SOA 的目标是提高企业 IT 资产的重用性，降低企业 IT 系统集成成本，提高业务灵活性和 IT 响应速度。
在 SOA 架构中，所有组件都是独立自主的，能为其它组件提供服务。
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 的集中化管理能力仍然是有效的选择。微服务更适用于需要快速迭代、高度可伸缩、容错性强的互联网应用和新业务系统。微服务也不是万能银弹，需要综合考虑使用。
作者：九卷 (公众号：九卷技术录)
出处：https://www.cnblogs.com/jiujuan/p/18927672
为您推荐
