集成

理想的集成技术

通信

交互方式

模式 一对一 一对多
同步模式 请求/响应
异步模式 异步请求/响应 单向通知 发布/订阅 发布/异步响应

同步还是异步

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

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

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

API定义

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

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

消息格式

跨服务业务流程

有两种方式:编排与协同

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

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

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

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

事件发生:
    服务A接收到事件,做一些事
    服务B接收到事件,做一些事

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

断路器模式处理局部故障

服务保护自己的方式:

服务发现

屏幕截图 2021-01-19 112903

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

屏幕截图 2021-01-19 112958

同步的编排方式

屏幕截图 2021-01-19 105517

远程过程调用(RPC)

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

一些问题

REST

REST是RPC的一种替代方案

REST成熟度模型

REST与HTTP

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

载体形式

过多的约定

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

缺点

基于HTTP的REST有一些缺点:

gRPC

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

异步的协作方式

同步消息会降低可用性,为消除同步交互,可:

异步协作的两种架构:

屏幕截图 2021-01-19 142008 屏幕截图 2021-01-19 142721

可实现的交互方式:

API规范

屏幕截图 2021-01-19 142500

异步操作:

记录事件发布API

技术选择

异步架构复杂性

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

服务即状态机

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

响应式扩展

把多个调用的结果组装起来,并在此上做操作(类似于stream)

微服务中代码复用的危险

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

按引用访问

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

版本管理

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

用户界面

为前端服务的后端

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

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

集成第三方软件

一些风险: