微服务框架 | 青训营笔记

这是我参与「第五届青训营」伴学笔记创作活动的第 9 天。

本节课内容主要分为4个方面：微服务架构介绍，包括微服务架构的背景由来、架构概览和基本要素；微服务架构原理及特征，包括微服务架构的基本组件、工作原理、流量特征；核心的服务治理功能，包括流量治理、服务均衡、稳定性治理；字节跳动服务治理实践；主要讲述了字节跳动在微服务架构稳定性治理中，对请求重试策略的探索及实践。

微服务架构介绍

系统架构演变历史

单体架构

单体架构通过分布式部署来对服务进行扩容。

垂直应用架构

竖直应用架构则更进一步，将服务进行竖直切分，让将一个服务切分成多个功能互不相干的服务，独立运行。

分布式架构

分布式架构进一步抽出与业务无关的公共模块，分布式独立部署运行。

SOA架构

SOA架构是面向服务的架构，以水平切分的思想，通过将一个应用之间有关联和无关联的功能都切分成一个个单独运行的服务，并通过某种通信标准（例如 HTTP, RPC）交换数据，最终构成一个完整的服务整体。

微服务架构

微服务架构则可以被近似的认为是 SOA 的一种去中心化方向，是一种彻底的服务化。

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API 进行通信的小型独立服务组成。 这些服务由各个小型独立团队负责。 微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。

微服务架构概览

• 网关

• 服务配置和治理

• 链路追踪和监控

微服务架构三大要素

• 服务治理（本课程内容）

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

• 可观测性

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

• 安全

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

微服务架构原理及特征

基本概念

• 服务 (service)：一组具有相同逻辑（运行同一段代码）的运行实体（实例）。
• 实例 (instance)：一个服务中，每个运行实体即为一个实例。
• 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程 (反之不常见) 。
• 集群(cluster)：通常指服务内部的逻辑划分，包含多个实例。
• 常见的实例承载形式：进程、VM、k8s pod......
• 有状态 / 无状态服务服务的实例：是否存储了可持久化的数据，例如磁盘文件。

微服务架构的出现和应用大幅度的提升了大型程序的开发效率，降低了程序故障率，但其复杂的架构设计也引来了治理、运维难度飙升，观测难度大，安全性较低等劣势。

如果把HDFS看做是一组微服务，那么NameNode是一个单实例服务，DataNode是另一个服务。

服务间通信：微服务之间通过网络进行通信，常见的通信协议包括 HTTP、RPC。

服务注册及发现

服务间调用中，如何指定下游服务实例的地址？

直接指定 ip:port？

如果我们通过硬编码的方式在服务 A 指定网络地址，灵活性低暂且不说，对于具有多个实例的服务 B，一个网络地址只能指定到同一个服务实例中，这会导致服务 A 的所有实例全部向服务 B 的单一实例进行网络请求，这明显是不符合我们负载均衡要求的。

• 没有任何动态能力
• 只能控制一个实例对象，有多个实例下游实例无法解决

使用 DNS？

这依然产生了问题，首先负载均衡问题仍未得到解决，其次本地 DNS 由于存在缓存，因此我们没办法做到服务更改的实时切换，亦无法支持服务实例得探活检查；最后，这种方式由于端口依然是写死在代码里的，我们依然没有办法自定义端口号。

• 本地 DNS 存在缓存，导致延迟
• DNS 没有负载均衡
• 不支持服务探活检查
• DNS 只能动态变化ip，不能指定端口（端口不变）

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

新增了一个统一的服务注册中心服务，用于存储服务名到服务实例的映射，需要进行跨服务网络请求的服务只需要向服务注册中心查询指定服务名便可得到该服务名包括的所有实例地址。

服务实例上下线过程：

• 旧服务实例下线前，从服务注册中心删除该实例，下线流量
• 新服务实例上线后，在服务注册中心注册该实例，上线流量

同时，所有服务实例自身还会进行健康检查以确定自己的服务始终可用，并以此决定自己是否可以继续提供服务。

微服务流量特征：

• 统一网关入口
• 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）

核心服务治理功能

服务发布

何为服务发布？

• 让一个服务升级运行新的代码的过程

服务发布难点：

对于一个大型的线上系统，我们不能像在学校里编写练习项目一样随时随刻终止项目、修改项目代码和重新运行项目，在项目发布的过程中会遇见以下几种问题：

• 服务不可用
• 服务抖动
• 服务回滚

解决方法：

• 蓝绿部署：将服务实例分成两个部分，分别先后发布，这样访问该服务的其他服务总是可以正常运行，因为始终有一部分服务实例时正常运作的。这种部署方法的优点是简单稳定，缺点是需要提供双倍的资源来保证服务稳定。

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

• 灰度发布（金丝雀发布）：先发布少部分实例，接着逐步增加发布比例。优点是不需要增加资源，缺点是回滚难度大，且对基础设施要求高。

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

流量治理

• 流量控制

  • 在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制

• 控制维度

  • 地区维度
  • 集群维度
  • 实例维度
  • 请求维度

负载均衡

有以下几种常用的负载均衡算法：

• Round Robin

• Random

• Ring Hash

• Least Request

稳定性治理

即使我们写的代码再完美、再适用，但在真实的运行环境中，还是可能遇到无法从程序角度解决的问题，例如硬件故障、网络攻击等。我们可以采取以下几种常用的稳定性治理方法：

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

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

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

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

字节跳动服务治理实践（重试）

重试的意义

本地函数调用通常没有重试意义，而对于远程函数调用，当面对网络抖动、下游负载高、下游机器宕机等问题时，重试是有意义的，可以避免偶发性的错误，提高 SLA (Service-Level Agreement)。

• 降低错误率
• 降低长尾延时
• 容忍暂时性错误
• 避开下游故障实例

重试的难点

• 幂等性：多次请求可能造成数据不一致；

• 重试风暴：随着调用链路的增加，重试次数呈指数级上升

• 超时设置：假设调用时间一共1s，经过多少时间开始重试？（不是故障）

重试策略

限制重试比例

• 设定一个重试比例阈值（例如 1%），重试次数占所有请求比例不超过该阈值，换句话说就是成功比例高，只有少数请求失败的调用，重试次数可以越多，而对于大多数请求都失败的调用，重试次数越多只会加剧问题。

防止链路重试

• 返回特殊的 status code，表示“请求失败，但别重试”，这样可以解决重试风暴的问题。

Hedged Requests

• 对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应，这是一种超时设置策略。

重试效果验证

字节跳动重试组件能够极大限制重试发生的链路放大效应