服务层次结构
编程思想发展史
面向对象 → 面向组件 → 面向服务
- 抽象程度越来越高（粒度越来越大）
- 耦合程度越来越松
- 应用范围越来越大
从程序应用到企业业务 - 通信范围越来越大
从本机扩展到网络
SO 与 OO 的对比
| 对比角度 | SO | OO |
|---|---|---|
| 耦合程度 | 松耦合 | 紧耦合 |
| 预期范围 | 范围大，变化大 | 范围小，变化小 |
| 接口粒度 | 粗粒度接口 | 细粒度接口 |
| 状态 | 尽可能无状态 stateless |
将数据与逻辑绑定到带状态的对象中 stateful |
OO 支持组件化，但是允许类间继承
这样的好处是复用了一部分代码，坏处是代码之间耦合程度过高
在低抽象层次是好用的，高抽象层次就不好用了
个人感觉是因为高抽象本身已经屏蔽了足够多的差异，高抽象层次之间显现出的差异明显，通过类间继承实现复用带来耦合的副作用往往大于复用本身带来的好处
OO 基于预定类依赖关系，造成紧密耦合处理逻辑
按照个人理解，OO 的设计思想就是希望通过 对象 + 消息 的形式描述整套业务逻辑，从这个出发点就计划让处理逻辑本身要由对象来承担，而 SO 通过引入抽象层的方式将业务逻辑交由高层服务来承担，底层对象不再承担具体的业务逻辑，而是承担粒度更小的通用具体操作
SOA
按照个人理解，SOA 先指导我们将业务逻辑和应用逻辑（包含组件和遗存系统）分离，再通过引入服务来实现依赖倒转（楔形抽象）
服务层次结构应该怎么划分？
个人理解 SOA 的思路就是将业务逻辑和应用逻辑分离，再引入服务接口桥接，这种三层（如果应用逻辑再进一步划分成组件层和遗存系统则分为四层），这种大划分结构是不变的，所以最终问题是服务接口层应该怎么划分
层次结构
- 业务过程层
- 服务接口层
- 服务编排层（可选）
- 业务服务层
- 以任务为中心的业务服务层（面向过程）
- 以实体为中心的业务服务层（面向对象）
- 应用服务层
- 混合应用服务层（包含一部分业务逻辑）
- 工具（utility）应用服务层
- 应用层
具体问题具体分析，合适的划分方式才是最好的划分方式，下面给出引入服务抽象层要解决的问题，用于作为划分的考虑维度
- 1W3H
- What：待服务化的对象是什么？
- How：面向业务逻辑的服务化何以最优？
- How：面向遗存系统的服务化何以最优？
- How：如何部署服务以促进敏捷性？（即快速部署何以实现？）
应用服务层
功能
- 表达技术依赖的功能
- 提供可复用的数据相关（上下文相关）的方法
三层架构中的正统 Service 层
组成
- 公共服务：用于提供通用服务
- 包装服务：用于集成，用作服务适配器
特点
- 上下文相关
- 资源可识读
- 方案无关
- 普适可复用
- 实现应用服务间的点对点连接
- 接口粒度不一致
- 服务来源广
业务服务层
功能
仅涉及表示业务逻辑的服务
三层架构中的 Controller 层
划分
- 以业务为中心
- 以实体为中心
本质上对应两种不同的视角，个人认为可以理解为 面向过程 和 面向对象 在业务服务层的划分
服务编排层
功能
保证执行顺序，按照个人理解，服务编排层的一个 Entity 对应 一组 Task
编排服务层由一个或多个流程服务组成，这些流程服务根据流程定义中嵌入的业务规则和业务逻辑 组成（动词） 业务和应用程序服务
编排层将业务规则和服务执行序列从其他服务中抽象出来，提高了灵活性和可重用性
也就是说编排层承担了按规则排序的职责
引入抽象层的感受
之所以引入抽象层，是希望在不同的层次上有人专事专办，引入抽象层必然带来协调问题，但是好处是实现职责的分离
换句话说，引入抽象层之前先想明白自己希望将什么职责分离出来让新引入的抽象层来承担，否则没必要给自己找麻烦（结合个人 Python 实验一的经验教训）
服务不可知
个人对其定位：一种提高（保障）可复用的思维倾向
个人不是很喜欢服务不可知的说法，按照个人理解，更喜欢将其称为服务独立性，这种独立性服务于服务的复用需求，与越多的具体事项无关，就越易于复用，这种无关理解成不可知也未尝不可，服务不可知某种程度上也体现了服务自治（自己有意识地维持难得糊涂），但是相较于服务独立性的理解方式可能稍微拐了点弯
功能
与解决方案无关的服务层与多个业务流程和自动化解决方案相关联，并将其绑定在在一起
这些服务层促进重用，但也模糊了单个解决方案的架构边界（个人感觉是因为引入了绑定）
服务配置方案
本质上就是服务层次结构应该怎么划分的问题
- 服务接口层只分为一层（其实就是没划分）
- 混合应用服务层
- 服务接口层划分为两层
- 混合应用服务层
- 工具（utility）应用服务层
- 服务接口层划分为两层
- 以任务为中心的业务服务层
- 工具（utility）应用服务层
- 服务接口层划分为三层
- 以任务为中心的业务服务层
- 以实体为中心的业务服务层
- 工具应用服务层
- 服务接口层划分为三层
- 编排服务层
- 混合应用服务层
- 工具（utility）应用服务层
- 服务接口层划分为三层
- 编排服务层
- 以任务为中心的业务服务层
- 工具（utility）应用服务层
- 服务接口层划分为四层
- 编排服务层
- 以任务为中心的业务服务层
- 以实体为中心的业务服务层
- 工具（utility）应用服务层
面向服务原则
基于 Web Service 的简化 SOA
服务消费者、服务注册中心、服务提供者三角架构
SOA 中的逻辑组件
- Message = units of communication
- Operation = units of work
- Service = units of processing logic
- Processes = units of automation logic
自动化逻辑，但个人认为也可以理解为事件驱动
面向服务原则之间的关系
