这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天
微服务框架-不变的基建 | 青训营笔记
1. 微服务架构介绍
1.1 系统架构演变历史
- 单体架构：all in a process
- 优势：性能高、冗余小
- 劣势：debug困难、模块互相影响、模块分工及开发流程比较困难
- 垂直应用架构：按照业务线垂直划分
- 优势：业务独立开发维护
- 劣势：不同业务存在冗余、每个业务还是单体
- 分布式架构：抽出业务无关的公共模块
- 优势：业务无关的独立服务
- 劣势：服务模块debug可导致全站瘫痪、调用关系复杂、不同服务冗余
- SOA架构：面向服务
- 优势：服务注册
- 劣势：整个系统设计是中心化的、需要从上至下设计、重构困难
- 微服务架构：彻底的服务化
- 优势：开发效率高、业务独立设计、自下而上设计、故障隔离
- 劣势：治理及运维难度大、观测挑战、安全性挑战、分布式系统
1.2 微服务架构核心要素
- 服务治理：服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理······
- 可观测性：日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪······
- 安全性：身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击······
2. 微服务结构原理及特征
2.1 基本概念
- 服务：一组具有相同逻辑的运行实体
- 实例：一个服务中，每个运行实体即为一个实例
- 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程（反之不常见）
- 集群：通常指服务内部的逻辑划分，包含多个实例
- 常见的实例承载形式：进程、VM、K8s pod······
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据（例如：磁盘文件）
- 服务间通信：对于单体服务，不同模块通信只是简单的函数调用；对于微服务，服务间通信意味着网络传输
2.2 服务注册及发现
问题：代码层面，如何指定调用一个目标服务的地址？ 解决思路：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
2.3 流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
3. 核心服务治理功能
3.1 服务发布
- 服务发布，即让一个服务升级运行新的代码的过程。
- 服务发布的难点：
- 服务不可用
- 服务抖动
- 服务回滚
- 服务发布方式
- 蓝绿部署：简单、稳定，但需要两倍资源
- 灰度发布
3.2 流量治理
在微服务架构下，可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行控制
3.3 负载均衡
负载均衡负责分配请求在每个下游实例上的分布 常见的策略： - Round Robin - Random - Ring Hash - ······
3.4 稳定性治理
线上服务总是会出问题，这与程序的正确性无关，如网络攻击、流量突增（应对手段——限流、熔断、过载保护、降级）、机房断电、光纤被挖、机器故障、网络故障、机房空调故障
4. 字节跳动服务治理实践
4.1 重试的意义
- 重试可以避免掉偶发的错误，提高SLA（Service-Level Agreement），本地函数调用一般没有重试的必要，但远程函数调用有必要进行重试操作
- 降低长尾延时，对于偶尔耗时较长的请求，重试请求有机会提前返回
- 容忍暂时性错误，某些时候系统会有暂时性异常（如网络抖动），重试可以尽量规避
- 避开下游故障实例，一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功
4.2 重试的难点
- 幂等性
- 重试风暴
- 超时设置
4.3 重试的策略
- 限制重试比例：设定一个重试阈值，重试次数占所有请求比例不超过该阈值
- 防止链路重试：链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明“请求失败，但别重试”
- Hedged requests：对于可能超时的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应
