微服务架构学习笔记 | 青训营笔记

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

一、微服务架构介绍

1.1 系统架构演变历史：

单体架构

优势:

1. 性能最高

2. 冗余小

劣势:

1. debug困难
2. 模块相互影响
3. 模块分工、开发流程

垂直应用架构

按照业务线垂直划分

优势:

1. 业务独立开发维护

劣势

1. 不同业务存在冗余

2. 每个业务还是单体

分布式架构

抽出业务无关的公共模块

优势:

1. 业务无关的独立服务

劣势:

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

SOA架构

面向服务--由服务注册中心来解耦

优势

1. 服务注册

劣势:

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

微服务架构

彻底的服务化

优势:

1. 开发效率
2. 业务独立设计

3. 自下而上

4. 故障隔离

劣势:

1. 治理、运维难度
2. 观测挑战
3. 安全性
4. 分布式系统

1.2 核心要素

服务治理

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

可观测性

日志采集

日志分析

监控打点

监控大盘

异常报警

链路追踪--就好像报错会栈式地返回出错函数一样。因为在微服务中，一个函数的调用可能是一个链式地跨越几十台机器，因此我们需要该功能来追踪相应的错误。

安全

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

二、微服务架构原理及特征

2.1 核心概念

服务(service)

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

实例 ( instance)

• 一个服务中，每个运行实体即为一个实例（通俗来说一个服务就是运行同一个代码的多个实例）。

实例与进程的关系

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

集群(cluster)

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

常见的实例承载形式

• 进程、VM、k8s pod …

有状态/无状态服务

• 服务的实例是否存储了可持久化的数据(例如磁盘文件)。

服务间通信

• 对于单体服务，不同模块通信只是简单的函数调用。对于微服务，服务间通信意味着网络传输，例如：企业常用RPC|HTTP

2.2 服务注册及发现

由于一个服务里面有多个实例，因此如果仅仅是ip:port的形式调用服务，将无法知道具体调用哪个实例。

用DNS给不同实例区分解决可不可以？可以解决，但是优缺点

• 本地 DNS存在缓存，导致延时。

• 负载均衡问题。
• 不支持服务实例的探活检查。
• 域名无法配置端口。

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

2.3 流量特征

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

三、核心服务治理功能

3.1 服务发布

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

其有三大难点：

• 服务不可用

• 服务抖动---断掉某个服务的流量

• 服务回滚

解决：

• 蓝绿发布，分成两种，先升级一个颜色集群，将流量切到另一个颜色的集群。简单，稳定，但需要两倍资源。
• 灰度发布，上一个新实例，下一个旧实例，测试完成继续再上一个新实例...

3.2 流量治理

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

3.3 负载均衡

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

3.4 稳定性治理

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

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

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

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

四、字节跳动服务治理实践之重试

不同于本地调用函数，在微服务的调用过程中，是涉及到网络的，因此我们可以加入重试操作，以来减少因为网络导致出的错误。

4.1 重试的意义

降低错误率

• 假设单次请求的错误概率为0.01，那么连续两次错误概率则为0.0001。

降低长尾延时

• 对于偶尔耗时较长的请求,重试请求有机会提前返回。

容忍暂时性错误

• 某些时候系统会有暂时性异常（例如网络抖动)，重试可以尽量规避。

避开下游故障实例

• 一个服务中可能会有少量实例故障（例如机器故障)，重试其他实例可以成功。

4.2 重试的问题

幂等性--多次请求可能会造成数据不—致

超时设置--假设一个调用正常是1s的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢?

重试风暴---跟调用链路有关，随着调用深度的增加，重试次数会指数级上涨(稍后分析)

例如下图，当服务down时，即便限制重试次数为3

4.3 重试的策略

• 限制重试比例。设定一个重试比例阈值（例如1%)，重试次数占所有请求比例不超过该阈值。
• 防止链路重试。链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明“请求失败,但别重试”。
• Hedged requests。对于可能超时(或延时高)的请求，重新向另一个下游实例发送 一个相同的请求，并等待先到达的响应。