软件架构初探-续 | 青训营笔记

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

本堂课主要内容是软件架构，本文接续上一篇文章，主要关于企业级后端架构的挑战和后端架构实战两部分内容，下面是我个人听课时的一些笔记。

个人笔记

企业级后端架构的挑战

• 基础设施层面的挑战

  • 物理资源是有限的，包括
    • 机器
    • 带宽
  • 资源利用率受制于部署服务

• 用户层面的挑战

  • 网络通信开销较大
  • 网络抖动导致运维成本提高
  • 异构环境下，不同实例资源水位不均

• 解决方案：

  离在线资源并池

  将业务分为离线业务和在线业务

  • 在线业务的特点：
    • IO密集型为主
    • 潮汐性、实时性
  • 离线业务的特点：
    • 计算密集型占多数
    • 非实时性

• 自动扩缩容：

  利用在线业务潮汐性自动扩缩容

  收益：降低业务成本

• 微服务亲和性部署：

  • 将满足亲合性条件的容器调度到一台宿主机

  • 微服务中间件与服务网格通过共享内存通信

  • 服务网格控制面实施灵活、动态的流调度

  收益：

  • 降低业务成本
  • 提高服务可用性

• 流量治理：基于微服务中间件和服务网格提供的治理能力

  • 熔断、重试：单词请求失败的场景
  • 单元化：不同种类的请求之前不会互相影响
  • 复杂环境的流量调度（如功能、预览）

  收益：

  • 提高微服务调用容错性
  • 提高微服务出现不可用等问题时的容灾表现
  • 进一步提高开发效率，将DevOps发挥到极致

• CPU水位负载均衡：

  • IaaS提供资源探针
  • 服务网格提供的动态负载均衡

  收益：

  • 打平异构环境算力差异
  • 为自动扩缩容提供正向输入

后端架构实战

问题简化到如何设计上述的CPU负载均衡？

我们需要的能力的三个关键点：

• 在负载均衡失效时的紧急回滚能力
• 可以应对大规模请求
• 可以处理极端场景

几种方案：

• 自适应静态权重

  采集宿主机物力资源信息，调整容器注册时的权重（相当于在注册时根据宿主机物理信息提前把权重写死）

  优点是复杂度低，可用性高，且微服务中间件无适配成本

  缺点是无紧急回滚能力，且缺乏运行时的自适应能力

• 自适应动态权重Alpha

  容器动态权重可以基于服务网格的服务发现和流量调度能力进行自适应调整，解决了运行时权重自适应的问题，且设置动态权重决策中心并在其中保存了静态权重，使得架构支持在负载均衡失效时进行紧急回滚（回滚到静态权重的值）

  缺点是过度流量倾斜时可能会有异常情况

• 自适应动态权重Beta

  比Alpha方案多出来的一点是，需要服务网格上报RPC指标，如每个实例的请求处理延迟等

  这使得对于极端场景的处理成为可能

  缺点是需要使用数据库保存RPC指标的时序信息，增大了时序数据库的压力，且动态权重决策中心职责过于繁重

• 自适应动态权重Release

  将动态权重决策中心微服务化

  对离线和在线链路进行切分

  通过一致性哈希解决在线分析引擎的数据一致性问题

  将时序数据库作为旁路工具，采用纯内存的在线分析引擎进行实时策略计算，从而降低其压力

  对离线分析引入消息队列进行解耦、削峰

“没有最好的架构，只有最合适的架构”

参考

• 字节内部课 —【后端入门 - 开发与迭代】