集成

理想的集成技术

通信

交互方式

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

同步还是异步

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

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

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

API定义

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

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

消息格式

跨服务业务流程

有两种方式:编排与协同

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

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

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

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

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

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

断路器模式

服务保护自己的方式:

同步的编排方式

屏幕截图 2021-01-19 105517

远程过程调用

异步的协作方式

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

异步协作的两种架构:

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

可实现的交互方式:

API规范

屏幕截图 2021-01-19 142500

异步操作:

记录事件发布API

技术选择

异步架构复杂性

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

按引用访问

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

服务即状态机

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

响应式扩展

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

微服务中代码复用的危险

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

版本管理

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

用户界面

BFF

服务查询模式

API组合模式

让拥有数据的服务的客户端调用服务,并组件服务返回的查询结果

屏幕截图 2021-01-26 150338

问题:

  1. 选择谁为组合器
  1. 如何在组合器编写聚合逻辑

这种方式好处是简单直观。弊端:

CQRS模式

维护一个或者多个视图数据库,进而实现查询。

屏幕截图 2021-01-26 154520

好处与弊端:

CQRS视图设计