微服务架构与社会实践 | 青训营

已注销
99 阅读8分钟

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

微服务架构是当前大多数互联网公司的标准架构

课程内容

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

01.微服务架构介绍

演进原因

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

1.1演变历史

image.png

单体架构

优势:

  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微服务架构概览

image.png

1.3微服务架构核心要素

服务治理

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

可观测性

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

安全

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

1.4总结

  1. 系统架构的演变历史
  2. 微服务架构的整体概览
  3. 微服务架构中的核心要素

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

2.1基本概念

  • 服务

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

  • 实例

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

  • 实例与进程的关系

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

  • 集群(cluster)

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

  • 常见的实例承载形式

进程、VM、k8s pod...

  • 有状态/无状态服务

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

2.1基本概念

服务间通信

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

image.png

2.2服务注册及发现

在代码层面指定调用一个目标服务的地址？ DNS问题：

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

解决思路:新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。 （类似哈希表、map）

2.3流量特征

  1. 统一网关入口
  2. 内网通信多数采用RPC
  3. 网状调用链路

2.4总结

  • 微服务架构中的基本组件及术语
  • 服务注册及发现
  • 无损的服务实例上下线流程
  • 微服务架构中的基本流量特征

03.核心服务治理功能

3.1服务发布

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

服务发布的难点

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

蓝绿部署

image.png蓝绿分别进行，先把流量全部切到蓝色、暂停绿色，这样即使绿色故障也不会影响系统，然后反过来同样的升级绿色、暂停蓝色。

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

灰度发布（金丝雀发布）

在实例服务中放入新的实例，检查；然后去掉其中一个老的实例，检查；再加入一个新实例，检查；然后又去掉其中一个老实例，检查......

  1. 不停修改注册表
  2. 回滚困难

3.2流量治理

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

image.png

  • 请求进来后，会有API gateway service，在各个地区都有机器，例如在北京有四台、上海有三台，按理说机器多一些分配的流量也会多一些。
  • A服务有比较稳定的线上集群，会有较多的机器，为了更好的用户体验，会设置少量test cluster（可能不稳定，有bug），得到少量流量进行测试。
  • B服务根据机器分配，线上可能会有几千几万台机器，并非所有机器都是最新版本，老旧机器的性能肯定不如新机器，期望老旧机器所分配流量少一些，处理事务少一些。
  • C服务根据请求分配，有稳定线上集群，开发者有一个测试功能，另起一个集群，只含有一个实例，仅用于测试。

3.3负载均衡

负责分配请求在每个上下游实例上的分布。

常见的LB策略

  1. Round Robin：绝对公平
  2. Random
  3. Ring Hash
  4. Least Request

3.4稳定性治理

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

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

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

  1. 限流

image.png2. 熔断

image.png3. 过载保护

image.png4. 降级

image.png

3.5总结

  • 服务发布：蓝绿部署、灰度发布
  • 基于地区、集群、实例、请求等维度的流量治理功能
  • 几种常见的负载均衡策略
  • 微服务架构中的稳定性治理功能

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

4.1重试的意义

本地函数测试可能存在的异常（没有重试的必要）

  1. 参数非法
  2. OOM (Out Of Memory)
  3. NPE (Null Pointer Exception)
  4. 边界 case
  5. 系统崩溃
  6. 死循环
  7. 程序异常退出

远程函数调用可能存在的异常（有重试意义）

  1. 网络抖动
  2. 下游负载高导致超时
  3. 下游机器宕机
  4. 本地机器负载高,调度超时
  5. 下游熔断、限流

  • 降低错误率

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

  • 降低长尾延时

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

  • 容忍暂时性错误

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

  • 避开下游故障实例

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

4.2重试的难点

  1. 幂等性
  2. 重试风暴（雪崩）

image.png微服务的调用链路很深。服务D已经下线，不能处理请求。服务A无脑重试三次，A的每个请求到B后，而B也是无脑重试三次，B处就会堵塞，B的每个请求在C处都会有3次无脑重试，因此十分繁琐以至于可能正常的流程也会导致故障。 3. 超时设置

4.3重试策略

  1. 限制重试比例

设定一个重试比例阈值（例如1%），重试次数占所有请求比例不超过该阈值。即大部分成功情况下才有意义重试。

  1. 防止链路重试

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

  1. Hedged requests

对于可能超时(或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。 4.4重试效果验证 实际验证经过上述重试策略后，在链路上发生的重试放大效应。

image.png

4.5总结

  • 重试的意义及难点
  • 应对重试风暴的策略

首先对微服务架构的背景、由来进行了介绍，然后对架构基本原理与特征进行讲解，在这之后就可以基础判断一个架构如何调成微服务架构，以及它的基本工作流程。了解了核心服务治理功能，服务的发布与流量控制，以及针对稳定性优化做的组件，最后以重试为例介绍了字节跳动服务实践，以及重试的一些策略与解决方法。

avatar
文章
阅读
粉丝