微服务架构原理与治理实践

本文主要从微服务架构介绍、微服务架构原理及特征、核心服务治理功能、字节跳动服务治理实践四个方面总结。

1 微服务架构介绍

1.1 背景介绍

微服务架构是当前大多数互联网公司的标准架构。

为什么系统架构需要演进?

• 互联网的爆炸性发展
• 硬件设施的快速发展
• 需求复杂性的多样化
• 开发人员的急剧增加
• 计算机理论及技术的发展

系统架构演变历史：

• 单体架构（All in one process）

优势: 1. 性能最高。2. 冗余小。

劣势: 1. debug 困难。2. 模块相互影响。3. 模块分工、开发流程。

• 垂直应用架构（按照业务线垂直划分）

优势: 1. 业务独立开发维护。

劣势: 1. 不同业务存在冗余。2. 每个业务还是单体。

• 分布式架构（抽出与业务无关的公共模块）

优势: 1. 业务无关的独立服务。

劣势: 1. 服务模块bug可导致全站瘫痪。2. 调用关系复杂。3. 不同服务冗余。

• SOA架构（面向服务）

优势: 1. 服务注册。

劣势: 1. 整个系统设计是中心化的。2. 需要从上至下设计。3. 重构困难。

• 微服务架构（彻底的服务化）

优势: 1. 开发效率。2. 业务独立设计。3. 自下而上。4. 故障隔离。

劣势: 1. 治理、运维难度。2. 观测挑战。3. 安全性。4. 分布式系统。

1.2 微服务架构概览

1. 网关（连接用户终端）

• 用户服务（用户数据库）
• 商品服务（商品数据库）
• 订单服务（订单数据库）
• 广告服务（数据仓库和Redis）

2. 服务配置治理

• 服务配置
• 服务治理

3. 链路追踪和监控

• 服务监控
• 链路追踪

1.3 微服务架构核心要素

1. 服务治理

• 服务注册
• 服务发现
• 负载均衡
• 扩缩容
• 流量治理
• 稳定性治理等

2. 可观测性

• 日志采集
• 日志分析
• 监控打点
• 监控大盘
• 异常报警
• 链路追踪等

3. 安全

• 身份验证
• 认证授权
• 访问令牌
• 审计
• 传输加密
• 黑产攻击等

2 微服务架构原理及特征

2.1 基本概念

服务（service）：一组具有相同逻辑的运行实体，运行同一组代码逻辑的。

实例（instance）：一个服务中，每个运行实体即为一个实例。

实例与进程的关系：实例与进程之间没有必然对应关系，可以一个；实例可以对应一个或多个进程(反之不常见)

集群（cluster）：通常指服务内部的逻辑划分，包含多个实例。

常见的实例承载形式：进程、VM、k8s pod......

有状态/无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)。

服务间通信:

• 对于单体服务，不同模块通信只是简单的函数调用。
• 对于微服务，服务间通信意味着网络传输。

企业内部通常外网通信采用HTTP和内网通信采用RPC（Thrift，gRPC）用的比较广泛。

2.2 服务注册及发现

在代码层面，如何指定调用一个目标服务的地址（ip:port）？

1. hardcode

采用以下代码？

//Service A wants to call service B.
client:= grpc.NewClient(“10.23.45.67:8080”)

实际中，不太能指定一个固定的ip地址，在一个正式的微服务器环境里它是会动态变化的，一个服务里面有多个实例，指定一个实例行不通，代码是独一份，不能写定。

2. 域名（DNS）

一个域名可以注册多个ip

• 本地DNS存在缓存，导致延时。
• 负载均衡问题。
• 不支持服务实例的探活检查。
• 域名无法配置端口。

解决思路：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。

服务实例上线及下线过程 假如service A有instance三个，service B有service-1（10.23.45.67:8080）、instance-2 （10.45.67.89:8791）、instance-3（10.67.89.12:9007）两个服务里的instance彼此可以连接，管理员想要下线instance-3，下线之前先去服务注册中心把instance-3的记录删掉，过几秒之后，service A不会再去调用instance-3，因为会不断刷新服务的记录，这个时候再去删除instance-3是安全的，因为instance-3已经没有浏览了。如果要添加一个instance-4（10.89.12.34:8989），先把instance-4添加进去，进行health check，再把这个实例注册到服务注册中心（Service Registry）里面，然后流量就会恢复了。

2.3 流量特征

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

3 核心服务治理功能

服务发布(deployment), 即指让一个服务升级运行新的代码的过程。

服务发布的难点：

服务不可用 服务抖动（部分短暂不可用） 服务回滚（下一段代码出问题先回到上一段没问题的代码）

蓝绿部署：

• 将服务分成两个部分，分别先后发布
• 简单、稳定
• 但需要两倍资源

灰度发布（金丝雀发布）：

金丝雀(canary) 对瓦斯及其敏感，17世纪时，英国旷工在下井前会先放入一只金丝雀，以确保矿井中没有瓦斯。

• 先发布少部分实例，接着逐步增加发布比例
• 不需要增加资源
• 回滚难度大，基础设施要求高

3.2 流量治理

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

负载均衡(Load Balance)负责分配请求在每个下游实例上的分布。

常见的LB策略：

• Round Robin
• Random
• Ring Hash
• Least Request
• ......

3.3 稳定性治理

线上服务总是会出问题的，这与程序的正确性无关。

• 网络攻击
• 流量突增
• 机房断电
• 光纤被挖
• 机器故障
• 网络故障
• 机房空调故障
• ......

主要分为四点：

1. 限流

• 限制服务处理的最大 QPS，拒绝过多请求

2. 熔断

• 中断请求路径，增加冷却时间从而让故障实例尝试恢复

3. 过载保护

• 在负载高的实例中，主动拒绝一部分请求，防止实例被打挂

4. 降级

• 服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求

4 字节跳动服务治理实践

4.1 请求重试的意义

本地函数调用（golang）

func LocalFunc(x int) int {
    res := calculate(x * 2)
    return res
}

• 通常没有重试意义 可能有哪些异常？
• 参数非法
• O0M (Out Of Memory)
• NPE (Null Pointer Exception)
• 边界case
• 系统崩溃
• 死循环
• 程序异常退出等

远程函数调用（golang）

func RemoteFunc(ctx context. Context, x int) (int, error) {
    ctx2, defer_func := context.WithTimeout(ctx, time.Second)
    defer defer_func()
    
    res, err := grpc_client.Calculate(ctx2, x * 2)
    return res, err
}

• 网络抖动、下游负载高、下游机器宕机......
• 重试是有意义的，可以避免偶发性的错误，提高 SLA

可能有哪些异常？

• 网络抖动
• 下游负载高导致超时
• 下游机器宕机
• 本地机器负载高，调度超时
• 下游熔断、限流等

重试可以避免掉偶发的错误，提高SLA (Service-Level Agreement)。

总结来说如下：

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

4.2 重试的难点

1. 幂等性

2. 重试风暴 重试可能会导致雪崩。

假设service A会retry 3 times，到service B那会将A的每一次重试都retry 3 times，到service C那又会将B的每一次请求retry 3 times，最终到service D那里就重试了27次，很小的一个故障可能就会导致雪崩。

3. 超时设置

4.3 重试策略

1. 限制重试比例

设定一个重试比例阈值(例如1%)，重试次数占所有请求比例不超过该阈值。（在大部分都是成功的情况下才有必要重试） 2. 防止链路重试

• 链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。
• 可以返回特殊的status表明“请求失败，但别重试”。

3. Hedged requests

对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。

4.4 重试效果验证

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