这是我参与「第五届青训营」伴学笔记创作活动的第16天
微服务架构介绍
系统架构的演进历史
- 单体架构：All in one process
- 垂直应用架构：按照业务线垂直划分
- 分布式架构：抽出与业务无关的公共模块
- SOA架构：面向服务
- 微服务架构：彻底的服务化
微服务架构的三大要素
- 服务治理：服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理、
- 可观测性：日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪
- 安全：身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击
微服务架构的原理即特征
微服务架构中的基本概念及组件
服务：一组具有相同逻辑（代码相同）的运行实体（一个实例）- 运行同一份代码的多个实例
实例：一个服务中的每个运行实体- 实例与进程的关系：没有必然对应关系，一般一对一或者一对多
集群：服务内部的逻辑划分，包含多个实例 常见的实例承载形式：进程、VM、k8s pod......有状态 / 无状态服务：服务的实例是否存储了可持久化的数据
服务间通信
- 微服务之间通过网络进行通信
- 常见的通信协议包括 HTTP、RPC
服务注册及服务发现
- 基本问题：服务间调用中，如何指定下游服务实例的地址？
- 方案一：直接指定
ip:port？- 没有任何动态能力
- 有多个实例下游实例怎么办？
- 方案二：使用
DNS域名解析？- 本地 DNS 存在缓存，导致延迟
- DNS没有负载均衡，一般会返回第一个
- 不支持服务探活检查
- DNS 不能指定端口
- 方案三：
服务注册发现- 新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系
- 旧服务实例下线前，从服务注册中心删除该实例，下线流量（注意先后顺序）
- 新服务实例上线后，在服务注册中心注册该实例，上线流量（注册还要健康检查）
- 微服务
流量特征- 统一网关入口
- 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
服务治理功能
服务发布
- 何为服务发布：让一个服务升级运行新的代码的过程，在线服务
- 服务发布难点
- 服务不可用
- 服务抖动
- 服务回滚：升级的新代码有问题，则回滚到老版本代码
蓝绿部署- 将服务分成两个逻辑集群，分别先后发布
- 简单、稳定
- 但需要两倍资源：一般选择在低峰期发布
灰度发布（金丝雀发布）- 先发布少部分实例，接着逐步增加发布比例
- 不需要增加资源
- 回滚难度大，基础设施要求高，需要强大的平台支持eg：k8s
流量治理
- 流量控制：在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制实现分流
- 控制维度：地区维度、集群维度、实例维度、请求维度
负载均衡
- 常见的
LoadBalancd策略：Round Robin（绝对均衡）、Random（随机）、Ring Hash（一次性哈希，某个特定的用户需要特殊处理等）、Least Request
稳定性治理
未知挑战：网络攻击、流量突增、断电、光纤被挖、机器故障、网络故障、机房空调等等
限流：限制服务处理的最大 QPS，拒绝过多请求熔断：中断请求路径，增加冷却时间从而让故障实例尝试恢复过载保护：在负载高的实例中，主动拒绝一部分请求，防止实例被打挂降级：服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求
字节服务治理实践
请求重试的意义
- 本地函数调用：通常没有重试意义
- 远程函数调用
- 网络抖动、下游负载高、下游机器宕机......
- 重试是有意义的，可以避免偶发性的错误，提高 SLA
- 重试的意义
- 降低错误率
- 降低长尾延时：对于偶尔耗时较长的请求，重试有机会提前返回
- 容忍暂时性错误
- 避开下游故障实例：某个实例挂了，重试其他下游实例
请求重试的难点
- 幂等性：POST 请求可以重试吗？
- 重试风暴：随着调用链路的增加，重试次数呈指数级上升
- 超时设置：假设调用时间一共1s，经过多少时间开始重试？没有一个通用的值设置
重试策略
限制重试比例- 设定一个重试比例阈值（例如 1%），重试次数占所有请求比例不超过该阈值
- ** 只有在大部分都会成功的情况下才会重试**
防止链路重试（重试风暴）：- 返回特殊的** status code，表示“请求失败，但别重试”**
- eg：上图中服务A、B没有重试的必要，仅在C重试即可
- 只要自己发生了重试，就认为自己是最下游，向上游发送特殊的status，不用继续重试了
Hedged Requests（对冲请求，用于延迟较高容易失败的情况）- 对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应
重试效果验证- 字节跳动重试组件能够极大限制重试发生的链路放大效应
- 字节跳动重试组件能够极大限制重试发生的链路放大效应
