微服务架构 | 青训营笔记

88 阅读5分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天

系统架构的演进

单体架构

优势

  • 性能最高
  • 冗余小

劣势

  • debug困难
  • 模块相互影响 image.png

垂直应用架构

按照业务线垂直划分
优势

  • 业务独立开发维护

劣势

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

分布式架构

抽出业务无关的公共模块 优势

  • 业务无关的独立服务 劣势
  • 服务模块bug可导致全站瘫痪
  • 调用关系复杂
  • 不同服务冗余 image.png

SOA架构

面向服务 劣势

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

微服务架构

优势

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

劣势

  • 治理运维难度
  • 可观测性
  • 安全性
  • 分布式系统 image.png

微服务架构的核心要素

  • 服务治理
    • 服务注册
    • 服务发现
    • 负载均衡
    • 扩缩容
    • 流量治理
    • 稳定性治理
    • ...
  • 可观测性
    • 日志采集
    • 日志分析
    • 监控打点
    • 监控大盘
    • 异常报警
    • 链路追踪
    • ...
  • 安全
    • 身份验证
    • 认证授权
    • 访问令牌
    • 审计
    • 传输加密
    • 黑产攻击
    • ...

微服务架构的原理与特征

服务——一组具有相同逻辑的运行实体
实例——一个服务中,每个运行实体即为一个实例
实例与进程的关系——一个实例可以对应一个或多个进程
服务间通信

  • 对于单体服务来说,服务通信就是调用函数
  • 对于微服务来说,服务通信意味着网络传输

服务注册及发现

如何指定调用一个目标服务的地址(ip:port)

client = grpc.NewClient("10.42.175.11:80")

以上代码存在问题

  • 服务地址会变化,不能写死
  • 一个服务有多个实例,选择哪一个未知,不能写死

image.png
那么用dns如b.service.org可以解决吗

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

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

核心服务治理功能

服务发布

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

蓝绿部署

蓝色环境和绿色环境都运行着相同的应用版本V1,只有绿色环境对外提供服务。
开发了一个新版本V2,那么放到蓝色环境上进行反复的测试、修改、验证,确定达到上线标准后,利用负载均衡器/反向代理/路由等手段将对外服务切换为蓝色环境。
一段时间后,如果发生故障,那么迅速切换回绿色环境V1;如果运行没有异常,那么绿色环境更新版本到V2,版本再次一致

image.png

灰度发布

先启动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试
如果没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的A/B测试。
当确认新版本运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。

image.png

流量治理

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

image.png

负载均衡

(Load Balance)负责分配请求在每个下游实例上的分布

image.png

稳定性治理

限流

限制请求次数

image.png

熔断

调用方访问服务时通过断路器做代理进行访问,断路器会持续观察服务返回的成功、失败的状态,当失败超过设置的阈值时断路器打开,请求就不能真正地访问到服务了。

image.png

降级

服务压力剧增的时候根据当前的业务情况及流量对一些服务和⻚面有策略的降级,以此缓解服务器的压力,以保证核心任务的进行。同时保证部分甚至大部分任务客户能得到正确的响应。

image.png

字节跳动服务治理实践

重试

远程函数调用可能会有哪些异常?

  • 网络波动
  • 下游负载高导致超时
  • 下游机器宕机
  • 本地机器负载高,调度超时

重试

func RemoteFuncRetry() {
    for (...) {
        if err = RemoteFunc(); err == nil {
            return 
        }
    }
}

重试的意义

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

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