微服务通信

为了保证拆分之后的微服务能够通力合作，共同对外提供服务能力，需要通过一定的机制将拆分之后的微服务合起来，也就是微服务通信。

1.微服务通信方式

选择微服务通信时，首先需要考虑的是通信方式的选择，对一些不需要返回业务数据的微服务来说，究竟是采用同步方式还是异步方式呢？同步方式架构层面要求比较高，异步方式架构层面比较优雅，但运维成本比较高，出现问题时排查起来不太方便。因此微服务化时，核心服务推荐均采用同步通信的方式，一些非核心服务可以采用异步通信的方式。

2.微服务编排

微服务编排上，一些可以并行调用的场景推荐采用并行调用的方式，可以减少请求的整体耗时，提高用户体验。当然对于有些场景来说，直接采用并行调用不一定是最好的方式，需要综合考虑和分析。面对这种场景，需要有一套完善的微服务编排引擎，能够同时兼顾性能和成本上的需求，做到微服务编排的最优化。

3.API 接口设计

API 接口设计上，需要尽可能简单易用，一个接口只实现一个确定的功能，不要设计复杂或者含义不明确的接口，避免滥用；同时接口设计时做好前后向兼容，以及幂等性设计。

4.合理设置超时和重试

微服务通信上，需要合理设置超时和重试，超时和重试设置不要只考虑当前链路，而要从请求全链路的角度，对超时和重试进行统一梳理。除非有特殊原因，建议在调用的入口统一进行重试，请求过程中不再进行重试，避免故障时的多级重试导致的整体雪崩。

5.数据一致性设计

同时操作多个微服务的场景，需要保证不同微服务之间的数据一致性，数据一致性设计尽量遵循简单的原则，除非特别场景，不要使用分布式事务。多个微服务操作时，成功或失败需要以核心数据为准，当同时对多个核心数据进行操作时，可以以其中一个为准，遇到个别数据不一致的场景，可以采用线下对账的方式对不一致的数据进行校对和修正。