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

96 阅读5分钟

这是我参与第五届青训营笔记创作活动的第15天,今天的课程为微服务架构相关理论,从四个方面讲述了微服务架构的优点与应用,下面我总结一下今天学到的知识。

微服务框架介绍

微服务架构的背景由来、架构概览、基本要素

系统架构的演变历史:

单体架构->垂直应用架构->分布式架构->SOA架构->微服务架构

单体架构

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

垂直应用架构

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

分布式架构

优势:业务无关的独立服务

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

SOA架构

优势:服务注册

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

微服务架构

优势:1.开发效率 2.业务独立设计 3.自下而上 4.故障隔离

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

微服务架构概览

核心要素

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

可观测性:日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪...

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

微服务架构原理及特征

微服务架构的基本组件、工作原理、流量特征

基本概念

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

服务中通信

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

代码层面指定调用一个目标服务的地址(ip:port):

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

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

流量特征

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

核心服务治理功能

核心的服务治理功能,包括流量治理、服务均衡、稳定性治理

服务发布

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

难点

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

方案

蓝绿部署

简单,稳定,但需要两倍资源

灰度发布(金丝雀发布)

逐渐在用户群中更新

流量治理

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

负载均衡

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

常见LB(负载均衡)策略

  • Round Robin

  • Random

  • Ring Hash

  • Least Request

稳定性治理

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

外界因素:网络攻击、流量突增、机房断电、光纤被挖、机器故障、网络故障、机房空调故障...

微服务架构中典型的稳定性治理功能:限流、熔断、过载保护、降级

字节跳动服务治理实践

宁节跳动在微服务架构稳定性治理中,对请求重试策略的探索及实践

重试的意义

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

本地函数调用可能出现异常的常见情况:(无重试必要)

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

远程函数调用可能出现异常的常见情况:(有重试必要)

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

重试的难点

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

重试策略

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

重试效果验证

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