响应式架构
对请求、事件、失败、用户进行响应
- 实时：及时给用户响应
- 高效：充分利用多核
- 弹性：隔离故障、解耦参与方
在响应式编程的基础上
原则
Responsive
- 确保及时对用户做出一致快速的响应
Elastic
- 在工作负载变化的情况下也能及时响应
- 避免出现中央瓶颈，使得可以分片复制动态伸缩 不仅可以抗住高负载 也能节省资源
Message Driven
通过异步消息驱动不仅可以在组件之间隔离边界，松耦合，弹性也得到一定提升
Resilient
- 回弹性
使用复制、隔离、委派等来保证系统在出现故障时的响应能力
本质
事件与消息
- 事件关注于源
- 消息关注于终点
消息传递
事件的触发，导致了消息的传递
异步
消息流程
- 传递路径要短
- 消息流尽可能单向
- 回执消息保持精简
- 使用[DDD](/软件工程/领域驱动设计.html)来设计消息流程
背压
- 本质上是[流控](/软件工程/架构/系统设计/流量控制.html)
- 当消费速度跟不上生产速度时 消费者会反过来压制生产速度
目标透明
原始分布式时代的RPC：
- 位置透明：生产者消费者不关心对方的位置
- 远程与本地调用都使用统一的抽象
但是这种统一的抽象往往会带来额外的问题，需要付出更大的成本
定界一致性
通过保证小一级模块的强一致性从而来使系统达成最终一致性
使用DDD来将相应的行为与数据划分在一起，形成事务边界
模式
单一组件
将复杂组件拆解为不同的组件，每个组件遵循SRP原则
错误内核
将状态保留在高层 当进行错误恢复时 状态得以保留从而恢复到当时状态 避免出现错误时当前组件崩溃状态丢失
任其崩溃
对于恢复成本极高的组件出现故障时，不进行修复，直接重启
为了发现故障，需要通过某种心跳监控来发现
断路器
消息流模式
请求响应
自包含消息
消息本身包含了处理所需的上下文 状态保存在消息里 处理者保持无状态
前进流
使用第三方组件是有代价的 如非必要 勿增实体
聚合器
聚合多方服务的数据 若无依赖 使用并发请求再汇总
商务握手
- 保证消息的可靠传递
流控模式
推拉
由消费者根据自身处理能力进行批量拉取数据 可以解决背压问题
推模式则时效性高 主动推送
托管队列
由于速度差异或者瞬时流量 使用一个FIFO队列来进行流量整形 使系统可以平滑度过