后端框架引入与实战 | 青训营笔记

love98
81 阅读5分钟

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

什么是架构

定义

架构是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计

单机

软件系统需要具备对外提供服务，单机，就是把所有功能实现在一个进程里，并部署在一台机器上

  • 优点

    • 简单

  • 问题

    • C10K Problem：承载瓶颈
    • 运维需要停服

单体、垂直应用|垂直切分

解决了单机的承载瓶颈问题

单体架构

分布式部署

优点：

  • 水平扩容
  • 运维不需要停服

问题：

  • 职责太多，开发效率不高

垂直应用架构

按应用垂直切分的单体

问题：

  • 爆炸半径大

SOA、微服务|水平切分

SOA(Service-Oriented Architecture)

  1. 将应用的不同功能单元抽象为服务
  2. 定义服务之间的通信标准

微服务框架可以理解成 SOA 的去中心化演进方向

问题

  • 数据的一致性

  • 高可用

    • 不同服务如何合作

  • 治理

    • 如何容灾

  • 解耦 / 过微

    • 运维成本变高

企业级后端框架

企业级后端架构剖析

云计算

云计算是指通过软件自动化管理，提供计算资源的服务网络

基础

  • 虚拟化技术
  • 产品编排方案

框架

  • IaaS (Infrastructure as a Service)

    • 买房子 vs 房屋租赁平台

  • Paas (Platform as a Service)

    • 清包 vs 全包

  • Saas (Software as a Service)

    • 自己配置 vs 开箱即用

  • FaaS (Function as a Service)

    • 手撸 API vs 别人的 API

云原生（Cloud Native）

包括

  • 弹性资源

    • 虚拟化容器
    • 快速扩缩容

  • 微服务框架

    • 业务单元解耦
    • 统一的通信标准

  • 服务网络

    • 业务与治理的解耦
    • 异构架构的治理统一化
    • 复杂治理能力

  • DevOps

    • 敏捷开发
    • CI / CD
弹性资源

  • 服务资源

  • 计算资源

  • 消息队列

  • 存储资源

    • 将存储资源当作服务
DevOps

图片源自：

orangematter.solarwinds.com/2022/03/21/…

结合自动化流程，提高软件开发、交付效率

微服务架构
通信标准
  • HTTP (RESTful API)
  • RPC (Thrift gRPC)
微服务中间件

一般情况下使用的是 RPC

对比 HTTP 优势：

  • 性能更好
  • 服务治理
  • 协议可解释性

云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架

服务网格 (Service Mesh)

  • 微服务之间通讯的中间层
  • 高性能的网络代理
  • 业务代码与治理解耦

相比于 RPC/HTTP 框架：

  • 异构架构治理统一化
  • 与业务进程解耦，生命周期容易管理

企业级后端框架的挑战

挑战

基础设施层面：

  • 物理资源有限

    • 机器数量有限
    • 网络带宽有限

  • 资源利用率受制于部署服务

用户层面：

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

离在线资源并池

在线业务特点

  • IO 密集型为主
  • 潮汐性、实时性

离线业务特点

  • 计算密集型占多数
  • 非实时性

核心收益

  • 降低物理资源成本
  • 提供更多的弹性资源，增加收入

on&offline_source.jpeg

自动扩缩容

auto_in&decrease.jpeg

微服务亲和性部署

  • 将满足亲和性条件的容器调度到一台宿主机
  • 微服务中间件与服务网格通过共享内存通信
  • 服务网格控制面实施灵活、动态的流量调度

8975c2b4-0c1b-46d3-981a-284bba63d567.jpg

流量治理

基于微服务中间件 & 服务网格

  • 熔断、重试
  • 单元化
  • 复杂环境（功能、预览）的流量调度

CPU 水位负载均衡

  • Iaas

    • 提供资源探针

  • 服务网格

    • 动态负载均衡

b3e7b317-4627-4b0c-aea8-f00f3203eebb.jpg

后端框架实战

CPU 水位负载均衡问题

分析

  • 需要哪些输入参数
  • 设计时需要考虑哪些关键点

提炼

输入

  • 服务网格数据面

    • 支持带权重的复杂均衡策略

  • 注册中心存储了所有容器的权重信息

  • 宿主机提供

    • 容器的资源使用情况
    • 物理资源信息（如 CPU 型号）

关键点

  • 紧急回滚能力
  • 大规模
  • 极端情况

解决：自适应静态权重

方案

  • 采集宿主机物理资源信息
  • 调整容器注册的权重

优势

  • 复杂度低
  • 完全分布式，可用性高
  • 微服务中间件无适配成本

缺点

  • 无紧急回滚能力
  • 缺乏运行时的自适应能力

解决：自适应动态权限 Alpha

方案

  • 容器动态权重的自适应调整
  • 服务网格的服务发现 & 流量调度能力

演进方向

  • 解决无法紧急回滚的问题
  • 运行时权重自适应

缺点

过度流量倾斜可能会有异常情况

Alpha.jpeg

解决：自适应动态权限 Beta

方案

  • 服务网格上报 RPC 指标

演进方向

  • 极端场景的处理成为可能

缺点

  • 时序数据库压力较大
  • 动态权重决策中心职责越来越多，迭代 -> 变更 -> 风险

Beta.jpeg

解决：自适应动态权限 Release

演进方向

  • 微服务化
  • 引入消息队列削峰、解耦
  • 离在线链路切分
  • 梳理强弱依赖

Release.jpeg

尾声

  1. 没有最好的架构，只有最合适的架构

  2. 如何做架构设计

    • 需求优先 -> 先弄清楚需要解决什么问题
    • 业界调研 -> 业界都有哪些解决方案可供参考
    • 技术选型 -> 内部 / 社区都有哪些基础组件
    • 异常情况 -> 考虑清楚 xxx 不行了怎么办
avatar
文章
阅读
粉丝