微服务架构
微服务的扩展模型
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失败，接收方丢弃该消息
使用异步消息提高可用性：消除同步交互
- 复制数据
服务维护一个数据副本，这些数据是服务在处理请求时需要使用的，这些数据的源头会在数据变化是发出消息，服务订阅这些消息来确保数据副本的实时更新。
- 先返回响应，再完成处理
当处理请求时，服务并不需要与其他服务直接进行同步交互，取而代之的是，服务异步向其他的服务发送消息。其他服务处理完成后向服务同步处理状态，这种方式确保了服务之间松耦合。