这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
微服务框架 - 不变的基建
微服务架构介绍
系统架构演变史
单体架构
all in one process
优势：
- 性能最高
- 冗余小
劣势：
- debug困难
- 模块互相影响
- 模块分工、开发流程(几乎无法分工)
垂直应用架构
按照业务线垂直划分
优势：
- 业务独立开发维护
劣势：
- 不同业务存在冗余
- 每个业务还是单体
分布式架构
抽出业务无关的公共模块
优势
- 业务无关的独立服务
劣势
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
SOA架构(Service Oriented Architecture)
面向服务
优势
- 服务注册
劣势
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
微服务架构
彻底的服务化
优势
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
微服务架构核心要素
微服务架构原理及特征
基本概念
- 服务(service)：一组具有相同逻辑的运行实体
- 实例(instance)：一个服务中，每个运行实体即为一个实例
- 实例与进程的关系：实例与进程之间没有必然对应关系，一个实例可以对应多个进程(反之不常见)
- 集群(cluster)：通常指服务内部的逻辑划分，包含多个实例
- 常见的实例承载形式：进程、VM、k8s pod... ...
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)
服务间通信
对于单体服务，不同模块通信只是简单的函数调用；对于微服务，服务间通信意味着网络传输
服务注册及发现
在代码层面，如何指定调用一个目标服务的地址(ip:port)？
解决思路：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
服务上线及下线过程
例如系统管理员要下线service B的实例-3
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
服务发布
服务发布(deployment)，即指让一个服务升级运行新的代码的过程
服务发布的难点
- 服务不可用
- 服务抖动
- 服务回滚
蓝绿部署
简单，稳定，但需要两倍资源
灰度发布
流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制
负载均衡
负载均衡(Load Balance)负责分配请求在每个上下游实例上的分布
常见的LB策略
- Round Robin
- Random
- Ring Hash
- Least Request
- ... ...
稳定性治理
线上服务总是会出现问题的，这与程序的正确性无关
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
- ... ...
微服务架构中典型的稳定性治理功能：
- 限流
- 熔断
- 过载保护
- 降级
字节跳动服务治理实践
重试的意义
一般来说本地函数调用异常没有重试的必要，远程函数调用异常有重试的必要
本地函数调用可能有哪些异常？
- 参数非法
- OOM(out of Memory)
- NPE(Null Pointer Exception)
- 边界case
- 系统崩溃
- 死循环
- 程序异常
远程函数调用可能有哪些异常？
- 网络抖动
- 下游负载高导致超时
- 下游机器宕机
- 本地机器负载高，调度超时
- 下游熔断、限流
- ... ...
- 重试可以避免掉偶发的错误，提高SLA(Service-Level Agreement)
- 降低错误率：假设单次请求的错误概率为0.01，那么连续两次错误概率为0.0001
- 降低长尾延时：对于偶尔耗时较长的请求，重试请求有机会提前返回
- 容忍暂时性错误：某些时候系统会有暂时性异常(例如网络抖动)，重试可以尽量规避
- 避开下游故障实例：一个服务中可能会有少量实例故障(例如机器故障)，重试其他实例可以成功
重试的难点
- 幂等性：多次请求可能会造成数据不一致
- 重试风暴：随着调用深度的增加，重试次数会指数级上涨
- 超时设置：假设一个调用正常是1s的超时时间，如果允许一次重试，那么第一次请求经过多少时间，才开始重试呢？
重试风暴：
重试策略
限制重试比例
设定一个重试比例阈值(例如1%)，重试次数占所有请求比例不得超过该阈值
防止链路重试
链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明“请求失败，但别重试”
Hedged requests
对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应
实际验证经过上述重试策略后，在链路上发生的重试放大效应
