分布式微服务架构设计原理_读书笔记_2

1.3.4微服务的分解和组合模式

分解

微服务架构的需求分析和架构设计过程中，通常是用领域的动词和名词来划分微服务的，

例如：电商后台系统可以分解成订单，商品，商品目录，库存，购物车，交易，支付，发票，物流等子系统，每个名词和动词都可以使一个微服务，将这几个微服务组合在一起，就实现了电商平台用户购买商品的整个业务流。

组合

1. 服务代理模式

   • 最简单的服务组合模式，代理可以对后端服务的输出进行加工，也可以直接把后端服务的返回结果返回给使用端。

   • 具体：1新老系统双写0.2迁移双写前的历史遗留数据0.3将读请求切换到新系统0.4下调双写逻辑，只写新系统。。。

2. 服务聚合模式

   • 最常用的服务组合模式，根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合，加工和转换，最后以一定的形式返回给使用方。

   • 每个被依赖的微服务都有自己的缓存和数据库，聚合服务本身可以有自己的数据存储，包括缓存和数据库等，也可以是简单的聚合，不需要持久化任何数据。

   DRY[Don't Repeat Yourself 一次且仅一次]原则的设计理念,设计或者构造应用时，最大限度地重用现有的实现。假如一快业务逻辑由三个独立的逻辑块组成，每个独立的逻辑块可能有多个使用方，则DRY原则推荐将三个独立逻辑块封装成三个独立运行的微服务，然后使用本节服务聚合模式开发集合服务，将三个独立逻辑块聚合在一起提供给上层组合服务。这样的好处：

   1. 三个独立子服务可以各自独立开发、敏捷变更和部署。

   2. 聚合服务封装下层的业务处理服务，由三个独立子服务完成数据持久化等工作，项目结构清晰明了。

   3. 三个独立的自服务对于其他使用方仍然可以重用。

   前端应用是后端各个微服务的一个最大的聚合服务，前端应用通过调用商品和商品目录显示商品列表，提供给用户选择商品的功能，用户选择商品后增加商品到购物车，在用户从购物车结算时，调用交易系统完成交易和支付等。聚合服务也可以是纯后台服务

   • 电商前台

     • 商品服务：显示商品

     • 购物车服务：选择商品

     • 交易服务：结算

       • 库存服务：锁定库存或扣减库存

       • 支付服务：去支付

       • 发票服务：开发票

   3.服务串联模式

   类似于一个工作流

   通常使用同步的RESTful风格的远程调用实现，在串联服务没有完成并返回前，所有服务都会阻塞和等待，一个请求会占用一个线程来处理，因此不建议服务层级太多，如果可以用聚合模式代替则有限用聚合模式。

   相对聚合模式，串联模式有一个优点：串联链路上再增加一个节点时，只要不是在串联服务的正后面增加，那么串联服务是无感知的。

   上面的电商案例：UI前端应用调用交易，交易调用商品库存系统锁定库存和扣减库存，使用的就是服务串联模式。

   4.服务分支模式

   服务代理模式，服务聚合模式和服务串联模式相结合的产物。

   分支服务可以拥有自己的数据库存储，调用多个后端服务或服务串联链，然后将结果进行组合处理再返回给客户端。粉红字服务也可以使用代理模式，简单地调用后端的某个服务或者服务链，然后将返回的数据直接返回给使用方。

   实际业务平台建设中，由于业务复发性，抽象的微服务可能有多层的依赖关系，经常呈现树状的分支结构。

   以电商平台的支付服务为例

   • 支付服务

     • 支付渠道一

       • 渠道网关

     • 支付渠道二

       • 渠道网关

     • 账户支付

       • 账户服务

   支付服务对接两个外部支付网关，都要经过各自的支付渠道网关，同时支持账户余额支付，这个支付服务其实就是分支模式

   假如一个基础服务在服务分支模式的多层次中对基础服务都有依赖，当基础服务的一台机器宕机时，假设基础服务有8台机器，受影响的流量并不是1/8。原因是调用链上有多层次重复调用了基础服务，所以受影响的流量有累加效果。

   分支模式放大了服务的依赖关系，因此在现实的微服务设计中尽量保持服务调用级别的简单，使用服务组合和服务代理模式时，不要使用服务串联模式和服务分支模式，以保持服务依赖关系的清晰明了，减少了日后维护的工作量。

   5.服务异步消息模式

   前面的所有组合模式都使用同步的基于REST风格的同步调用来实现，同步调用模式在调用的过程中会阻塞线程，严重情况下会撑满服务的线程池，出现雪崩效应。因此通常会梳理核心系统的最小化服务集合，这些核心的系统服务使用同步调用，而其他核心链路以外的服务可以使用异步消息队列进行异步化。

   典型案例：

   • 电商平台

     • 购物车

     • 交易服务---->通过消息队列将异步消息传递给---->物流服务

   6.服务共享数据模式

   服务共享数据模式其实是反模式，之前提出去数据共享模式，去掉了数据共享，仅仅通过服务间良好定义的接口进行交互和通信，使得每个服务都是自治的，服务本身和服务的团队包含全角色栈的技术和运营，效率最大化，但是某些场景仍然需要共享模式。

   1）单元化架构

   平台对性能有高要求，采用微服务化将服务进行拆分，通过网络服务进行通信，尽管网络通信的带宽很宽，但是还有性能损耗，这时可以让不同微服务共享一些资源（缓存，数据库等），甚至可以将缓存和数据库在屋里拓扑上与微服务部署在一个物理机中，最大限度减少网络通信带来的性能损耗。这种方法称为 “单元化架构”。

   • 负载均衡（分片策略）

     • 单元一：服务一和服务二共享缓存，服务二和服务三共享数据库

     • 单元二：同单元一

     • ......

     • 单元N：同单元一

   2）遗留的整体服务

   对遗留传统单体服务在重构微服务的过程中，发现单体服务依赖的数据库表耦合在一起，对其拆分需要进行反规范化处理，可能造成数据一致性问题，在没有完全理解和把握时，选择保持现状，让不同微服务暂时共享数据存储。

   除了上面两个场景，其他任何场景都不能使用服务数据共享模式。