微服务架构原理与治理实践 | 青训营笔记

等待救赎的波
112 阅读5分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第11篇笔记

微服务架构介绍

系统架构演变历史

  • 为什么系统架构需要演进?
  • 互联网的爆炸性发展
  • 硬件设施的快速发展
  • 需求复杂性的多样化
  • 开发人员的急剧增加
  • 计算机理论及技术的发展

image.png

单体架构

all in one process

优势:

  1. 性能最高
  2. 冗全小 劣势:
  3. dabug困难
  4. 模块相互影响
  5. 模块分工、开发流程

image.png

垂直应用架构

按照业务线垂直划分

优势:

  1. 业务独立开发维护 劣势:
  2. 不同业务存在几余
  3. 每个业务还是单体

image.png

分布式架构

抽出业务无关的公共模块

优势:

  1. 业务无关的独立服务 劣势:
  2. 服务模块bug可导致全站瘫痪
  3. 调用关系复杂
  4. 不同服务冗余

image.png

SOA架构(Service Oriented Architecture)

面向服务

优势:

  1. 服务注册 劣势:
  2. 整个系统设计是中心化的
  3. 需要从上至下设计
  4. 重构困难

image.png

微服务架构

彻底的服务化

优势:

  1. 开发效率
  2. 业务独立设计
  3. 自下而上
  4. 故障隔离 劣势:
  5. 治理、运维难度
  6. 观测挑战
  7. 安全性
  8. 分布式系统

image.png

微服务架构核心要素

image.png

总结

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

微服务架构原理及特征

基本概念

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

image.png

如果把HDFS看做一组微服务

image.png

  • 服务间通信 对于单体服务，不同模块通信只是简单的函数调用。

对于微服务，服务间通信意味着网络传输。

image.png

服务注册及发现

在代码层面，如何指定调用个目标服务的地址

DNS?

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

image.png

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

image.png

服务实例上线及下线过程

image.png

image.png

image.png

image.png

image.png

image.png

image.png

流量特征

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

image.png

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

核心服务治理功能

服务发布

服务发布的特点

image.png

蓝绿部署

image.png

image.png

image.png
简单，稳定 但需要两倍资源

image.png

灰度发布 (金丝雀发布)

金丝雀(canary) 对瓦斯及其敏感，17世纪时，英国旷工在下井前会先放入一只 金丝雀，以确保矿井中没有瓦斯。

image.png

image.png

流量治理

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

image.png

负载均衡

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

image.png

常见的LB策略
Round Robin
Random
Ring Hash
Least Request

稳定性治理

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

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

image.png

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

image.png

image.png

总结

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

字节跳动服务治理实践

重试的意义

本地函数调用

可能有哪些异常?

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

image.png

远程函数调用

可能有哪些异常?

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

image.png

降低错误率

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

重试的难点

image.png

重试风暴

image.png

重试策略

限制重试比例 设定一个重试比例阈值(例如1%)重试次数占所有请求比例不超过该阈值。

image.png

防止链路重试

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

image.png

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

image.png

重试效果验证

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

image.png

总结

  • 重试的意义及难点
  • 应对重试风暴的策略
avatar
文章
阅读
粉丝