目录
- 一、SOA定义
- 二、微服务
- 微服务优势
- 微服务与SOA对比
- 微服务架构模式方案
- 微服务设计约束
- 三、SOA参考架构
- 四、SOA设计的标准要求
- 五、SOA设计原则
- 六、SOA设计模式
- 七、SOA实施
一、SOA定义
面向服务的体系结构 (Service-Oriented Architecture,SOA), 从应用和原理的角度看，目前有两种业界公认的标准定义。
从应用的角度定义，可以认为：
SOA是一种应用框架，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。
SOA使用户可以构建、部署和整合这些服务，且无需依赖应用程序及其运行平台，从而提高业务流程的灵活性。
这种业务灵活性可使企业加快发展速度，降低总体拥有成本，改善对及时、准确信息的访问。
SOA有助于实现更多的资产重用、更轻松的管理和更快的开发与部署。
从软件的基本原理定义，可以认为：
SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
作为软件架构师，后一种从软件原理方面的定义，对日常工作更具指导性
二、微服务
SOA架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。
微服务优势
助记：解独异容展
微服务与SOA对比
微服务架构模式方案
微服务设计约束
| 约束 | 助记 | 详细 |
|---|---|---|
| 微服务 个体约束 | 每个微服务都是独立的，修改一个微服务不能影响另一个微服务 | 服务拆分、单一职责、高内聚低耦合、独立性 |
| 微服务间的 横向关系 | 通过第三方服务注册中心来满足服务的可发现性 | 服务注册发现、客户端负载均衡、限流熔断等 |
| 微服务与数据层之间的 纵向约束 | 数据是微服务的“私产”，访问时需要通过微服务 | 零共享架构 |
| 全局视角下的微服务 分布式约束 | 高效运维整个系统 | 自动化CI/CD、可观测、蓝绿/金丝雀发布等 |
三、SOA参考架构
从服务为中心的视角来看，企业集成的架构可划分为6大类。
- (5) 开发服务 (Development Service): 贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试和维护等全面的工具支持。
- (4) 业务创新和优化服务 (Business Innovation and Optimization Service): 用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
- (2) 控制服务 (Control Service): 包 括 实 现 人 (People)、 流 程 (Process) 和 信 息 (Information) 集成的服务，以及执行这些集成逻辑的能力。
- (3) 连接服务 (Connectivity Service): 通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。
- (1) 业务逻辑服务 (Business Logic Service): 包括用于实现业务逻辑的服务和执行业务逻辑的能力，其中包括业务应用服务 (Business Application Service)、 业 务 伙 伴 服 务 (Partner Service) 以及应用和信息资产 (Application and Information asset)。
- (6) IT服务管理 (IT Service Management): 支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。
四、SOA设计的标准要求
- 文档标准化
- 通信协议标准化
- 应用程序统一登记与集成
- 服务质量QoS（可靠性、安全性、策略、控制、管理）
五、SOA设计原则
(1) 无状态。 以避免服务请求者依赖于服务提供者的状态。
(2) 单一实例。 避免功能冗余。
(3) 明确定义的接口。 服务的接口由WSDL 定义，用于指明服务的公共接口与其内部专用实现之间的界线。 WS-Policy用于描述服务规约， XML模式 (Schema) 用于定义所交换的消息格式(即服务的公共数据)。使用者依赖服务规约调用服务，所以服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
(4) 自包含和模块化。 服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
(5) 粗粒度。 服务数量不应该太大，依靠消息交互而不是远程过程调用 (RPC), 通常消息量比较大，但是服务之间的交互频度较低。
(6) 服务之间的松耦合性。 服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
(7) 重用能力。 服务应该是可以重用的。
(8) 互操作性、兼容和策略声明。 为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，例如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。 WS-Policy 用于定义可配置的互操作语义，来描述特定服务的期望、控制其行为。在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。
六、SOA设计模式
- 服务注册表模式（服务注册、服务位置、服务绑定）
- 企业服务总线模式
- (1) 提供位置透明性的消息路由和寻址服务。
- (2) 提供服务注册和命名的管理功能。
- (3) 支持多种消息传递范型(如请求/响应、发布/订阅等)。
- (4) 支持多种可以广泛使用的传输协议。
- (5) 支持多种数据格式及其相互转换。
- (6) 提供日志和监控功能。
- 微服务架构模式（聚合器、链式、数据共享、异步消息传递）
七、SOA实施
选择SOA解决方案
- 1.尽量选择能进行全局规划的方案
- 2.选择时充分考虑企业自身的需求
- 3.从平台、实施等技术方面进行考察
业务流程分析
- 建立服务模型 - 自顶向下分解法、业务目标分析法、自底向上分析法
- 建立业务流程 - 实体（实体、过程、事件）、服务接口、业务流程
