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

用户4955575447946
132 阅读5分钟
  • 这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天

1. 微服务架构介绍

1.1 系统架构演变历史

  1. 单体架构

    优势：

    1. 性能最高
    2. 冗余小

    劣势：

    1. debug 困难

  1. 模块相互影响

  2. 单个仓库的模块分工，依赖管理，开发流程

  3. 垂直应用架构

    按照业务线垂直划分

    优势：

    1. 业务独立开发维护

    劣势：

    1. 不同业务存在冗余，无法复用
    2. 每个业务还是单体

  4. 分布式架构

    抽出业务无关的公共模块

    优势：

    1. 业务无关的独立服务

    劣势：

    1. 一个模块服务有问题，可以导致整个系统崩溃
    2. 调用关系错综复杂
    3. 不同服务依然存在冗余

  5. SOA架构

    面向服务

    优势：

    1. 服务注册

    劣势：

    1. 整个系统从设计上依然是中心化的
    2. 需要从上至下 去设计划分
    3. 重构困难

  6. 微服务架构

    彻底的服务化

    优势：

    1. 高效的开发迭代效率
    2. 故障可控

    劣势：

    1. 治理、运维难度急剧增加
    2. 观测挑战
    3. 安全等问题
    4. 分布式系统本身的复杂性

1.2 微服务架构核心要素

  1. 服务治理

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

  2. 可观测性

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

  3. 安全

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

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

2.1 基本概念

  • 服务(service)

    一组具有相同逻辑的运行实体

  • 实例(instance)

    一个服务中，每个运行实体即为一个实例

  • 实例与进程的关系

    实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程（反之不常见）

  • 集群(cluster)

    通常指服务内部的逻辑划分，包含多个实例

  • 常见的实例承载形式

    进程、VM、k8s pod ...

  • 有状态/无状态服务

    服务的实例是否存储了可持久化的数据（例如磁盘文件）

  • 服务间通信

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

2.2 服务注册及发现

问题：

  • 对于网络通信功能（不管http还是rpc），我们知道是需要指定远程的ip port的。
  • 既然服务之间存在通信关系，在实际代码层面，我们怎么写通信地址？
  • hardcode的方式指定下游实例地址有什么问题？

hardcode：

  • 服务有多个实例，没法hardcode（记住一个服务的所有实例都是运行同一份代码）
  • 服务实例ip port本身是动态变化的

DNS：

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

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

2.3 流量特征

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

3. 核心服务治理功能

3.1 服务发布

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

服务发布的难点：

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

蓝绿部署：简单、稳定，但需要两倍资源

灰度发布（金丝雀发布）：回滚难度大，基础设施要求高

3.2 流量治理

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

3.3 负载均衡

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

常见的LB策略

  • Round Robin
  • Random
  • Ring Hash
  • Least Request

3.4 稳定性治理

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

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

微服务架构中典型的稳定性治理功能

  1. 限流
  2. 熔断
  3. 过载保护
  4. 降级

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

4.1 重试的意义

本地函数调用可能的异常：

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

远程函数调用可能的异常：

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

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

意义：

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

4.2 重试的难点

  • 幂等性：多次请求可能会造成数据不一致
  • 重试风暴：随着调用深度的增加，重试次数会指数级上涨（稍后分析）
  • 超时设置：假设一个调用正常是 1s 的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢？

4.3 重试策略

  • 限制重试的比例
  • 防止链路重试
  • Hedged requests
avatar
文章
阅读
粉丝