微服务框架 - 不变的基建｜ 青训营笔记

Gerrad
82 阅读7分钟

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

笔记内容来自掘金字节内部课：微服务架构原理及特征, 核心服务治理功能, 字节跳动服务治理实践

一、本堂课重点内容：

  • 微服务架构介绍：微服务架构的背景由来、架构概览、基本要素
  • 微服务架构原理及特征：微服务架构的基本组件、工作原理、流量特征
  • 核心服务治理功能：核心的服务治理功能，包括流量治理、服务均衡、稳定性治理
  • 字节跳动服务治理实践：字节跳动在微服务架构稳定性治理中，对请求重试策略的探索及实践

二、详细知识点介绍：

1. 微服务架构介绍

1.1 系统架构演变历史

单体架构 all in one process

  • 优势:
    • 性能最高
    • 冗余小
  • 劣势:
    • debug困难
    • 模块相互影响
    • 模块分工、开发流程

垂直应用架构，按照业务线垂直划分

  • 优势：业务独立开发维护
  • 劣势：1.不同业务存在冗余；2.每个业务还是单体

分布式架构：抽出业务无关的公共模块

  • 优势：1.业务无关的独立服务
  • 劣势：1.服务模块bug可导致全站瘫痪；2.调用关系复杂；3.不同服务冗余

SOA架构（Service Oriented Architecture）：面向服务（增加了服务注册中心）

  • 优势:1.服务注册
  • 劣势:1.整个系统设计是中心化的；2.需要从上至下设计；3.重构困难

微服务架构——彻底的服务化

  • 优势:1.开发效率2.业务独立设计3.自下而上4.故障隔离（服务拆分得很细）
  • 劣势（作为一个分布式系统）:1.治理、运维难度；2.观测挑战；3.安全性；4.分布式系统

1.2 微服务架构概览

image.png

1.3 微服务架构核心要素

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

2. 微服务架构原理及特征

2.1 基本概念

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

image.png

如果把HDFS看作一组微服务

服务间通信

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

2.2 服务注册及发现

问题：在代码层面，如何指定调用一个目标服务的地址(ip:port) ?

hardcode?

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

// 地址固定了；只指定了一个实例

DNS?

  • 本地DNS存在缓存，导致延时。
  • 负载均衡问题（虽然对应了多个地址，但是还会去先找第一个）。
  • 不支持服务实例的探活检查（不存在的ip也可以配置上去）。
  • 域名无法配置端口（受端口数量上限限制）。

问题：在代码层面，如何指定调用一个目标服务的地址(ip:port) ?

解决思路：新增一个统一的服务注册中心,用于存储服务名到服务实例的映射（解决了DNS没有端口的问题；用random调用——最简单的负载均衡）。

服务实例上线及下线过程：

  • 新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系
  • 旧服务实例下线前，从服务注册中心删除该实例，下线流量
  • 新服务实例上线后，在服务注册中心注册该实例，上线流量

2.3 流量特征

  • 统一网关入口
  • 外网通信多数采用 HTTP（文本协议运行效率差），内网通信多数采用 RPC（二进制协议，效率高）（Thrift, gRPC）
  • 网状调用链路

image.png

3. 核心服务治理功能

3.1 服务发布

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

服务发布的难点：

image.png

解决方案：

  • 蓝绿部署

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

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

    • 先发布少部分实例，接着逐步增加发布比例
    • 不需要增加资源
    • 以实例为单位不停切换流量
    • 回滚难度大，基础设施要求高（f8s提供了这种能力——精细化回滚）

3.2 流量治理

在微服务架构中，我们可以基于地区、集群、实例（eg.机器不同）、请求（eg.内部用户测试，特殊用户单独测试）等维度，对端到端的流量在链路上进行精确控制

image.png

3.3 负载均衡

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

常见的LB策略：

  • Round Robin（绝对公平）
  • Random
  • Ring Hash（一致性哈希，跟请求有特定的关系）
  • Least Request

3.4 稳定性治理

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

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

稳定性治理功能：

image.png

4. 字节跳动服务治理实践

4.1 重试的意义

本地函数调用，可能有哪些异常?

  • 参数非法
  • OOM (Out Of Memory)
  • NPE (Null Pointer Exception)
  • 边界case
  • 系统崩溃
  • 死循环
  • 程序异常退出

但没有重试必要

远程函数调用，可能有哪些异常?

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

重试是有意义的，可以避免偶发性的错误，提高 SLA (Service-Level Agreement)

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

4.2 重试的难点

既然重试这么多好处,为什么默认不用呢?

  • 幂等性
    • POST 请求可以重试吗？
  • 重试风暴
    • 随着调用链路的增加，重试次数呈指数级上升

image.png

  • 超时设置
    • 假设调用时间一共1s，经过多少时间开始重试？

4.3 重试策略

  • 限制重试比例：设定一个重试比例阈值（时间窗口）（例如 1%），重试次数占所有请求比例不超过该阈值
  • 防止链路重试：链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。 返回特殊的 status code，表示“请求失败，但别重试”

image.png

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

image.png

4.4 重试效果验证

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

avatar
文章
阅读
粉丝