我觉得说微服务的服务分层前，有必要说一下微服务的演进历史和微服务架构的一些常用设计模式
一、微服务演进历史
- MVC (Modle View Controller) 架构： 当业务规模很小时，将所有功能都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流；此时，用于分离前后台逻辑的 MVC 架构是关键。
- RPC (Remote Procedure Call)架构：当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分的 RPC 框架是关键。
- SOA (Service Oriented Architecture)架构：随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的 SOA 服务治理是关键。
- 微服务架构：随着敏捷开发、持续支付、DevOps 理论的发展和实践，以及基于 Docker 等轻量级容器 (LXC) 部署应用和服务的成熟，微服务架构开始流行，逐渐成为应用架构的未来演进方向。通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队敏捷交付，应用的交付周期将缩短，运营成本也将大幅下降。
二、常用的微服务架构设计模式
1、聚合器微服务设计模式
这是一种最常用也最简单的设计模式，如下图所示：
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的 Web 页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合 DRY 原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿 X 轴和 Z 轴独立扩展。
2、代理微服务设计模式
这是聚合器模式的一个变种，如下图所示：
在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应，如下图所示：
在这种情况下，服务 A 接收到请求后会与服务 B 进行通信，类似地，服务 B 会同服务 C 进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。
4、分支微服务设计模式
这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：
5、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL 数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，如下图所示：
在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。
6、异步消息传递微服务设计模式
虽然 REST 设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替 REST 请求 / 响应，如下图所示：
三、服务分层：
通过分层可梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的需求，提供服务可用性等。 费话不多说，针对一、二我想在系统架构上采用微服务系统架构的必然性已不用怀疑，经过几种微服务架构设计模式的对比，我想“聚合器微服务设计模式”正是我们目前所需要的，经过完善：整个系统的分层架构如下：
注：
CaaS(Communications-as-a-Service) 通讯即服务
PaaS（Platform as a Service）平台即服务
IaaS（Infrastructure as a Service）基础设施即服务
四、服务层级说明：
- 网关：请求的统一入口，可完成认证、鉴权、安全、流量管控、缓存、服务路由，协议转换、服务编排、熔断、灰度发布、监控报警等；
- 聚合服务：对基础服务层功能进行封装，减少前端接入接口请求量和复杂程度，聚合服务层与聚合服务层间不建议相互调用，以保证服务的低耦合和微服务特性；
- 基础服务：提供原子性核心业务数据处理能力，为调用方提供业务能力支持；
作者 轻易科技 知行研发部（php）
张铁龙
