集成

理想的集成技术

• 避免破坏性修改
  • 一个服务的修改会导致服务的消费方也发生变化
• 保证API的技术无关性
  • 也就说，API不管使用什么技术，应该都能实现，保证通信方式的技术无关性是非常重要的，这样各个服务才有可能使用不同的技术实现
• 使服务易于消费方使用
• 隐藏内部实现细节
  • 如果消费方与服务的实现细节绑定在一起，会增加两者间的耦合

通信

交互方式

• 一对一与一对多
• 同步与异步

同步还是异步

同步通信，发起一个远程调用后，会阻塞自己并等待整个操作的完成

异步通信，则不需要等待操作结束就可以访问

使用哪种方式，要取决于哪种风格的通信解决的问题

API定义

如何定义API取决于进程间通信机制。

随着应用演进，API也会随着演进。

• 次要且向后兼容的演进：增加可选属性、添加新操作等
• 主要且不向后兼容的演进：此时可以引入版本号

消息格式

• 基于文本消息格式：xml、json。好处在于可读性高、自描述。缺点在于消息过度冗长。
• 二进制消息格式：protocol buffers、avro。编译器根据定义的IDL生成序列化与反序列代码。好处性能高。

跨服务业务流程

有两种方式：编排与协同

编排是有一个控制中心，指导其他服务应该做些什么，具体怎么做，则交给具体服务

事件发生：    控制中心调用服务A    控制中心调用服务B

使用这种方式的缺点是会让控制中心承担太多的职责，并会导致少量的“上帝服务（上帝视角）”

若使用协同，则是可以客户触发一个事件，监听到这个事件的具体服务去做一些事情

事件发生：    服务A接收到事件，做一些事    服务B接收到事件，做一些事

这个方式的优点是能显著地消除耦合，但是缺点是无法看到清晰的业务流程，所以这种方式需要一定的监控手段来保证业务的正确性

断路器模式处理局部故障

服务保护自己的方式：

• 网络超时：对某个服务的超时不能无限
• 限制客户端的请求数量
• 断路器模式

服务发现

• 应用层：服务直接与服务注册表交互

好处在于可以处理多平台部署问题，弊端则是需要为每种编程语言提供一个SDK。

• 平台层：使用基础设施来实现服务发现

同步的编排方式

远程过程调用（RPC）

在分布式计算，远程过程调用（英语：Remote Procedure Call，缩写为 RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（无需关注细节）

一些问题

• 技术耦合
  • 如果使用JAVA RMI，就会将服务端与客户端都绑定在JVM上
• 远程调用的开销
  • 网络是不可靠的
• 脆弱
  • 一端的修改很容易影响到另外一端

REST

REST是RPC的一种替代方案

REST成熟度模型

• 0：每个请求都指明了需要执行的操作和必要的参数
• 1：引入了资源的概念，对资源进行操作
• 2：使用HTTP动词来执行操作
• 3：基于HAEOAS，超文本驱动，客户端无需硬编码REST链接。让客户端自行遍历与发现API，可以很好地隐藏低层细节，使得客户端与服务端之间实现了松耦合

REST与HTTP

REST本身没有定义应该使用哪种协议实现，但是使用HTTP协议，会简单的很多

载体形式

• JSON
• XML

过多的约定

数据持久化继承并非是一件需要过早操心的事，最好是先设计外部接口，这样可以确保服务的接口是由消费者的需求驱动出来的

缺点

基于HTTP的REST有一些缺点：

• 时延不低
• 数据包不够精简
• 需要手动编写客户端代码
• 有些框架HTTP动词支持不好

gRPC

service UserService {  rpc createUser(CreateUserRequest) returns(CreateUserReply) {}}...

• 高效紧凑
• 支持双向流式

异步的协作方式

同步消息会降低可用性，为消除同步交互，可：

• 使用消息代理来进行异步交互
• 复制数据来避免与其他服务同步交互

异步协作的两种架构：

• 消息代理：需要一些中间件来实现异步协作，尽量让中间件保持简单
  • 耦合低
  • 更为灵活
  • 额外的复杂性
• 无代理架构：直接向服务发送消息
  • 性能较高
  • 复杂性较低
  • 耦合过紧

可实现的交互方式：

• 请求/响应模型
• 单向通知
• 发布订阅
• 发布/响应

API规范

异步操作：

• 请求/异步响应API
• 单向通知API

记录事件发布API

技术选择

• MQ
• 基于HTTP的发布订阅模式

异步架构复杂性

采用异步架构，要考虑的事情就更多了

• 并发与消息顺序
  • 在kafka中，使用了分片来解决顺序
• 重复消息
  • 应用程序需要自己进行幂等处理
• 事务性消息
  • 消息队列表与分布式事务

服务即状态机

服务拥有在限界上下文中的所有逻辑，这样可以在唯一一个地方处理逻辑

响应式扩展

把多个调用的结果组装起来，并在此上做操作（类似于stream）

微服务中代码复用的危险

不同的服务复用同一块代码，一个服务修改的代码很可能影响另一个服务

按引用访问

在进行事件通知时，传递的数据应该是指向资源的一个引用，这样当其他服务处理这个事件时，就可以根据这个引用得到最新的数据，而避免数据不一致的情况

版本管理

• 尽可能推迟修改

宽进严出原则：对自己发送的东西要严格，对接收的东西可以宽容一点

• 及早发现破坏性修改

• 使用语义化的版本管理

  • 通过版本号来告知消费方功能增加或是否向后兼容

• 多版本接口共存

• 多版本服务共存

用户界面

• 数字化
  • 未来的需求很难预测，提供细粒度的API
• 不同场景的约束
• API的组合
  • 使用网关来缓解客户端与服务之间的过多交互
• 服务直接提供UI片段

为前端服务的后端

再在服务之上封装一个API提供粗粒度的接口，这些接口通过调用下层的服务来提供服务

但是这层API很容易发展为一个怪兽，并且可能会有业务逻辑混入其中

集成第三方软件

一些风险：

• 缺乏控制