微服务模式(1)--读模式和写模式

微服务本身是独立且隔离的个体，基于业务的需要， 一个完整的业务可能需要多个微服务的数据整合。

  微服务与微服务之间不应该存在强耦合关系，应该存在协作关系，彼此独立。

  微服务之间的协作存在以下几种模式：

一 当前微服务执行读操作，该服务依赖的其他服务也是读操作，简称 "ReadRead"模式

   这应该是最常见的一种方式了，比如查订单时需要依赖查询物流服务，一般的建议是整个查询链路不要超过5个微服务，不要问为什么，问了就是“根据经验“。

  "ReadRead"模式比较难搞的问题是分页查询，最难搞的情形是每个依赖的服务都要分页，然后再合并查询结果；下一个请求来了再对每个微服务分页，然后再合并结果。

这种做法显然是极其痛苦和傻屌的，那有没有一种一劳永逸而又优雅的做法呢？

  ....找了一圈，发现没有好办法，一个思路是从产品和设计上避免这种极端情况，要么就对这几个微服务做合并，出现这种场景说明这块的业务关联度很大，又不是做淘宝京东那么大的体量，服务粒度拆的那么细完全没有必要啊

二 当前微服务执行写操作，该服务依赖的其他服务存在写操作，简称 "ReadWrite"模式

 针对这种模式在DMS业务中不太可能存在，可以暂时忽略

三 当前微服务执行写操作，该服务依赖的其他服务存在读操作，简称 "WriteRead"模式

 针对这种模式的方案可以参考 服务补偿 + 服务内事务控制  → 可以借助于Java8 Completable Future或者RxJava

四 当前微服务执行写操作，该服务依赖的其他服务存在写操作，简称 "WriteWrite"模式

针对这种模式的方案，可以有两种方式来解决：

    1 服务补偿 + 服务内事务控制  

             可以借助于Java8 Completable Future或者RxJava + Spring 事务管理组件

             当需要强最终一致性时，可以使用同步变成模式，最终的效果：服务A调用服务B，只有在B有返回时再执行后面的代码

   

2 事件驱动 + 服务内事务控制  → 可以借助于Spring Cloud Stream + Spring事务管理组件

           这种模式比较适合弱一致性