微服务的 交互 分解组合 容错 模式

一 微服务之间的通用设计模式：

1.读者容错模式

消费者对提供者返回的内容进行兼容，消费者处理提供者返回的消息的过程中，对消息进行过滤，只提取自己需要的聂荣，对多余或未知的内容丢弃，而不是强行抛出异常或错误信息。

2.契约模式

服务契约分为：提供者契约、消费者契约、消费者驱动契约

提供者契约：最常用的契约模式，以提供者为中心，提供者提供什么功能和消息格式，消费者无条件的遵守这些约定，不论消费者实际需要多少功能。

消费者契约：对某个消费者的需求进行精确描述，消费者确定需要提供者提供哪部分功能或者数据。

消费者驱动契约：服务提供者向其所有消费者承诺遵守的约束，有消费协商确定需求的功能或者数据并告知提供者，提供者保证始终坚守约定的契约。

3.数据共享模式

在实践的过程中，有些方案的设计使用缓存或者数据库作为两个微服务的纽带，起一个微服务的结果存入缓存或者数据库，下一个微服务从缓存或数据库中读取数据继续处理。

这种模式用如下明显缺点：

1.使微服务之间的交互除了接口契约，还存在这数据存储的契约（存储类型，数据结构）。

2.上游的数据结构发生变化，可能导致下游的处理逻辑出现问题。

3.多个服务共享一个资源服务，对资源服务的运维难以划清职责和界限。

4.跨机房独立部署，需要考虑服务和资源的路由情况，跨机房独立部署很难实现进而难以实现服务的自治。

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

使用微服务架构划分服务和团队是微服务架构实施的第一步，良好的划分和拆分使系统达到松耦合和高内聚的效果，人后通过微服务的灵活组装可以满足上层的各种各样的业务处理需求。

微服务的设计中通常用领域的动词和名词来划分微服务。

1.服务代理模式

根据业务需求选择调用后端的某个服务，在返回给前端之前代理对后端服务输出进行加工，也可以直接吧后端服务的返回结果返回给前端。

2.服务聚合模式

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

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

3.服务串联模式

服务串联模式类似于一个工作流，上层的服务负责接收请求和响应使用方，接到请求和继续与下层服务交互，最后底层的结果向上逐级处理以后返回给使用方。

服务串联模式之间的调用通常使用同步的RESTful风格的远程调用实现，同步调用在串联服务没有完成并返回之前，所有服务都会阻塞和等待，一个请求会占用一个线程来处理，因此在这种模式下不建议服务的层级太多。

4.服务分支模式

服务分支模式是服务代理模式、服务聚合模式和服务串联模式相结合的产物。

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

5.服务异步消息模式

同步调用模式在调用过程中会阻塞线程，如果服务提供方迟迟没有返回，则消费方会一直阻塞，在严重情况下会撑满服务的线程池，出现雪崩效应。因此在构建服务架构系统的时候，梳理出核心系统的最小化服务集合，将这些核心的系统服务使用同步调用，和其它核心链路以外的服务可以使用异步消息队列进行异步化。

6.服务共享数据模式

服务共享数据模式其实是反模式。之前的去数据共享模式，由于去掉数据共享，所以服务之间通过定义的接口进行交互和通信。但在如下的特殊场景下仍然需要考虑数据共享模式。

1.单元化架构

一些平台由于对性能要求比较高，采用微服务将服务拆分，通过网络服务进行通信，尽管网络通信的带宽已经很宽，但还是会有性能方面的损耗，在这种情况下可以让不同的微服务共享一些资源，如：缓存、数据库等，甚至可以将这些服务部署到一台物理机中，最大限度地减少网络通信带来的性能损耗。

2.遗留的整体服务

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