集成是微服务相关技术中最重要的一个。做得好的话，你的微服务可以保持自治性，可以独立修改和发布他们，如果做的不好的话，会带来灾难。
4.1寻找理想的集成技术
微服务间的通讯选择性很多，REST、SOAP、RPC、Protocol buffers等。
4.11避免破坏性修改
有些时候对一个微服务的修改会造成该服务消费者的修改，例如：微服务A增加了一个字段，如果处理不好的话，会导致A服务的消费者B服务也必须增加该字段才能保证服务B能够正常调用A服务。
4.12保证API的技术无关性
保证微服务间的技术无关性非常重要，这意味着不应该选择那种对微服务的具体实现技术有限制的集成方式。
4.13使你的服务易于消费方使用
消费方应该很容易的调用我们的服务。理想情况下，消费方可以使用任何技术来实现；
另一方面，提供一个客户端库也可以简化消费方的使用，但是消费方使用客户端库也会造成微服务间的耦合。
4.14隐藏内部实现细节
我们不希望消费方和服务的内部实现细节绑定在一起，因为这会增加耦合。
与细节绑定意味着，如果改动服务内部的一些实现，消费方就需要跟着做出修改，这会增加成本，因此我们要避免。
这也会导致我们为了避免消费方的修改而尽量少的对服务本身进行修改，从而导致服务内部技术债的增加。
因此，所有倾向于暴露内部实现细节的技术都不应该被采用。
4.2为用户创建接口
以MusicCrop为例，创建客户这个业务，包括新客户的创建、付账设置、发送欢迎邮件等接口；
接下来会以这个业务为例说明集成的各种方式。
4.3共享数据库
业界最常见的集成形式就是共享数据。使用这种方式时，如果其他服务想要从一个服务获取信息，可以直接访问数据库。如果想要修改，也可以直接在数据库中修改。这种方式看起来非常简单，而且可能是最快的集成方式，这也正是它流行的原因。
共享数据库的方式有以下缺点：
多个服务同时访问相同共享数据库，会造成外部服务能够查看到内部实现细节，并与其绑定在一起。存储在数据库中的数据对所有人来说都是公平的，所有服务都可以完全访问该数据库。如果我们更改数据库表结构，那么消费方就无法进行工作。共享数据库是一个大的共享API，但同时也非常不稳定。
消费方与特定的技术进行了绑定，这说的是所有服务都与共享数据库进行了绑定。如果一个某个服务使用非关系型数据库更好，那么会为以后这种形式的修改带来很大的困难。这也造成了服务间的耦合。
微服务的设计核心：高内聚和松耦合。因此通过共享数据库的方式很难满足设计要求。
4.4同步和异步
服务间的协作包括两种方式“同步和异步。
如果使用同步通信，发起一个远程服务调用后，调用方会阻塞自己并等到整个操作的完成。
如果使用异步通信，调用方不用等待操作完成就可以返回，甚至不需要关心这个操作是否完成。
同步可以知道事情是否成功执行。
异步通信对于运行时间比较长的任务来说比较有用，否则就需要在客户端和服务端之间开启一个长连接，这是非常不实际的。
当需要低延迟的时候可以使用异步通信。
处理异常通信的技术相对来说比较复杂。
同步通信 即请求/响应：发起一个请求，然后等待响应。
异步通信 即基于事件：发起一个请求，注册一个回调，当服务端操作结束后，会调用该回调。
对于使用基于事件的协作方式来说，客户端不是发起请求，而是发布一个事件，然后期待其他的协作者接收到该消息，并知道该怎么做。
基于事件的系统天生就是异步的；
业务逻辑并非集成中某个核心服务中，而是平均分布在不同的协作者中。
基于事件的协作方式耦合性很低。
4.5编排和协作
待续。。。。。。。。。。。。。。