微服务架构
微服务的扩展模型
X轴扩展在多个相同实例之间实现请求的负载均衡
Y轴扩展根据功能将应用程序拆分为服务
Z轴扩展根据请求的属性路由请求
微服务架构与SOA的异同
特性 | SOA | 微服务 |
---|---|---|
服务间通信 | 智能管道,采用重量级协议 | 哑管道,采用消息代理,点对点通信 |
数据管理 | 全局数据模型并共享数据库 | 每个服务都有自己的数据模型和数据库 |
典型服务的规模 | 较大的单体应用 | 较小的服务 |
微服务架构的好处
- 使大型的复杂应用程序可以持续交付和持续部署
- 每个服务都相对较小并容易维护
- 服务可以独立部署
- 服务可以独立扩展
- 微服务架构可以实现团队的自治
- 更容易实验和采纳新的技术
- 更好的容错性
微服务架构的弊端
- 服务的拆分和定义是一项挑战
- 分布式系统带来的各种复杂性,使开发、测试和部署变得更加困难
- 当部署跨越多个服务的功能时需要谨慎的协调更多开发团队
- 开发者需要思考到底应该在应用的什么阶段使用微服务架构
微服务进程间通信
模式 | 一对一 | 一对多 |
---|---|---|
同步模式 | 请求/响应 | 无 |
异步模式 | 异步请求/响应 单向通知 | 发布/订阅 发布/异步响应 |
请求/响应:一个客户端向服务端发起请求,等待响应,会造成线程阻塞,服务间紧耦合;
异步请求/响应:客户端发送请求到服务端,服务端异步响应请求,不会阻塞线程,请求不会马上返回;
单向通知:客户端的请求发送到服务端,不期望服务端做出任何响应;
发布/订阅:客户端发布通知消息,被零个或者多个感兴趣的服务订阅;
发布/异步响应:客户端发布请求消息,然后等待从感兴趣的服务发回响应。
基于同步远程过程调用模式的通信:REST API
REST提供了一系列架构约束,当作为整体使用时,它强调组件交互的可扩展性,接口的通用性、组件的独立部署,以及那些能减少交互延迟的中间件,它能强化了安全性,也能封装遗留系统
REST成熟度模型
- Level0:Level0层级服务的客户端只是向服务端点发起HTTP
POST请求,进行服务调用,每个请求都指明了需要执行的操作、这个操作针对的目标和必要参数 - Level1:Level1层级的服务引入了资源的概念,要执行对资源的操作,客户端需要发出指定要执行的操作和包含任何参数的POST请求
- Level2:Level2层级的服务使用HTTP动词来执行操作,GET获取,POSY创建,PUT更新,DELETE删除
- Level3:由GET请求返回的资源部信息中包含链接,这些链接能够执行该资源允许的操作
开发可靠的远程过程调用代理
- 网络超时:在等待针对请求的响应时,一定不要做出无限阻塞,而是设定一个超时,使用超时可以保证不会一直在无响应的请求上浪费资源
- 限制客户端向服务器发出的请求数量:把客户端能够像特定服务发起的请求设置一个上限,达到上限再多的请求也无济于事
- 断路器模式:监控客户端发出请求的成功和失败数量,如果失败的比例超过一定的阈值,就启动断路器
基于异步消息模式的通信:消息中间件
处理重复消息
- 编写幂等消息处理器:应用被相同输入参数多次重复调用时,也不会产生额外的结果
- 跟踪消息并丢弃重复消息:消息接收方使用message id跟踪它已处理的消息并丢弃任何重复项,将消息的message id作为创建和更新业务实体的事务的一部分记录在数据库表中,message id重复,则INSERT失败,接收方丢弃该消息
使用异步消息提高可用性:消除同步交互
- 复制数据
服务维护一个数据副本,这些数据是服务在处理请求时需要使用的,这些数据的源头会在数据变化是发出消息,服务订阅这些消息来确保数据副本的实时更新。
- 先返回响应,再完成处理
当处理请求时,服务并不需要与其他服务直接进行同步交互,取而代之的是,服务异步向其他的服务发送消息。其他服务处理完成后向服务同步处理状态,这种方式确保了服务之间松耦合。