微服务集成问题

微服务的集成应避免破坏性修改。微服务之间通信方式的选择非常多样化。有时候，对某个服务做的一些修改会导致该服务的消费方也随之发生改变。希望选用的技术可以尽量避免这种情况的发生。

保证API的技术无关性。保证微服务之间通信方式的技术无关性非常重要。不应该选择那些对微服务的具体实现技术有限制的集成方式。

使你的服务易于消费方使用。消费方应该可以采用任何技术来实现。

隐藏内部实现细节。倾向于暴露内部实现细节的技术都不应该被采用。

业界最常见的集成形式是数据库集成。这是一种非常普通的模式，但实践起来却困难重重。它使得外部系统能够查看内部实现细节、消费方与特定的技术选择绑定在一起。

服务之间的通信应该是同步还是异步的呢?如果使用同步通信，发起一个远程服务调用后，调用方会阻塞自己并等待整个操作的完成。如果使用异步通信，调用方不需等待操作完成就可返回。这两种不同的通信模式有着各自的协作风格，即请求/响应或者基于事件。

在开始对越来越复杂的逻辑进行建模时，我们需要处理跨服务业务流程的问题。当采用具体实现时，有两种架构风格可以采用。使用编排的话，我们会依赖某个中心大脑来指导并驱动整个流程。使用协同的话，我们仅仅会告知系统中各个部分自己的职责，而把具体怎么做的细节留给它自己.

远程过程调用允许你进行一个本地调用，但事实上结果是由某个远程服务器产生的。RPC的核心想法是隐藏远程调用的复杂性。但很多RPC的实现隐藏得有些过头了，会花费大量时间对负荷进行封装和解封装。有一些很流行的RPC实现可能造成一些令人讨厌的脆弱性。

服务集成的一些Tips: 

- 无论如何避免数据集成

- 理解REST和RPC之间的取舍，但总是使用REST作为请求响应模式的起点

- 相比编排，优先选择协同

- 避免破坏性修改，使用容错性读取器

- 将用户界面视为一个组合层

​