服务拆分-分层模式
1 定义
分层架构（Layered Architecture），是一种将复杂系统划分为多个逻辑层的架构模式，这种模式在软件领域尤其是大型系统中广泛使用。
2 上下文和问题
复杂的系统需要其各个组成部分能够独立的开发和演进，因此系统开发人员需要一个清晰和完备的文档来描述分离的细节，从而使系统的组成部分可以独立的开发和维护。
3 解决方案
为了帮助各个团队对复杂系统的组成部分独立开发和维护，通常对复杂系统按照”多层蛋糕“的形式进行组织：
- 每层应具备特定的职责
- 每层只依赖其下层
- 上层使用下层定义的接口、服务，下层对上层一无所知
- 每层都对其上层隐藏其下层的细节
按照上面的原则划分后，每一层都由若干模块、组件或者微服务提供一组内聚的服务。上层通过接口使用下层提供的服务，上层只需要关注下层的接口，不关注下层模块、组件或微服务采用的具体技术、架构和实现方式，也不易受到下层变动的影响（接口变更例外）。从而实现层与层之间的松耦合，层与层之间的接口也更加容易管理。
分层架构.png
分层的架构很容易和开发团队的组织架构契合，从而达到各个团队独立开发维护系统不同组成部分的目的。
4 分层架构的优点
- 结构简单，易于理解，易于开发维护。
- 不同技能的开发人员分工协作负责不同的层，天然和公司的组织契合。
- 层与层松耦合，可独立测试发布。
5 分层的陷阱
过犹不及，分层不能过细，分层过细会带来性能损耗（没有减少一层解决不了的性能问题）和开发人员的职能定位冲突。对于小型系统，三层足够满足需要；对于复杂的大型系统，5-7层是一个比较合理的划分；如果系统划分超过10层，需要谨慎的选择。
微服务的架构风格越来越流行，在微服务场景下，系统划分应该在更大粒度上进行。如果对微服务系统进行较细粒度的划分，首先系统会由大量的微服务构成，每层中的微服务只聚焦”自己“的功能，而不是为最终客户提供价值。一条能够创造价值的价值流将会由每层的多个微服务构成，微服务之间的调用链变长，管理维护的工作量都急剧上升。这甚至会抵消使用微服务架构带来的好处，分层成了微服务的反模式。因此，在微服务场景下，分层需要更加谨慎，避免过长的调用链和重度依赖。
6 应用场景
大型软件系统
7 应用举例
Spring Framework Runtime也是按照分层的架构设计，上层依赖下层提供的服务。
Sping Framework runtime.png
