集成

理想的集成技术

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

通信

交互方式

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

同步还是异步

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

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

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

API定义

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

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

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

消息格式

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

跨服务业务流程

有两种方式:编排与协同

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

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

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

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

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

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

断路器模式处理局部故障

服务保护自己的方式:

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

服务发现

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

屏幕截图 2021-01-19 112903

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

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

屏幕截图 2021-01-19 112958

同步的编排方式

屏幕截图 2021-01-19 105517

远程过程调用(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) {}
}
...
  • 高效紧凑
  • 支持双向流式

异步的协作方式

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

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

异步协作的两种架构:

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

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

可实现的交互方式:

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

API规范

屏幕截图 2021-01-19 142500

异步操作:

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

记录事件发布API

技术选择

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

异步架构复杂性

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

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

服务即状态机

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

响应式扩展

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

微服务中代码复用的危险

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

按引用访问

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

版本管理

  • 尽可能推迟修改

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

  • 及早发现破坏性修改

  • 使用语义化的版本管理

    • 通过版本号来告知消费方功能增加或是否向后兼容
  • 多版本接口共存
  • 多版本服务共存

用户界面

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

为前端服务的后端

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

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

集成第三方软件

一些风险:

  • 缺乏控制

results matching " "

No results matching " "

results matching " "

No results matching " "