这是我参与「第三届青训营-后端场」笔记创作活动的的第4篇笔记。

微服务架构原理及特征

• 服务通信
  • 对于单体服务，不同模块通信只是简单的函数调用。
  • 对于微服务，服务间通信意味着网络传输。

在代码层面，如何指定调用一个目标服务的地址（ip:port）？

解决思路：新增一个统一的服务注册中心用于存储服务名到服务实例的映射。

流量特征

• 统一网关入口
• 内网通信多数采用RPC
• 网状调用链路

核心服务治理功能

服务发布

服务发布（deployment），即指让一个服务升级运行新的代码的过程。

• 服务发布的难点
  • 服务不可用
  • 服务抖动
  • 服务回滚
• 解决方法
  • 蓝绿部署
    • 简单、稳定,但需要两倍资源
  • 灰度发布(金丝雀发布)
    • 在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。

负载均衡

负载均衡（Load Balance）负责分配请求在每个下游实例上的分布。

• 常见的LB策略
  • Round Robin
  • Random
  • Ring Hash
  • Least Request

稳定性治理

• 限流
• 熔断
• 过载保护
• 降级

重试

本地函数调用可能出现的异常

• 参数非法
• OOM（Out Of Memory）
• NPE（Null Pointer Exception）
• 边界 case
• 系统崩溃
• 死循环
• 程序异常退出

远程函数调用可能出现的异常

• 网络抖动
• 下游负载高导致超时
• 下游机器启机
• 本地机器负载高，调度超时
• 下游熔断、限流

重试的意义

• 降低错误率
  • 假设单次请求的错误概率为0.01，那么连续两次错误概率则为0.0001。
• 降低长尾延时
  • 对于偶尔耗时较长的请求，重试请求有机会提前返回。
• 容忍暂时性错误
  • 某些时候系统会有暂时性异常（例如网络抖动），重试可以尽量规避。
• 避开下游故障实例
  • 一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功。

重试的难点

• 幂等性
• 重试风暴
• 超时设置

重试策略

• 限制重试比例
  • 设定一个重试比例阅值（例如1%），重试次数占所有请求比例不超过该阙值。

• 防止链路重试
  • 链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明“请求失败，但别重试”。

• Hedged requests
  • 对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。