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

zeke
117 阅读5分钟

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

架构演变

单体架构

All in one process

优势

  • 性能最高
  • 冗余小

劣势

  • debug困难
  • 模块相互影响
  • 模块分工、依赖管理，开发流程捆绑

image.png

垂直应用架构

按照业务线垂直划分

优势

  • 业务独立开发维护

劣势

  • 不同业务存在冗余，无法复用
  • 每个业务依旧是单体

image.png

分布式架构

抽出与业务线无关的公共模块，分布式独立部署运行

优势

  • 业务无关的独立服务

劣势

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

SOA架构

面向服务的架构，开始引入“服务”，“服务注册”的概念

优势

  • 服务注册

劣势

  • 整个系统从设计上依然是中心化
  • 重构困难
  • 需要从上至下去进行设计和划分

image.png

微服务架构

彻底服务化

优势

  • 高效的开发迭代效率
  • 故障可控，故障隔离
  • 不同业务独立设计
  • 自下而上的设计

劣势

  • 治理、运维难度急剧增加
  • 观测挑战
  • 安全性问题
  • 分布式系统本身的复杂性

image.png

微服务架构核心要素

服务治理

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

可观测性

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

安全

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

微服务架构原理和特征

基本概念

  • 服务(service) 一组具有相同逻辑的运行实体。
  • 实例(instance) 一个服务中，每个运行实体即为一个实例。
  • 实例与进程的关系 实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程(反之不常见)。
  • 集群(cluster) 通常指服务内部的逻辑划分，包含多个实例。
  • 常见的实例承载形式 进程、VM、k8s pod ……
  • 有状态/无状态服务 服务的实例是否存储了可持久化的数据(例如磁盘文件)。
  • 服务间通信 对于单体服务，不同模块通信只是简单的函数调用。对于微服务，服务间通信意味着网络传输。服务内部一般使用rpc通信，服务外部一般适用http通信

image.png

服务注册和发现

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

  • 一般情况下，服务有多个实例，可以通过配置文件的方式写死客户端的ip和端口，但这种做法是不灵活的，因为目标服务实例的ip和端口是动态变化的

image.png

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

image.png

  • 新增一个统一的服务注册中心，用于存储服务名到服务实例的映射

image.png

流量特征

在流量方面，弱化连接的概念，强调“请求” 即同一个客户端长连接发出的请求，理论上可以到达服务中所有实例 API gateway 可以用作身份认证，进而将 token 附在请求上

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

image.png

微服务之服务治理功能

服务发布

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

难点

  • 服务不可用

image.png

  • 服务抖动

image.png

  • 服务回滚

image.png

蓝绿部署

蓝绿部署即将目标服务分成两个集群，分别更新，逐渐交替，这种部署方法简单且稳定，但需要两倍的资源

image.png

灰度发布（金丝雀发布）

一个实例一个实例逐渐更新，但回滚难度大，基础设施要求高

image.png

流量治理

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

image.png

负载均衡

负载均衡负责分配请求在每个下游实例上的分布，常见策略包括：

  • Round Robin
  • Random
  • Ring Hash
  • Least Request

image.png

稳定性

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

image.png

请求重试

重试意义

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

重试难点

  • 幂等性：多次请求可能会造成数据不一致
  • 重试风暴：随着调用深度的增加，重试次数会指数级上涨

image.png

  • 超时设置

重试策略

  • 限制重试比例 重试只有在大部分请求都成功，只有少量请求失败时，才有必要 如果大部分请求都失败，重试只会加剧问题严重性 因此，可以定义，比如重试次数不能超过正常成功请求次数的 1%（重试阈值），重试次数占所有请求比例不超过该阈值
  • 防止链路重试 链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试，可以返回特殊的status表明“请求失败，但别重试”。但存在对业务代码有侵入性的缺点

image.png

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

image.png

avatar
文章
阅读
粉丝