微服务架构原理与治理实践

Cool
128 阅读5分钟

课程背景

为什么有这门课程

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

我看也学到什么？

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

我可以学到什么？

  • 微服务架构的由来及原理
  • 服务治理功能是如何工作的

微服务架构介绍

系统架构演变历史

为什么系统架构需要演进？

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

image-20220529150211423.png

单体架构

all in one process

优势：

  • 性能最高
  • 冗余小

劣势：

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

image-20220529150538729.png

垂直应用架构

按照业务线垂直划分

优势：

  • 业务独立开发维护

劣势：

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

image-20220529150656557.png

分布式架构

抽出业务无关的公共模块

优势：

  • 业务无关的独立服务

劣势：

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

image-20220529151000813.png

SOA (Service Oriented Architecture)

面向服务

优势：

  • 服务注册

劣势：

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

image-20220529151314036.png

微服务架构

彻底的服务化

优势：

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

劣势：

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

image-20220529151449736.png

微服务架构概览

image-20220529151633039.png

微服务架构核心要素

服务治理：

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

可观察性：

  • 日志采集
  • 日志分析
  • 监控打点
  • 监控大盘
  • ......

安全：

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

微服务架构原理及特征

基本概念

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

image-20220529152928949.png

如果把 HDFS 看做一组微服务

image-20220529153023268.png

服务间通信

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

image-20220529153229625.png

服务注册及发现

问题

在代码层面，如何指定调用一个目标服务的地址（ip:port）？hardcode？

// ServiceA wants to call serviceB
client := grpc.NewClient("10.23.45.67:8080")

image-20220529153516634.png

在代码层面，如何指定调用一个目标服务的地址（ip:port）? DNS?

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

image-20220529153516634.png

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

image-20220529154127813.png

服务实例上线及下线过程

image-20220529154211000.png

image-20220529154234527.png

image-20220529154249582.png

image-20220529154316114.png

image-20220529154330740.png

image-20220529154406014.png

image-20220529154444163.png

流量特征

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

image-20220529154749218.png

核心服务治理功能

服务发布

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

服务发布的难点

image-20220529175535940.png

蓝绿发布

image-20220529175608841.png

image-20220529175624662.png

image-20220529175651599.png

image-20220529175716949.png

image-20220529175734567.png

image-20220529175754351.png

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

灰度发布（金丝雀发布）

image-20220529175847986.png

image-20220529175923415.png

流量治理

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

image-20220529180048373.png

负载均衡

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

常见的 LB 策略：

  • Round Robin
  • Random
  • Ring Hash
  • Least Request
  • ....

image-20220529180228658.png

稳定性治理

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

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

微服务架构中电信的稳定性治理功能

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

image-20220529180537964.png

字节跳动服务治理实践

重试的意义

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

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

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

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

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

image-20220529180935644.png

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

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

重试的难点

  • 幂等性
  • 重试风暴
  • 超时设置

重试风暴

image-20220529181416867.png

重试策略

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

image-20220529181513101.png

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

image-20220529181724627.png

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

image-20220529181846178.png

重试策略效果验证

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

image-20220529182047066.png

avatar
文章
阅读
粉丝