01 微服务架构介绍

演变历史

单体 - 垂直应用- 分布式 - SOA - 微服务

微服务架构

微服务架构核心要素

02 微服务架构原理及特征

• 服务
  • 一组具有相同逻辑的运行实体
• 实例
  • 一个服务中，每个运行实体即为一个实例
• 实例与进程的关系
  • 实例与进程没有必然对应关系，可以一个实例对应一个或多个进程
• 集群
  • 通常指服务内部的逻辑划分，包含多个实例
• 常见的实例承载形式
  • 进程、VM、k8s pod...
• 有状态/无状态服务
  • 服务的实例是否存储了可持久化的数据（例如磁盘文件）

2.1 基本概念

服务间通信

2.2 服务注册及发现

• 硬编码
• DNS
  • 问题：本地DNS缓存延时；负载均衡问题；不支持服务实例的探活检查；域名无法配置端口
• 服务注册中心
  • 思路：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射

2.3 流量特征

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

03 核心服务治理功能

3.1 服务发布

难点

• 服务不可用
• 服务抖动
• 服务回滚

方式

• 蓝绿部署
• 灰度发布（金丝雀发布）

3.2 流量治理

在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。

3.3 负载均衡

常见策略

• Round Robin
• Random
• Ring Hash
• Least Request

3.4 稳定性治理

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

04 字节跳动服务治理实践

4.1 重试的意义

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

4.2 重试的难点

重试的难点

• 幂等性
  • 多次请求可能数据不一致
• 重试风暴
  • 随着调用深度增加，重试次数会指数级上涨
• 超时设置
  • 假设一个调用正常是1s的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢？

4.3 重试策略

• 限制重试比例
  • 设定重试阈值（比如1%）
• 防止链路重试
  • 限制每层都发生重试，理想情况下只有最下一层发生重试
  • 可以返回特殊的status表明“请求失败，但别重试”
• Hedged requests
  • 对于可能超时（或延时高）的请求，重新向另一个下游实例发送相同请求，并等待先到达的响应

4.4 重试效果验证

实际验证经过上述重试策略后，在链路上发生的重试放大效应