声明，此连续文章为阅读《微服务设计》[英]纽曼（Sam Newman）的读书笔记，旨在记录重点内容和阅读心得，有共读的朋友可以交流书中疑惑。

4.1 寻找理想的集成技术的指导原则
避免服务方修改一个字段就引起消费方的修改
保证API的技术无关性
消费方应该能够很简单的使用服务方提供的服务，提供客户端库的做法会增加耦合。
隐藏内部实现细节
4.2 MusicCorp创建用户接口
4.3 共享数据库
数据库集成（即消费者直接访问数据库）的缺点：表结构直接暴露给所有消费者，维护性差，改了表可能多个消费者都要改、有一天想换成非关系数据库，这样消费者都要改、多个消费者中都包括操作统一表结构的逻辑代码，代码可重复性低，可维护性差。
4.4 同步与异步
服务之间通信同步与异步的选择。
1.请求/响应
2.基于事件，客户端不是发起请求，而是发布一个事件。（没说清楚）
4.5 编排（orchestration）与协同（choreography）
在开始对越来越复杂的逻辑建模时，我们需要处理跨服务业务流程的问题，而使用微服务时这个问题会更加凸显。
MusicCorp创建客户流程

当考虑具体实现时有两种系统设计风格：
1.编排

客户服务作为中心控制点来指导和驱动整个业务流程。
缺点：客户服务承担太多职责，这种方法会导致中心控制点成为“上帝”服务，而与之打交道的其他服务都沦为CRUD的贫血服务。
2.协同

针对请求/响应 方式，可以考虑两种技术RPC和REST.
4.6 远程过程调用
RPC的缺点：客户端与服务端技术耦合、许多RPC框架隐藏远程调用的复杂性，让你可以像调用本地方法一样调用，但是也带来一些问题，网络不可靠的一些因素没有得到处理、脆弱性，接口API发生变化，会引起客户端的代码也要变化。
4.7 REST
https://martinfowler.com/articles/richardsonMaturityModel.html
《REST实战》
4.8 基于事件的异步协作方式
1.技术选择
主要有两个部分需要考虑：微服务发布事件机制和消费者接收事件机制。
RabbitMQ
ATOM
2.异步架构的复杂性
《企业集成模式》
4.9 服务即状态机
状态机设计
4.10 响应式扩展
Reactive extensions
4.11微服务世界中的DRY和代码重用的危险
微服务内部DRY，但是跨服务时引入大量的公共库会导致耦合，因此有些情况下可以适当增加微服务中代码的重复。
4.12 按引用访问
举例，发货之后要给客户发邮件，一种做法是把客户信息发给邮件系统，但是邮件系统在发送之前，这些信息可能发生变化，所以更合理的方式是将客户资源的URI发给邮件系统，邮件系统在发送时再次查询客户服务中的用户信息。
4.13 微服务版本管理
1.避免破坏性修改
客户端代码的高度容错性，比如：客户端读取xml时，可以使用XPath，若xml中字段顺序发生变更不会影响客户端解析。（所谓的“鲁棒性”原则、宽进严出）
2.及早发现破坏性修改
使用消费者驱动的契约来及早的定位这些破坏性修改对消费方的影响。
3.使用语义化的版本管理
4.不同接口共存
5.运行多个版本的同一个服务
4.14 用户界面
为前端服务的后端（BFF）
4.15 与第三方软件集成
使用外观服务来隐藏底层的第三方服务，增强对第三方软件的控制