图灵学院 java架构师学习路线
微服务的交互模式
本节介绍微服务之间交互的通用设计模式，这些设计模式对微服务之间的交互定义契约，服务的生产者和调用者都需要遵守这些契约，才能保证微服务不出问题。
1. 读者容错模式
读者容错模式（Tolerant Reader）指微服务化中服务提供者和消费者之间如何对接口的改变进行容错。从字面上来讲，消费者需要对提供者提供的功能进行兼容性设计，尤其对服务提供者返回的内容进行兼容，或者解决在服务提供者改变接口或者数据的格式的情况下，如何让服务消费者正常运行。
任何一个产品在设计时都无法预见将来可能增加的所有需求，服务的开发者通常通过迭代及时地增加新功能，或者让服务提供的API自然地演进。不过，服务提供者对外提供的接口的数据格式的改变、增加和删除，都会导致服务的消费者不能正常工作。
因此，在服务消费者处理服务提供者返回的消息的过程中，需要对服务返回的消息进行过滤，只提取自己需要的内容，对多余或者未知的内容采取抛弃的策略，而不是硬生生地抛错处理。
在实现过程中不推荐使用严格的校验策略，而是推荐使用宽松的校验策略，即使服务消费者拿到的消息报文发生了改变，程序也只需尽最大努力提取需要的数据，同时忽略不可识别的数据。只有在服务消费者完全不能识别接收到的消息，或者无法通过识别的信息继续处理流程时，才能抛出异常。
服务的消费者的容错模式忽略了新的消息项、可选的消息项、未知的数据值及服务消费者不需要的数据项。
笔者当前在某个支付公司工作，公司里几乎每个业务都需要使用枚举类型，在微服务平台下，笔者在研发流程规范中定义了一条枚举值使用规范：
在服务接口的定义中，参数可以使用枚举值，在返回值的DTO中禁止使用枚举值。
这条规范就是读者容错模式在实践中的一个实例，之所以在参数中允许使用枚举值，是因为如果服务的提供者升级了接口，增加了枚举值，若服务的消费者并没有感知，则服务的消费者得知新的枚举值就可以传递新的枚举值了；但是如果接口的返回DTO中使用了枚举值，并且因为某种原因增加了枚举值，则服务消费者在反序列化枚举时就会报错，因此在返回值中我们应该使用字符串等互相认可的类型，来做到双方的互相兼容，并实现读者容错模式。
2. 消费者驱动契约模式
消费者驱动契约模式用来定义服务化中服务之间交互接口改变的最佳规则。
服务契约分为：提供者契约、消费者契约及消费者驱动的契约，它从期望与约束的角度描述了服务提供者与服务消费者之间的联动关系。
提供者契约：是我们最常用的一种服务契约，顾名思义，提供者契约是以提供者为中心的，提供者提供了什么功能和消息格式，各消费者都会无条件地遵守这些约定，不论消费者实际需要多少功能，消费者接受了提供者契约时，都会根据服务提供者的规则来使用服务。
消费者契约：是对某个消费者的需求进行更为精确的描述，在一次具体的服务交互场景下，代表消费者需要提供者提供功能中的哪部分数据。消费者契约可以被用来标识现有的提供者契约，也可以用来发现一个尚未明确的提供者契约。
消费者驱动的契约：代表服务提供者向其所有当前消费者承诺遵守的约束。一旦各消费者把自己的具体期望告知提供者，则提供者无论在什么时间和场景下，都不应该打破契约。
在现实的服务交互设计中，上面这三种契约是同时存在的，笔者所在的支付平台里，交易系统在完成一笔支付后，需要到账务系统为商户入账，在这个过程中，服务契约表现如下。
生产者契约：账务系统提供Dubbo服务化接口，参数为商户账户ID、入账订单号和入账金额。
消费者契约：账务系统返回DTO，包含商户账户ID、入账订单号、入账金额、入账时间、账务流水号、入账状态等，而交易系统只需使用其中的入账订单号和入账状态。
消费者驱动的契约：为了保证资金安全，交易系统作为入账的发起者向账务提出要求，需要账务做幂等和滤重处理，对重复的入账请求进行拦截；账务系统在接受这个契约后，即使将来有任何改变，也不能打破这个限制，否则就会造成资金的损失，这在金融系统中是最严重的问题。
服务之间的交互需要使用的三种服务契约如图所示。
从图上可以看到，服务提供者契约是服务提供者单方面定下的规则，而一个消费者契约会成为提供者契约的一部分，多个服务消费者可以对服务提供者提出约束，服务提供者需要在将来遵守服务消费者提出的契约，这就是消费者驱动的契约。
3. 去数据共享模式
与SOA服务化对比，微服务是去ESB总线、去中心化及分布式的；而SOA还是以ESB为核心实现遗留系统的集成，以及基于Web Service为标准实现的通用的面向服务的架构。在微服务领域，微服务之间的交互通过定义良好的接口来实现，不允许使用共享数据来实现。
在实践的过程中，有些方案的设计使用缓存或者数据库作为两个微服务之间的纽带，在业务流程的处理过程中，为了处理简单，前一个服务将中间结果存入数据库或者缓存，下一个服务从缓存或者数据库中拿出数据继续处理。处理流程如图所示。
这种交互流程的缺点如下。
使得微服务之间的交互除了接口契约，还存在数据存储契约。
上游的数据格式发生变化时，可能导致下游的处理逻辑出现问题。
多个服务共享一个资源服务，对资源服务的运维难以划清职责和界限。
在做双机房独立部署时，需要考虑服务和资源的路由情况，跨机房的服务调用不能使用独立的资源部署模式，因此难以实现服务自治。
因此，在设计微服务架构时，一定不要共享缓存和数据库等资源，也不要使用总线模式，服务之间的通信和交互只能依赖定义良好的接口，通常使用RESTful样式的API或者透明的RPC调用框架。
微服务的分解和组合模式
使用微服务架构划分服务和团队是微服务架构实施的重要一步，良好的划分和拆分使系统达到松耦合和高内聚的效果，然后通过微服务的灵活组装可以满足上层的各种各样的业务处理需求。
在微服务架构的需求分析和架构设计过程中，通常是用领域的动词和名词来划分微服务的，例如，对于一个电商后台系统，可以分解为订单、商品、商品目录、库存、购物车、交易、支付、发票、物流等子系统，每个名词和动词都可以是一个微服务，将这几个微服务组合在一起，就实现了电商平台用户购买商品的整个业务流。
这样拆分以后，系统具有敏捷性、灵活性、可伸缩性等，拆分后有多个高度自治的微服务，那么以什么方式组合微服务呢？
1. 服务代理模式
服务代理模式是最简单的服务组合模式，它根据业务的需求选择调用后端的某个服务。在返回给使用端之前，代理可以对后端服务的输出进行加工，也可以直接把后端服务的返回结果返回给使用端。
服务代理模式的架构如图所示。
在笔者工作的微服务化架构平台下，经常会使用这种模式，典型的案例是做平滑的系统迁移，通常经历如下4个阶段。
在新老系统上双写。
迁移双写之前的历史遗留数据。
将读请求切换到新系统。
下调双写逻辑，只写新系统。
服务代理模式常常应用到第3步，一般会对读请求切换设计一个开关，开关打开时查询新系统，开关关闭时查询老系统。
迁移案例中开关的逻辑如图所示。
2. 服务聚合模式
服务聚合模式是最常用的服务组合模式，它根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合、加工和转换，最后以一定的形式返回给使用方。
这里，每个被依赖的微服务都有自己的缓存和数据库，聚合服务本身可以有自己的数据存储，包括缓存和数据库等，也可以是简单的聚合，不需要持久化任何数据。
服务聚合模式的架构如图所示。
这里体现了DRY（Don’t Repeat Yourself）原则的设计理念，在设计或者构造应用时，最大限度地重用了现有的实现。假如一块业务逻辑由三个独立的逻辑块组成，每个独立的逻辑块可能有多个使用方，则DRY原则推荐将三个独立的逻辑块封装成三个独立运行的微服务，然后使用本节的服务聚合模式开发聚合服务，将三个独立的逻辑块聚合在一起提供给上层组合服务。这样的设计原则有如下好处。
三个独立的子服务可以各自独立开发、敏捷变更和部署。
聚合服务封装下层的业务处理服务，由三个独立的子服务完成数据持久化等工作，项目结构清晰明了。
三个独立的子服务对于其他使用方仍然可以重用。
考虑到本节开头的例子，在对微服务进行拆分时，将电商后台系统大致拆分成订单、商品、商品目录、库存、购物车、交易、支付、发票、物流等微服务，那么电商平台的前端应用就是后端各个微服务的一个最大的聚合服务，前端应用通过调用商品和商品目录显示商品列表，提供给用户选择商品的功能，用户选择商品后增加商品到购物车，在用户从购物车结算时，调用交易系统完成交易和支付等。
电商前台的聚合模式的案例架构如图所示。
另外，聚合服务也可以是一个纯后台服务，通过聚合对使用方输出组合的服务，例如在上面的电商系统案例中，在用户选择结算后，系统调用交易，交易系统会调用库存系统锁库存，然后创建交易订单，引导用户去支付，支付成功后扣减库存，最后通过发票服务开具电子发票。
电商后台交易服务的聚合模式架构如图所示。
3. 服务串联模式
服务串联模式类似于一个工作流，最前面的服务1负责接收请求和响应使用方，串联服务后再与服务1交互，随后服务1与服务2交互，最后，从服务2产生的结果经过服务1和串联服务逐个处理后返回给使用方，如图所示。
服务串联模式之间的调用通常使用同步的RESTful风格的远程调用实现，注意，这种模式采用的是同步调用方式，在串联服务没有完成并返回之前，所有服务都会阻塞和等待，一个请求会占用一个线程来处理，因此在这种模式下不建议服务的层级太多，如果能用服务聚合模式代替，则优先使用服务聚合模式，而不是使用这种服务串联模式。
相对于服务聚合模式，服务串联模式有一个优点，即串联链路上再增加一个节点时，只要不是在串联服务的正后面增加，那么串联服务是无感知的。
在串联服务中调用链的最后端增加服务无感知的架构如图所示。
在上面提及的电商案例中，UI前端应用调用交易，交易调用商品库存系统锁定库存和扣减库存，使用的就是服务串联模式。
服务串联模式案例的架构如图所示。
4. 服务分支模式
服务分支模式是服务代理模式、服务聚合模式和服务串联模式相结合的产物。
分支服务可以拥有自己的数据库存储，调用多个后端的服务或者服务串联链，然后将结果进行组合处理再返回给客户端。分支服务也可以使用代理模式，简单地调用后端的某个服务或者服务链，然后将返回的数据直接返回给使用方。
服务分支模式的架构如图所示。
在实际的业务平台建设中，由于业务的复杂性，抽象的微服务可能有多层的依赖关系，依赖关系并不会太简单，经常呈现树形的分支结构。
以电商平台的支付服务架构为例，如图1-21所示。
图1-21
支付服务对接两个外部的支付网关，都要经过各自的支付渠道网关，同时支持账户余额支付，这个支付服务其实就是一个分支模式，在实际项目中这种服务分支模式很多。
笔者在构建支付平台时，由于大量地使用了服务分支模式，所以发现了一个比较有趣的现象，如下所述。
假设有一个基础服务，在服务分支模式的多个层次中对基础服务都有依赖，那么当基础服务的一台机器宕机时，假设基础服务有8台机器，则最后受影响的流量并不是1/8。假设基础服务6共有8台机器，服务1、服务3和服务5组成某服务的一个调用链，则调用链过程中会多次调用基础服务6。
具体服务的调用链示意图如图所示。
尽管Java架构师学习路线已经分享给大家，但有多少学员能认真的去践行，这个就难说了。互联网寒冬已经到来，作为程序员，更应在此时提高自己，有着更高远的追求。
篇幅有限，如果需要更详细的java架构师学习路线资料可加博主qq：1993712276，或者去图灵官网查看