微服务实践：服务设计
微服务实践：服务设计
服务划分
划分的原则
- 单一职责原则：微服务通常功能单一，只负责处理一件事。服务需呈现“高内聚，低耦合”原则
- 服务依赖原则：避免服务间的循环依赖，避免核心服务依赖非核心服务。如电商平台，核心业务是订单相关，非核心业务是推荐等。
- 服务自治原则：按服务组织的团队具有更小的沟通成本，因此从服务交付的角度考虑，服务的划分也应考虑如何让团队能够参与服务构建的整个生命周期，包括需求、设计、实现、验证、发布、运维甚至运营。
说明：代码行数并不能作为直接划分依据！
服务划分策略
服务实现
通常对于单个服务而言，其内部结构如下几个部分：
资源定义
服务间的通信
微服务的通信方式分为基于请求/响应的同步通信和基于消息（事件）的异步通信两类。
同步通信机制
微服务常见的同步通信机制有远程过程调用（RPC）和REST两种。
远程过程调用
异步通信机制
服务设计模式
链式模式
当某业务功能按照数据的流动，拆分成多个服务，并且服务之间形成链式的请求/响应关系的模式时，就称其为链式模式。
在链式模式中，消费者端的请求到达网关，网关向微服务A发起调用，微服务A再向B发起调用，B处理后又会将请求发给C，然后再逆向的获取响应，将结果最终返回给消费者端。
链式模式只能串行调用，无法并行处理，且调用整体成功率等于链条中每次调用成功率之乘积。
聚合器模式
当某服务需要调用其他多个服务，进行业务功能的组装时，便形成了聚合器模式。
比如服务A是订单服务，那么他需要从服务B（商品目录服务）中检查库存，然后调用服务C（计价服务）计算总价，最后调用服务D（银行扣款服务）进行交易结算。
但是聚合模式难以保证数据一致性，比如下单过程有多个环节，属于分布式事务的内容。
基于事件的异步模式
上述两种服务大多采用同步机制，因此会造成消费者端的阻塞。采用基于事件驱动的方式，可以通过异步的机制实现服务聚合。
消息是连接服务A和B、C之间的媒介。存在一个消息队列，服务B和服务C对消息队列中的A
的事件进行订阅。当服务A状态发生变化时，他发布事件到消息队列中。当B和C收到事件时，分别更新各自的状态，同时可能发布新的事件，触发下一步操作。这就是典型的基于消息队列，进行异步时间处理的机制。
服务间协作的关键点是消息，因此要保证消息发布与服务的状态保持一致。
