服务范围和粒度
- 面向服务的架构 (SOA) 旨在解决更广泛的企业范围需求，促进不同业务部门在通用数据共享平台上的高效协作。SOA 中的服务通常代表更广泛的业务能力，例如，电子商务系统中的库存管理服务.
- 微服务架构 专注于更精细的范围。它将应用程序分解为更小的、独立的服务，每个服务执行特定的功能. 例如，库存管理在微服务架构中可能会进一步分解为可用性检查器、发货和会计等微服务。微服务提倡细粒度的服务，甚至是每个操作或方法都作为独立的服务开发，足够小，无法进一步拆分.
实施方法
- SOA 的实施涉及集成不同类型的服务，通常使用企业服务总线 (ESB) 来连接各种服务. ESB 充当连接不同服务节点的管道，处理消息转换、协议解释和路由，以实现服务之间的互操作性. SOA 的服务通常是粗粒度的，内部实现可能更广泛，只要接口约定规范化即可.
- 微服务架构 是 SOA 的更精细和独立的实现。每个微服务都是一个独立的应用程序，旨在提供非常具体的功能，而无需像 SOA 服务那样共享资源. 微服务架构强调组件化和服务化，将单个业务系统分解为可以独立开发、设计、运行和维护的小型应用程序. 微服务更多是为了可扩展性、负载均衡和提高吞吐量而分解应用程序.
通信方式
- SOA 架构 使用集中式 企业服务总线 (ESB) 作为服务间通信的关键组件. ESB 连接具有多种消息传递协议的服务，例如 SOAP、高级消息队列协议 (AMQP) 和微软消息队列 (MSMQ). 如果 ESB 发生故障，所有 SOA 服务都会受到影响. SOA 倾向于使用重量级通信方式.
- 微服务架构 采用更轻量级的通信机制，例如 RESTful API、Java 消息服务 (JMS) 或发布-订阅 (pub/sub) 事件流. 这些方法允许微服务直接交换数据，而无需通过集中式渠道. 微服务通常使用 HTTP RESTful 协议或 TCP RPC 协议进行通信. 微服务甚至是去 ESB 和去中心化的.
数据存储
SOA 中的数据存储模型
- 集中式数据存储 (常见但非唯一)：SOA 确实 可以 并且经常涉及一个中心化的数据存储层，不同的服务在其中共享数据. 这种方法旨在实现企业范围内的数据一致性和避免数据冗余. 许多 SOA 实现的架构都围绕着连接到共享数据库的企业服务总线 (ESB) 构建.
- 分散式数据存储 (也是可能的)：重要的是要认识到 SOA 不一定 要求所有服务都共享一个数据库。SOA 的原则重点在于通过服务公开业务能力，并促进不同系统之间的互操作性. 虽然集中式数据库与某些 SOA 实施的目标（例如数据集成和重用）相符，但 SOA 架构原则上 可以 容纳服务拥有自己独立数据库的场景.
- 服务封装和数据所有权： SOA 的一个关键原则是服务封装，这意味着每个服务应该封装特定的业务功能，并且服务内部的实施细节（包括数据存储）应该对服务使用者隐藏. 从理论上讲，这种封装允许服务拥有自己的数据存储，而不会违反 SOA 的基本原则. 然而，在实践中，为了实现企业范围的数据集成和互操作性，集中式数据存储在 SOA 中变得很普遍.
- ESB 和数据访问模式：即使在 SOA 中使用多个数据库，企业服务总线 (ESB) 仍然可以发挥作用，以协调跨不同数据源的服务之间的交互. ESB 可以帮助处理数据转换和路由，即使数据分布在不同的数据库中. 在这种情况下，服务仍然可以通过 ESB 相互交互，但它们的数据可能是隔离的.
微服务中的数据存储模型
- 数据库即服务 (强制)：与 SOA 不同，微服务架构 强烈提倡 每个微服务拥有自己的独立数据库. 这种模式被称为“每个服务一个数据库”. 数据独立性是微服务架构的关键原则，旨在实现松耦合、独立部署和技术多样性.
- 数据去中心化和自治：在微服务中，每个服务负责管理和持久化其自身的数据. 服务不应直接访问其他微服务的数据库. 如果一个微服务需要另一个微服务的数据，它应该通过明确定义的 API 请求数据. 这种方法最大限度地减少了服务之间的依赖性，并允许团队独立选择最适合其服务的数据库技术.
- 避免共享数据库：微服务架构避免共享数据库，因为它可能导致紧耦合、降低自治性并阻碍独立部署. 共享数据库会成为瓶颈和单点故障，这与微服务的可扩展性和弹性目标背道而驰.
SOA 和微服务之间数据存储的关键区别
| 特征 | SOA | 微服务 |
|---|---|---|
| 数据存储模式 | 集中式数据存储（常见）；分散式数据存储（可能） | 分散式数据存储（每个服务一个数据库 - 强制） |
| 数据共享 | 集中式数据共享（通过共享数据库或 ESB） | 数据自治；通过 API 共享数据 |
| 耦合 | 服务之间可能存在数据耦合 | 服务之间数据松耦合 |
| 数据库选择 | 通常同构（倾向于企业级数据库） | 可以是异构的（每个服务选择最佳数据库） |
| 治理 | 集中式数据治理（如果使用共享数据库） | 分散式数据治理 |
总之，虽然 SOA 可以 容纳多个独立数据库，但它通常与集中式数据存储相关联，以促进企业范围的数据集成和互操作性。另一方面，微服务架构 始终 提倡每个服务拥有独立的数据库，以实现数据自治、松耦合和独立部署. 微服务对数据独立性的强调是其与 SOA 的关键区别之一. 微服务被视为 SOA 原则在更精细的粒度和更强调独立性方向上的演进.
部署方式
- SOA 服务 的部署可能具有挑战性，因为它们在一定程度上是耦合的. 对 SOA 应用程序的修改可能需要重建和重新部署整个应用程序. 传统的 SOA 应用程序可能无法充分利用容器化技术. SOA 倾向于整体部署.
- 微服务 更易于部署，因为它们是为在云环境中扩展而设计的. 每个微服务都可以独立部署，通常使用容器化技术（如 Docker），并可以通过自动化方式独立部署. 微服务可以独立于其他服务进行部署，从而实现更快的交付.
中心化与去中心化
- SOA 倾向于 中心化 架构，ESB 作为中心枢纽管理服务通信、消息转换和路由. SOA 方法侧重于集中管理.
- 微服务 提倡 去中心化，服务彼此直接通信，无需中央 ESB. API 网关通常用于微服务架构中，以提供统一的入口点，但核心服务交互是去中心化的. 微服务方法侧重于分散管理.
复杂性与敏捷性
- SOA 更适合大型企业中复杂的业务流程编排和应用程序集成. 虽然 SOA 旨在提高互操作性和重用性，但其集中式特性和重量级实现有时会导致复杂性. SOA 的交付速度通常较慢.
- 微服务 旨在提高敏捷性和开发效率. 微服务框架通常更轻量级，可以更快地构建和部署应用程序. 微服务架构支持快速交付和技术多样性，因为团队可以独立选择技术.
组件大小和耦合性
- SOA 中的组件通常较大，代表大块的业务逻辑. SOA 系统中的服务通常是松散耦合的，但服务之间可能仍然存在依赖关系，尤其是在共享 ESB 的情况下.
- 微服务 提倡更小的组件，每个组件专注于特定的任务或小块业务逻辑. 微服务架构总是松散耦合的，旨在最大限度地减少服务之间的依赖性. 微服务通过服务实现组件化，允许开发者独立工作，而无需协调其他服务的部署.
应用场景
- SOA 更适合庞大、复杂、异构的企业级系统，这些系统可能已经发展多年，并且集成了各种不同的技术和系统. SOA 对于需要集成遗留系统和实现跨多个部门的企业级互操作性的场景非常有用.
- 微服务 更适合快速、轻量级、基于 Web 的互联网系统，这些系统需要快速迭代、快速交付和可扩展性. 微服务非常适合需要快速执行新功能和快速扩展的场景.
总而言之，SOA 是一种更成熟的架构方法，强调企业级服务重用和互操作性，通常采用集中式 ESB 进行服务集成。微服务 是 SOA 的演进，它强调更细粒度的服务、去中心化、轻量级通信和敏捷开发，更适合现代云原生应用和快速变化的业务需求. 微服务可以被认为是 SOA 原则在更精细的粒度和更强调独立性方向上的 refined 和 evolution.
