微服务架构原理与治理实践｜青训营笔记

微服务架构介绍

架构概览

• 优势：
  1. 开发效率高、2. 业务独立设计、3. 自下而上、4. 故障隔离
• 劣势：
  1. 治理、运维难度高、2. 观测挑战、3. 安全性、4. 分布式系统的问题

核心要素

• 服务治理：
  1. 服务注册、2. 服务发现、3. 负载均衡、4. 扩缩容、5. 流量治理、6. 稳定性治理
• 可观测性：
  1. 日志采集、2. 日志分析、3. 监控打点、4. 监控大盘、5. 异常报警、6. 链路追踪
• 安全：
  1. 身份验证、2. 认证授权、3. 访问令牌、4. 审计、5. 传输加密、6. 黑客攻击

微服务架构原理及特征

服务间通信

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

服务注册及发现

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

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

服务的上下线流程（上面是下线流程、下面是上线流程）

流量特征

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

核心服务治理功能

服务发布

蓝绿发布：简单、但需要两倍资源（可以根据流量的错峰特性使用蓝绿发布）

金丝雀发布：过度平滑，但是在部署时进度在1%～99%时都有可能出现问题，需要回滚版本，这种维护能力需要平台级的设施提供支持。

流量治理

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

负载均衡

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

常见的LB策略：轮询、随机、一致性hash等。

稳定性治理

线上服务总是会出现故障：网络攻击、流量突增、机房断电、光纤问题、机器问题、网络问题......

下面给出了微服务治理中的四个经典功能：

字节跳动服务治理实践

针对于微服务架构中的请求重试机制字节给出了如下实践：

重试的意义

本地函数重试基本上是没有意义的，而远程函数重试则有意义，因为其发生请求错误的原因可能不是下游程序编写出错，而是因为：网络抖动、下游负载高导致超时、下游机器宕机、本地机器负载高、调度超时、下游熔断、限流等。

因此远程调用的重试可以：

• 降低错误率：单次错误概率为0.01，连续错误两次概率为0.0001
• 降低长尾延迟：对于偶尔耗时较长的请求，重试请求有机会提前返回
• 规避暂时性错误：网络抖动
• 避开下游故障实例：一个服务可能会有少量故障实例（如机器故障），重试可以将请求打到其他机器

重试的难点

重试本身并不默认开启，因为有一些难点需要克服：

• 幂等性：一些请求发起一次和多次结果会造成数据不一致情况（转账）
• 超时设置：不同项目需要结合自己的业务设置超时重试时间和频率
• 重试风暴：下游的重试次数会因为调用层数的深入而不断放大

重试策略

• 限制重试比例：设定一个重试比例阈值（例如1%），重试此处占所有请求比例不超过该阈值。

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

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

• 重试效果验证：