微服务 | 青训营笔记

55 阅读4分钟

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

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

从这节课中学习到微服务架构的原理、服务治理功能是如何工作的。

微服务架构介绍

系统架构演变历史

image.png

微服务架构概览

image.png

  • 优势: 高效的开发迭代效率故障可控
  • 缺点: 治理、运维难度急剧增加观测挑战 安全等问题 分布式系统本身的复杂性

微服务架构核心要素

image.png

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

微服务架构原理及特点

基本概念

image.png

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

服务间通信:

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

那么就有一个问题:在代码层,如何指定调用一个目标服务的地址(ip:port)?

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

image.png

核心服务治理功能

服务发布

服务发布:让一个服务升级运行新的代码的过程

服务发布的难点: 服务不可用、服务抖动、服务回滚 image.png

解决:蓝绿部署、灰度发布

流量治理

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

image.png

负载均衡

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

image.png

常见的负载均衡策略:
-Round Robin
-Random
-Ring Hash
-Least Request

稳定性治理

线上服务总是会出现问题,这与程序正确性无关:
网络攻击、流量突增、机房断电、光纤被挖、机器故障、网络故障。。。

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

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

image.png

字节跳动服务治理实践

重试的意义

本地函数调用和远程函数调用分别有哪些异常?

  • 本地

    • 参数非法
    • 参数非法
    • OOM (Out Of Memory)
    • NPE (Null Pointer Exception)
    • 边界case
    • 系统崩溃死循环
    • 程序异常退出
  • 远程

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

重试的意义:可以避免掉偶发的错误,提高SLA(Service-Leavel Agreement)

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

重试的难点

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

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

重试风暴:随着调用深度的增加,重试次数会指数级上涨

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

重试策略

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

image.png

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

image.png

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

image.png