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

115 阅读5分钟

微服务架构介绍

系统机构需要演进的原因:

  1. 互联网的爆炸性发展
  2. 硬件设施的快速发展
  3. 需求复杂性的多样化
  4. 开发人员的急剧增加
  5. 计算机理论及技术的发展

单体架构(all in one process)

  • 优势:性能最高,冗余小
  • 劣势:debug困难,模块相互影响(非核心功能可能导致程序崩溃),模块分工、开发流程困难

垂直应用架构——按照业务线垂直划分

  • 优势:业务独立开发维护
  • 劣势:不同业务存在冗余,每个业务还是单体架构

分布式架构——抽出业务无关的公共模块

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

  • 劣势:服务模块bug可能导致全站瘫痪;调用关系复杂;不同服务冗余

SOA架构——面向服务(Service Oriented Architecture)

  • 优势:服务注册

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

微服务架构——彻底的服务化

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

  • 劣势:治理、运维难度急剧增加;观测挑战;安全性;分布式系统

微服务架构的核心要素

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

微服务架构原理及特征

基本概念

  • 服务 service:一组具有相同逻辑的运行实体

  • 实例 instance:一个服务中,每个运行实体即为一个实例

  • 实例与进程的关系:实例与进程之间没有必然的对应关系,可以一个实例对应一个或多个进程(反之不常见)

  • 集群 cluster:通常指服务内部的逻辑划分,包含多个实例

  • 常见的实例承载形式:进程,VM,k8s pod

  • 有状态/无状态服务:服务的实例是否存储了可持久化的数据(如磁盘文件)

  • 服务间通信

    • 对于单体服务,不同模块通信知识简单的函数调用

    • 对于微服务,服务间的通信意味着网络传输

服务注册及发现

  • 在代码层面,如何制定调用一个目标服务的地址(ip:port)

    // Service A wants to call service B
    client := grapc.NewClient("10.23.45.67:8080")
    
    • 存在的问题:很难指定一个固定的地址;有多个实例时指定一个实例肯定会出问题;服务的地址是会变动的

    • DNS?

      • 本地DNS存在缓存,导致厌食
      • 负载均衡问题
      • 不支持服务实例的探活检查
      • 域名无法配置端口
    • 解决思路:新增一个统一的微服务注册中心,用于存储服务名到服务实例的映射

流量特征

  • 统一网管入口

  • 内网通信多采用RPC

  • 网状调用链路

核心服务治理功能

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

  • 服务发布的难点

    • 服务不可用
    • 服务抖动
    • 服务回滚
  • 蓝绿部署——简单稳定,但需要两倍资源

  • 灰度/滚动发布(金丝雀发布):不断增加实例

流量治理

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

负载均衡

  • 负载均衡(Load balance):负责分配请求在每个下游实例上的分布
  • 常见的LB策略:Round Robin, Random, Ring Hash, Least Request

稳定性治理

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

字节服务治理实践

重试的意义

  • 本地函数调用——可能存在的异常:参数非法,OOM(out of memory),NPE(Null Pointer Exception),边界case,系统崩溃,死循环,程序异常退出——没有重试的必要

  • 远程函数调用——可能存在的异常:网页抖动,下游负载高导致超时,下游机器宕机,本地机器负载高,调度超时,下游熔断,限流

  • 重试可以避免偶发的错误,提高SLA(Service-Level Agreement)

    • 降低错误率 (0.01 ^ 2 = 0.0001)
    • 降低长尾延时:对于偶尔耗时较长的请求,重试请求有机会提前返回
    • 容忍暂时性错误:某些时候系统会有暂时性的异常(如网络抖动),重试可以尽量规避
    • 避开下游故障实例:一个服务中可能会有少量实例故障(机器故障),重试其他实例可以成功
  • 为什么默认不用重试

    • 幂等性

    • 重试风暴

      重试策略

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

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

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

      • 重试效果验证

    • 超时设置