架构初探 ｜ 青训营笔记

Chow617
98 阅读11分钟

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

一、本堂课重点内容

  • 什么是架构
  • 企业级后端架构剖析
  • 企业级后端架构的挑战
  • 后端架构实战

二、详细知识点介绍

什么是架构

架构，又称软件架构

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

通俗来说：实现一个软件有很多种方法，架构在方法选择上起着至关重要的指导作用。

架构的重要性

  • 地基没打好，大厦容易倒
  • 地基坚实了，大厦才能盖得高
  • 站在巨人肩膀上，才能看得远

问题

兰师傅蛋糕坊要开张了，要解决如下问题：

  • 如何做蛋糕？ 独家秘方，还是亲自做比较好。
  • 如何卖蛋糕？ 刚开始客流量应该不大，边做边卖。

现在可以开张了。

单机架构

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

image.png

优点

  • 简单

问题

  • 运维需要停服

此时，如果客户很多，但是只有一个人做蛋糕，卖蛋糕。因此此时想要卖出更多的蛋糕，就需要多雇几个蛋糕师傅。

垂直切分 —— 单体架构、垂直应用架构

单体架构

将进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。

image.png

垂直应用架构

将进程进一步拆分，而得到相对独立的应用，就来到了垂直应用架构，其按照应用来拆分进程。

image.png

上面两种都属于垂直切分的架构，其解决了之前的一些问题。

优点

  • 水平扩容
  • 运维无需停服

问题

  • 职责太多，开发效率不高
  • 爆炸半径大

这时，思考怎么继续提高效率，想到既然垂直切分了，那可不可以水平切分呢？答案当然是可以的，也就是各自分工协作。

水平切分 —— SOA、微服务架构

SOA（Service-Oriented Architecture）

将进程按功能进一步划分为多个服务，以服务为一等公民，并为它们之间定义通信标准，就得到了SOA架构。

重要概念

  • 服务 根据功能抽象出来的概念。比如处理用户登录的Passport服务，负责持久化存储的数据库服务，以及为了加速查询的缓存服务等。
  • 通信标准 是服务之间通信的基石。没有实现定义好的通信标准，就好比多个师傅之间语言不通，难以协作。

image.png

为了服务之间的通信，有两个大的发展方向

  • 中心化 方案形态重，拓展性不佳，普及性不佳。
  • 去中心化 有许多好处。

微服务架构

SOA的去中心化演进方向就是微服务架构。

image.png

在这种情况下，不同模块的研发工程师就可以专心于自己的业务逻辑，开发效率可以得到显著的提高；同时，由于各个模块独立运维，整个系统的稳定性得到了提高。

但是由于垂直切分和水平切分，也带来了一些问题：

  • 单机架构到分布式架构，如何解决数据一致性？
  • 服务越来越多，依赖越来越复杂，如何做到高可用？
  • 一个团队甚至一个人可能同时管理多个微服务，如何运维？
  • 微服务的目标是强化单一职责，控制爆炸半径，如何在解耦和过微之间进行取舍？

企业级后端架构剖析

背景

兰师傅蛋糕店经过3年的发展，积累了良好的口碑和用户基础，接下来需要扩大规模。

  • 店面怎么盘？
    • 卖
    • 租
  • 师傅怎么招？
    • 兰师傅全家出马
    • 找培训班出身的
  • 是否继续坚持纯手工制作？
    • 手工制作
    • 机器加工
    • 我全都要
  • 规模扩大后，工作重心应该是？
    • 精进蛋糕制作收益
    • 蛋糕店重点方向梳理 & 未来规划

云计算

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

基础

  • 虚拟化技术 - 整租 vs 合租
    • 硬件 —— 虚拟机
    • 操作系统 —— 容器
    • 网络
  • 编排方案 - 业主 vs 租赁平台
    • 虚拟机编排方案 —— OpenStack
    • 容器编排方案 —— Kubernetes

架构

  • IaaS（Infrastructure as a Service） 买房子 vs 房屋租赁平台
  • PaaS（Platform as a Service） 清包 vs 全包
  • Saas（Software as a Service） 从零培训 vs 雇佣培训过的师傅
  • FaaS（Function as a Service） 纯手工制作 vs 蛋糕机批量生产

image.png

云原生

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

代表技术

  • 容器化
  • 服务网格
  • 微服务
  • 不可变基础架构
  • 声明式API

基于上述这些技术可以构建出容错性好、易于管理、具备较好观测性的云服务。结合可靠的自动化机制，服务可以轻松应对频繁和可预测的重大变更。

云原生涉及的四大方面

  • 弹性资源

    基于虚拟化容器和灵活的编排调度机制，可以为云服务提供快速扩缩容的能力，而且极大程度地提高了物理资源地利用率。在这一方面，Kubernetes技术已经成为了业界的标准。

  • 微服务架构

    依托于功能单元的解耦，云服务具备了快速迭代的可能，业务得以迅速发展。而统一的通信标准能够帮助越来越多的组件加入到云原生的大家庭，同时也使得各组件之间的交互变得更容易。

  • DevOps

    graph LR
设计(设计)-->开发1(开发)
开发1-->测试1(测试)
测试1-->交付1(交付)
交付1-->开发2(开发)
开发2-->测试2(测试)
测试2-->交付2(交付)
交付2-->...(......)

    自动化的流程使得软件的工作流程更高效，将微服务架构的优势发挥得淋漓尽致。

  • 服务网格

    如果说微服务架构的重要进步，是将庞大的单体服务按照业务功能解耦开来，那么服务网络的重要进步就是将业务逻辑与网络通信和治理解耦开来。业务不需要关心异构系统中的RPC中间件治理能力的不统一，也使得复杂的治理能力的落地成为可能。

image.png

弹性资源

弹性计算资源

类型如下：

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

类型如下：

  • 经典
    • 对象
      • 宣传视频
    • 大数据
      • 用户消费记录
  • 关系型数据库
    • 收银记录
  • 元数据
    • 服务发现
      • 蛋糕店通信录
  • NoSQL
    • KV
      • 来个 XX 蛋糕

总结来说：将存储资源当作服务。

DevOps

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

image.png

微服务架构

通信标准

  • HTTP（Restful API）
  • RPC（Thrift，gRPC）

微服务中间件 RPC vs HTTP

  • 性能（RPC > HTTP）
  • 服务治理（RPC > HTTP）
  • 协议可解释性（RPC < HTTP）

image.png

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

服务网格

服务网格（Service Mesh）：

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

相比较于 RPC/HTTP 框架：

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

image.png

云原生蛋糕店

企业级蛋糕店架构：

  • 售卖
  • 蛋糕制作（肉丝、慕斯）
  • 会员激励
  • 满意度分析
  • 研发新品

image.png

企业级后端架构的挑战

问题

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

如下图所示，不同的系统下的实例资源水位不均匀

image.png

离在线资源并池

将离线资源池和在线资源池合并。

image.png

其核心收益为：

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

在线业务的特点

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

离线业务的特点

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

问题：同一个机器怎么做离在线隔离？ 答：离线资源对应离线的进程，在线的资源对应在线的进程。使用cgroup或容器化的方式对CPU的核心做隔离，使得不同的任务使用不同的CPU。

自动扩缩容

在离在线资源并池的基础上，利用在线业务的潮汐性自动扩缩容。

image.png

核心收益：

  • 降低业务成本

问题：扩缩容依据什么指标？ 答：微服务中常使用CPU的某一个统计分类数（如P50）来作为指标。内存有时候也行，得看情况。IO、QPS等量化比较难，所以暂时不用做指标。

微服务亲和性部署

image.png

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

核心收益：

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

流量治理

基于微服务中间件 & 服务网格的流量治理

核心收益：

  • 提高微服务调用容错性
  • 容灾
  • 进一步提高开发效率，DevOps发挥到极致

CPU水位负载均衡

异构环境下的资源水位不均问题的解决。主要使用：

  • IaaS
    • 提供资源指针（反馈资源使用量）
  • 服务网格
    • 动态负载均衡

image.png

核心收益：

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

三、实践练习例子

问题背景

CPU水位负载均衡，应该如何设计？

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

问题提炼

输入：

  • 服务网格数据面
    • 支持带权重的负载均衡策略（给不同容器分配不同量的工作）
  • 注册中心存储了所有容器的权重信息
  • 宿主机能提供
    • 容器的资源使用情况
    • 物理资源情况（如CPU型号）

image.png

关键点

  • 紧急回滚能力
  • 大规模
  • 极端场景

自适应静态权重

方案

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

image.png

优势

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

缺点

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

自适应动态权重 Alpha

方案

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

image.png

演进方向

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

缺点

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

自适应动态权重 Beta

方案

  • 服务网格上报RPC指标

image.png

演进方向

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

缺点

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

自适应动态权重 Release

演进方向

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

image.png

问题解决

  • 解决在线分析引擎的数据一致性问题

    • 一致性哈希

  • 解决时序数据库压力

    • 将其作为旁路工具，采用纯内存的在线分析引擎进行实时策略计算

  • 离线分析

    • 使用消息队列解耦、削峰

  • 离线回馈在线

四、课后个人总结

此次课程讲述了架构相关的一些内容，从架构的发展历程到实践例子的挑战，一一道来。最后，对于架构：

  • 没有最好的架构，只有最合适的架构
  • 如何做架构
    • 需求先行。弄清楚要解决什么问题
    • 业界调研。业界内都有哪些解决方案可以参考
    • 技术选型。内部/社区都有哪些基础组件
    • 异常情况。考虑清楚xxx不行了怎么办

五、引用参考

avatar
文章
阅读
粉丝