Go语言学习——架构初探｜ 青训营笔记

LongBob
124 阅读6分钟

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

一：架构定义解析

1：架构：又称软件架构

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

2：单机

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

  • 优点:
    • 简单
  • 问题:
    • C10K problem
    • 运维需要停服
image.png

3：单体、垂直应用/垂直切分

单体架构:分布式部署
垂直应用架构:按应用垂直切分的单体

  • 优点:
    • 水平扩容
    • 运维不需要停服
  • 问题:
    • 职责太多,开发效率不高
    • 爆炸半径大

image.png

4：SOA、微服务/水平切分

  • SOA(Service-Oriented Architecture)
    • ①将应用的不同功能单元抽象为服务
    • ②定义服务之间的通信标准
  • 微服务架构:SOA的去中心化演进方向

问题:

  • 数据一致性
    • 装货台共交付了多少蛋糕?
  • 高可用
    • 这么多师傅，如何合作?
  • 治理
    • 烤箱坏了，怎么容灾?
  • 解耦vs过微
    • 运维成本高了，值当么?

image.png

二：企业级后端架构剖析

1：云计算

云计算:是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石。

  • 基础:
    • 虚拟化技术–整租vs 合租
    • 编排方案–业主vs租赁平台
  • 架构:
    • laaS (lnfrastructure as a Service)
      • 买房子vs房屋租赁平台
    • PaaS (Platform as a Service)
      • 清包vs全包
    • Saas (Software as a Service)
      • 从零培训vs雇佣培训过的师傅
    • FaaS (Function as a Service)
      • 纯手工制作vs蛋糕机批量生产
image.png

2：云原生

云原生技术为组织(公司)在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。

image.png

（1）弹性计算资源

  • 弹性计算资源类型
    • 服务资源调度
      • 微服务:和面、雕花
      • 大服务:烤箱
    • 计算资源调度
      • 在线:热销榜单
      • 离线:热销榜单更新
    • 消息队列
      • 在线:削峰、解耦
      • 离线:大数据分析

（2）弹性存储资源

  • 弹性存储资源类型
    • 经典
      • 对象:宣传视频
      • 大数据:用户消费记录
    • 关系型数据库
      • 收银记录
    • 元数据
      • 服务发现:蛋糕店通讯录
    • NoSQL
      • KV:来个xx蛋糕

总结:将存储资源当成服务一样

（3）DevOps

Dev0ps是云原生时代软件交付的利器,贯穿整个软件开发周期。
结合自动化流程，提高软件开发、交付效率

image.png

（4）微服务架构

  • 通信标准:
    • HTTP (RESTful API)
    • RPC (Thrift, gRPC)
  • 微服务中间件RPC vs HTTP:
    • 性能
    • 服务治理
    • 协议可解释性

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

image.png

（5）服务网格

  • 服务网格(Service Mesh):
    • 微服务之间通讯的中间层
    • 高性能网络代理
    • 业务代码与治理解耦
  • 相比较于RPC/HTTP框架:
    • 异构系统治理统一化
    • 与业务进程解耦，生命周期易管理

image.png

3：云原生蛋糕店

  • 企业级蛋糕店架构:
    • 售卖
    • 蛋糕制作(肉松、慕斯)
    • 会员激励
    • 满意度分析
    • 研发新品
image.png

三：业内架构面临的挑战

1：挑战

  • 基础设施层面
    • 物理资源是有限的
      • 机器
      • 带宽
    • 资源利用率受制于部署服务
  • 用户层面
    • 网络通信开销较大
    • 网络抖动导致运维成本提高
    • 异构环境下，不同实例资源水位不均
image.png

2：离在线资源并池

  • 核心收益:

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

  • 解决思路:离在线资源并池

  • 在线业务的特点

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

  • 离线业务的特点

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

3：自动扩缩容

  • 核心收益:
    • 降低业务成本
  • 解决思路:自动扩缩容
    • 利用在线业务潮汐性自动扩缩容
image.png

4：微服务亲和性部署

  • 核心收益:
    • 降低业务成本
    • 提高服务可用性
  • 解决思路:微服务亲合性部署
    • 将满足亲合性条件的容器调度到一台宿主机
    • 微服务中间件与服务网格通过共享内存通信
    • 服务网格控制面实施灵活、动态的流量调度

image.png

5：流量治理

  • 核心收益:
    • 提高微服务调用容错性
    • 容灾
    • 进一步提高开发效率，Dev0ps发挥到极致
  • 解决思路:基于微服务中间件&服务网格的流量治理
    • 熔断、重试
    • 单元化
    • 复杂环境(功能、预览）的流量调度

6：CPU水位均衡

  • 核心收益:
    • 打平异构环境算力差异
    • 为自动扩缩容提供正向输入
  • 解决思路:CPU水位负载均衡
    • laaS
      • 提供资源探针
    • 服务网格
      • 动态负载均衡

image.png

四：后端架构实战

1：问题背景

  • 兰师傅蛋糕店也碰到了类似的问题:

    • 不同师傅干活的效率差距较大
    • 有些师傅希望『能者多劳多挣』

  • 在这个背景下，继续像之前一样为每个师傅分配完全相同的工作，会引起他们的不满。。。

  • 回到03最后的挑战——CPU水位负载均衡，应该如何设计

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

2：问题提炼

  • 输入：
    • 服务网格数据面
      • 支持带权重的负载均衡策略
    • 注册中心存储了所有容器的权重信息
    • 宿主机能提供
      • 容器的资源使用情况
      • 物理资源信息(如CPU型号)
  • 关键点：
    • 紧急回滚能力
    • 大规模
    • 极端场景

image.png

3：自适应静态权重

  • 方案:
    • 采集宿主机物理资源信息
    • 调整容器注册的权重
  • 优势:
    • 复杂度低
    • 完全分布式,可用性高
    • 微服务中间件无适配成本
  • 缺点:
    • 无紧急回滚能力
    • 缺乏运行时自适应能力

image.png

4：自适应动态权重 AIpha

  • 方案:
    • 容器动态权重的自适应调整
    • 服务网格的服务发现&流量调度能力
  • 演进方向:
    • 解决无法紧急回滚的问题
    • 运行时权重自适应
  • 缺点:
    • 过度流量倾斜可能会有异常情况

image.png

5：自适应动态权重 Beta

  • 方案:
    • 服务网格上报 RPC指标
  • 演进方向:
    • 极端场景的处理成为可能
  • 缺点:
    • 时序数据库压力较大
    • 动态权重决策中心职责越来越多，迭代→>变更-〉风险

image.png

6：自适应动态权重 Release

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

image.png

avatar
文章
阅读
粉丝