架构入门讲解 - 谁动了我的蛋糕

笔者参加了今年字节跳动举办的后端青训营，在听了其中一节关于架构入门介绍的课后，作下本篇笔记。

本篇笔记主要是讲述后端开发中关于架构的信息，内容偏广泛且入门，同时课程里老师用了蛋糕店师傅卖蛋糕的比喻方式形象生动地讲解架构。

什么是架构

架构的定义

• 有关软件整体结构与组件的抽象描述
• 用于指导软件系统各个方面的设计
• 通俗地讲，实现一个软件有很多中方法，方法选择上起着至关重要的指导作用

单机

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

• C10K problem：提供的服务有瓶颈
• 运维需要停服

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

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

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

SOA、微服务|水平切分

SOA(Service-Oriented Architecture)

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

在单机 → 单体 → SOA的过程中，功能的演化为：进程 → 应用 → 服务

SOA以服务为中心，即面向服务，而服务之间的沟通就需要通过定义通信标准来进行，可以说是进行了水平切分。

微服务架构 : SOA的去中心化演进方向，将职责和服务拆分得更加细致，提倡服务之间建立自由的沟通方式，进而避免中心化的存在，使得耦合性更低。

问题:

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

小结：

架构的演进初衷: 好比做蛋糕。

• 需求量越来越大, 终归要增加人手
• 越做越复杂，终归要分工合作

架构的演进思路: 就像切蛋糕，蛋糕越来越大，一口吃不下终归要切分

• 竖着切(垂直切分)
• 横着切(水平切分)

 

企业级后端架构剖析

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

• 店面怎么盘: 买/租
• 师傅怎么招: 兰师傅全家出马/招培训班出身的
• 是否继续坚持纯手工制作?
• 规模大了之后，工作重心应该是: 精进蛋糕制作收益/蛋糕店重点方向梳理和未来规划

云计算

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

基础:

• 虚拟化技术 – 整租vs合租
• 编排方案 – 业主vs租赁平台

架构: 从上到下提供的功能越来越细致

• Iaas (lnfrastructure as a Service)：买房子vs房屋租赁平台
• PaaS (Platform as a Service)：清包vs全包
• SaaS (Software as a Service)：从零培训vs雇佣培训过的师傅
• FaaS (Function as a Service)：纯手工制作vs蛋糕机批量生产

下图与上面的架构顺序是相反的，从下到上提供的功能越来越细致，可以与上面的架构划分进行类比。

云原生

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

其中：公有云、自由云、混合云都可以理解为云计算中的云，区别在于云的不同形态。

下面对以上图中的各个部分进行进一步的阐述：

弹性资源

弹性计算资源类型

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

弹性存储资源

• 经典
  • 对象: 宣传视频
  • 大数据:用户消费记录
• 关系型数据厍
  • 收银记录
• 元数据（数据不是很大但用于很多场景）
  • 服务发现: 蛋糕店里师傅的通讯录
• NoSQL
  • KV: 来个 xx 蛋糕

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

DevOps

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

Dev贯穿整个软件开发周期：

微服务架构

通信标准:

• HTTP (RESTful API)
• RPC (Thrift, gRPC)

微服务中间件 RPC vs HTTP:

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

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

服务网络

服务网格(Service Mesh):

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

相比较于RPC/HTTP框架:

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

到这里，我们用蛋糕店来类比后端架构，如下图：

 

企业级后端架构的挑战

问题

挑战:

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

离在线资源并池

企业内部提高物理资源使用率的方案

核心收益:

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

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

• 在线业务的特点
  • IO密集型为主
  • 潮汐性(凌晨访问量少、晚高峰访问量大)、实时性(延迟敏感)
• 离线业务的特点
  • 计算密集型占多数
  • 非实时性

自动扩缩容

核心收益：降低业务成本

解决思路：自动扩缩容

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

问题：扩缩容依据什么指标？
例：CPU利用率、内存利用率

微服务亲合性部署

核心收益：

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

解决思路：微服务亲合性部署

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

流量治理

核心收益:

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

解决思路: 基于微服务中间件&服务网格的流量治理

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

CPU水位负载均衡

核心收益:

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

解决思路: CPU水位负载均衡

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

 

尾声

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