这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
本堂课重点内容：
-
微服务架构介绍
- 微服务架构的背景由来、架构概览、基本要素
-
微服务架构原理及特征
- 微服务架构的基本组件、工作原理、流量特征
-
核心服务治理功能
- 核心的服务治理功能，包括流量治理、服务均衡、稳定性治理
-
字节跳动服务治理实践
- 字节跳动在微服务架构稳定性治理中，对请求重试策略的探索及实践
1.微服务架构介绍
微服务架构是当前大多数互联网公司的标准架构。
1.1 系统架构演变历史
为什么系统架构需要演进？
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
1.1.1 单体架构
- All in one process
| 优势 | 劣势 |
|---|---|
| 1.性能最高 | 1. debug 困难 |
| 2.冗余小 | 2.模块相互影响 |
| 3.模块分工、开发流程 |
1.1.2 垂直应用架构
- 按照业务线垂直划分
| 优势 | 劣势 |
|---|---|
| 1.业务独立开发维护 | 1.不同业务存在冗余 |
| 2.每个业务还是单体 |
1.1.3 分布式架构
- 抽出与业务无关的公共模块
| 优势 | 劣势 |
|---|---|
| 1.业务无关的独立服务 | 1.服务模块 bug 可导致全站瘫痪 |
| 2.调用关系复杂 | |
| 3.不同服务冗余 |
1.1.4 SOA架构(Service Oriented Architecture)
- 面向服务
| 优势 | 劣势 |
|---|---|
| 1.服务注册 | 1.整个系统设计是中心化的 |
| 2.需要从上至下设计 | |
| 3.重构困难 |
1.1.5 微服务架构
- 彻底的服务化
| 优势 | 劣势 |
|---|---|
| 1.开发效率 | 1.治理、运维难度 |
| 2.业务独立设计 | 2.观测挑战 |
| 3.自下而上 | 3.安全性 |
| 4.故障隔离 | 4.分布式系统 |
1.2 微服务架构整体概览
- 网关
- 服务配置和治理
- 链路追踪和监控
1.3 微服务架构的三大要素
| 服务治理（本课程内容） | 可观测性 | 安全 |
|---|---|---|
| 服务注册 | 日志采集 | 身份验证 |
| 服务发现 | 日志分析 | 认证授权 |
| 负载均衡 | 监控打点 | 访问令牌 |
| 扩缩容 | 监控大盘 | 审计 |
| 流量治理 | 异常报警 | 传输加密 |
| 稳定性治理 | 链路追踪 | 黑产攻击 |
2.微服务架构原理及特征
2.1 微服务架构中的基本概念及组件
| 概念 | 描述 |
|---|---|
| 服务 （service） | 一组具有相同逻辑的运行实体 |
| 实例 （instance） | 一个服务中的每个运行实体 |
| 实例与进程的关系 | 没有必然对应关系，一般一对一或者一对多 |
| 集群 （cluster） | 通常指服务内部的逻辑划分，包含多个实例 |
| 常见的实例承载形式 | 进程、VM、k8s pod...... |
| 有状态/无状态服务 | 服务的实例是否存储了可持久化的数据(例如磁盘文件) |
如果把 HDFS 看做一组微服务
2.2 服务间通信
对于单体服务，不同模块通信只是简单的函数调用。 对于微服务，服务间通信意味着网络传输
- 微服务之间通过网络进行通信
- 常见的通信协议包括 HTTP、RPC
2.3 服务注册及服务发现
2.3.1 基本问题
服务间调用中，如何指定下游服务实例的地址？
对于网络通信功能（不管http还是rpc),我们知道是需要指定远程的 ip port 的。
既然服务之间存在通信关系，在实际代码层面，我们如何指定调用一个目标服务的地址(ip:port)?
2.3.2 直接指定 ip:port
hardcode 的方式指定下游实例地址有什么问题？
- 没有任何动态能力
- 有多个实例下游实例怎么办？
// Service A wants to call service B.
client := grpc.NewClient("10.23.45.67:8080")
- 服务有多个实例，没法 hardcode (记住一个服务的所有实例部是运行同一份代码)
- 服务实例 ip 地址不可能写死，它会动态变化
2.3.3 使用 DNS
DNS 的思想：中间层
存在的问题：
- 本地 DNS 存在缓存，导致延迟
- DNS 没有负载均衡
- 不支持服务探活检查
- DNS 不能指定端口
2.3.4 服务注册发现
与 DNS 类似，需要引入一个中间层
解决思路：新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系
服务实例上线及下线过程
- 旧服务实例下线前，从服务注册中心删除该实例，下线流量
不能直接下线，因为还有流量
- 新服务实例上线后，在服务注册中心注册该实例，上线流量
2.4 微服务流量特征
- 统一网关入口
- 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
- 网状调用链路
弱化连接的概念，强调“请求”
即同一个客户端长连接发出的请求，理论上可以到达服务中所有实例
API gateway可以用作身份认证，进而将token附在请求上
2.5 总结
- 微服务架构中的基本组件及术语
- 服务注册及发现
- 无损的服务实例上下线流程
- 微服务架构中的基本流量特征
3.核心服务治理功能
3.1 服务发布(deployment)
-
何为服务发布
- 让一个服务升级运行新的代码的过程
3.1.1 服务发布难点
- 服务不可用
- 服务抖动
- 服务回滚
3.1.2 蓝绿部署
- 将服务分成两个部分，分别先后发布
- 简单、稳定
- 但需要两倍资源
适合在流量低峰时采用
3.1.3 灰度发布（金丝雀发布）
金丝雀 (canary) 对瓦斯及其敏感，17世纪时，英国旷工在下井前会先放入一只金丝雀，以确保矿井中没有瓦斯。
- 先发布少部分实例，接着逐步增加发布比例
- 不需要增加资源
- 回滚难度大，基础设施要求高
3.2 流量治理
-
流量控制
- 在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制
这里指狭义的对流量进行控制
-
控制维度
- 地区维度
- 集群维度
- 实例维度
- 请求维度
3.3 负载均衡(Load Balance)
最基本的问题，一个服务中，通常每个实例的负载应当是大体均衡一致的
负载均衡负责分配请求在每个下游实例上的分布。
常见的LB策略：
- Round Robin
- Random
- Ring Hash
- Least Request
3.4 稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
网络攻击、流量突增、机房断电、光纤被挖、机器故障、网络故障、机房空调做障等等。
微服务架构中典型的稳定性治理功能：
-
限流
- 限制服务处理的最大 QPS，拒绝过多请求
-
熔断
- 中断请求路径，增加冷却时间从而让故障实例尝试恢复
-
过载保护
- 在负载高的实例中，主动拒绝一部分请求，防止实例被打挂
-
降级
- 服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求
3.5 总结
- 服务发布：蓝绿部署、灰度发布
- 基于地区、集群、实例、请求等维度的流量治理功能
- 几种常见的负载均衡策略
- 微服务架构中的稳定性治理功能
4.字节跳动服务治理实践
我们以重试功能为例，介绍字节跳动在这方面的实践
4.1 请求重试的意义
4.1.1 本地函数调用
可能有哪些异常：
参数非法、OOM(Out Of Memory）、NPE(Null Pointer Exception)、边界case、系统崩溃、死循环、程序异常退出等等。
- 通常没有重试意义
4.1.2 远程函数调用
- 可能有哪些异常：
网络抖动、下游负载高导致超时、下游机器宕机、本地机器负载高、调度超时、下游熔断、限流等等
- 重试是有意义的，可以避免偶发性的错误，提高 SLA (Service-Level Agreement)
4.1.3 重试的意义
| 意义 | 描述 |
|---|---|
| 降低错误率 | 假设单次请求的错误概率为 0.01，那么连续两次错误概率则为 0.0001。 |
| 降低长尾延时 | 对于偶尔耗时较长的请求，重试请求有机会提前返回 |
| 容忍暂时性错误 | 某些时候系统会有暂时性异常（例如网络抖动），重试可以尽量规避。 |
| 避开下游故障实例 | 一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功。 |
4.2 请求重试的难点
既然重试这么多好处，为什么默认不用呢？
4.2.1 幂等性
即多次请求可能会造成数据不一致
- POST 请求可以重试吗？
4.2.2 重试风暴
随着调用深度的增加，重试次数会指数级上升
假设我们使用简单的 for 循环，循环 3 次进行重试：
4.2.3 超时设置
假设调用时间一共1s，经过多少时间开始重试？
4.3 重试策略
4.3.1 限制重试比例
- 设定一个重试比例阈值（例如 1%），重试次数占所有请求比例不超过该阈值
重试只有在大部分请求都成功，只有少量请求失败时，才有必要。
如果大部分请求都失败，重试只会加剧问题严重性。
因此，可以定义，比如重试次数不超过血正常成功请求次数的1%
4.3.2 防止链路重试
链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试，
- 返回特殊的 status code，表示“请求失败，但别重试”
缺点：对业务代码有侵入性
4.3.3 Hedged Requests（对冲的请求）
- 对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应
4.4 重试效果验证
- 字节跳动重试组件能够极大限制重试发生的链路放大效应
实际验证经过上述重试策略后，在链路上发生的重试放大效应。
4.5 总结
- 重试的意义及难点
- 应对重试风暴的策略
课后
- 结合 CAP 等原理，思考微服务架构有哪些缺陷？
- 微服务是否拆分得越“微”越好？为什么？
- Service Mesh 这一架构是为了解决微服务架构的什么问题？
- 有没有可能有这样一种架构，从开发上线运维体验上是微服务，但实际运行又类似单体服务？。
个人总结
- 形成微服务架构的原因
- 微服务架构的组成和各组件发挥的作用
- 对微服务的治理的一些方案
- 针对微服务下的服务治理之一 ：请求重试
