微服务框架 | 青训营笔记

微服务架构介绍

1.1 系统架构演变历史

为什么系统架构需要演进

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

单体架构：all in one process

• 优势

  • 性能最高
  • 冗余小

• 劣势

  • debug困难
  • 模块相互影响
  • 模块分工、开发流程

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

• 优势

  • 业务独立开发维护

• 劣势

  • 不同业务存在冗余
  • 每个业务还是单体

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

• 优势

  • 业务无关的独立服务

• 劣势

  • 服务模块bug可导致全站瘫痪
  • 调用关系复杂
  • 不同服务冗余

SOA架构 (Service Oriented Architecture)：面向服务

• 优势

  • 服务注册

• 劣势

  • 整个系统设计是中心化的
  • 需要从上至下设计
  • 重构困难

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

优势

• 开发效率
• 业务独立设计
• 自下而上
• 故障隔离

劣势

• 治理、运维难度
• 观测挑战
• 安全性
• 分布式系统

1.2 微服务架构概览

1.3 微服务架构核心要素

服务治理、可观测性、安全

微服务架构原理及特征

2.1 基本概念

服务(service)：一组具有相同逻辑的运行实体

实例(instance)：一个服务中，每个运行实体即为一个实例

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

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

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

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

服务间通信

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

2.2 服务注册及发现

2.3 流量特征

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

核心服务治理功能

3.1 服务发布

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

服务发布的难点

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

蓝绿部署

• 简单，稳定，但需要两倍资源

灰度发布（金丝雀发布）

3.2 流量治理

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

3.3 负载均衡

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

常见的LB策略

• Round Robin
• Randon
• Ring Hash
• Least Request

3.4 稳定性治理

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

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

限流、熔断、过载保护、降级

字节跳动服务治理实践

4.1 重试的意义

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

降低错误率

降低长尾延时

容忍暂时性错误

避开下游故障实例

4.2 重试的难点

幂等性

重试风暴

超时设置

4.3 重试策略

限制重试比例

• 设定一个重试比例阈值（例如1%），重试次数占所有请求比例不超过该阈值

防止链路重试

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

Hedged requests

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

4.4 重试效果验证

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