架构初探——谁动了我的蛋糕 | 青训营笔记

xxxxxyyy
279 阅读11分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第三篇笔记。主要介绍各种后端架构以及从蛋糕店例子来介绍针对场景设计一个合理的架构的过程。

1 什么是架构

架构定义

架构，又称软件架构

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

简单来说，实现一个软件有很多种方法，架构在方法选择上起着至关重要的作用

单机

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

优点：

  • 简单 问题：
  • C10K problem 单体服务一定有架构瓶颈
  • 运维需要停服，因为只有一个单体服务，有用户使用的时间点没有办法运维。

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

为了解决单机的问题，可以多用几台机器。把进程部署在多个机器上，并引入负载均衡层，经过垂直切分，就来到了单体架构。

在单体架构上，进一步地把不同应用的代码从之前一个大的进程中拆分出来，就来到了垂直应用架构。

单体架构：分布式部署

垂直应用架构：按应用垂直切分的单体

优点：

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

问题：

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

image.png

演进：如何提高做蛋糕效率？

  • 分工协作

SOA、微服务 | 水平切分

SOA(Service-Oriented Architecture)：

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

微服务架构：SOA的去中心化演进方向

优点：

  • 不同模块的RD可以专心于自己的业务逻辑，开发迭代效率得到显著提高
  • 各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到提高

image.png

垂直切分和水平切分导致的一系列问题：

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

小结

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

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

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

  • 竖着切（垂直切分）
  • 横着切（水平切分）

2 企业级后端架构剖析

背景

image.png

云计算

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

基础：

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

架构：

  • IaaS Infrastructure as a service: 基础设施服务。主要提供部分基础资源，如机房、网络、服务器等，也就是云服务的最底层。
    • 买房子vs房屋租赁平台
  • PaaS Platform as a service: 是指平台服务。平台提供软件部署平台（runtime），抽象掉了硬件和操作系统细节，可以无缝地扩展（scaling）。开发者只需要关注自己的业务逻辑，不需要关注底层。
    • 清包vs全包
  • SaaS Software as a service：是指软件服务,也称为云应用服务。是软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来即用。普通用户接触到的互联网服务，几乎都是 SaaS。
    • 从零培训vs雇佣培训过的师傅
  • FaaS Function as a Service：是指函数即服务。无服务器计算，当前使用最广泛的是AWS的Lambada。服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护通常与开发和启动应用程序相关的基础架构的复杂性。 按照此模型构建应用程序是实现“无服务器”体系结构的一种方式，通常在构建微服务应用程序时使用。
    • 纯手工制作vs蛋糕机批量生产

image.png

参考： IaaS、PaaS、SaaS、FaaS以及XPaaS大全 、 结合阿里云 FC 谈谈我对 FaaS 的理解

云原生

云原生技术为组织在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。其代表技术有：容器化、服务网格、微服务、不可变基础架构、声明式API。

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

image.png

云原生之弹性计算资源

弹性计算资源类型：

  • 服务资源调度：微服务、大服务 （可以按照占用资源的量级来划分）
  • 计算资源调度：
    • 在线：热销榜单
    • 离线：热销榜单更新（数据分析计算量较大）
  • 消息队列：
    • 在线：削峰、解耦
    • 离线：大数据分析

弹性存储资源类型：

  • 经典存储
    • 对象存储：宣传视频
    • 大数据：用户消费记录
  • 关系型数据库
    • 收银记录，某一用户在什么时间点买了什么蛋糕花了多少钱，手机号、订单号是多少
  • 元数据
    • 服务发现：蛋糕店通讯录
  • NoSQL
    • KV：如缓存、分布式事务等。来个xx蛋糕

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

云原生之DevOps

DevOps是云原生时代软件交付的利器，贯穿整个软件开发周期。

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

image.png

云原生之微服务架构

通信标准：

  • HTTP（RESTful API）
  • RPC （Thrift, gRPC）

微服务中间件协议的选择 RPC vs HTTP：

  • 性能，RPC会做通信压缩，性能一般比HTTP协议要好。
  • 服务治理，一些RPC中间件天生具备服务治理能力。
  • 协议可解释性，payload可解释性，HTTP使用的json格式有较好的可解释性。

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

image.png

云原生之服务网格

服务网格（Service Mesh）:

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

相比较于RPC/HTTP框架：

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

image.png

云原生蛋糕店总结

企业级蛋糕店架构：

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

image.png

3 企业级后端架构的挑战

挑战：

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

image.png

离在线资源并池

核心收益：

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

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

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

根据业务潮汐性，对池子资源进行调配

image.png

问题：同一个机器怎么做离在线隔离？

可以使用容器化方式如Cgroup或虚拟化方式进行划分。

自动扩缩容

核心收益：

  • 降低业务成本

解决思路：利用在线业务潮汐性自动扩缩容

image.png

问题：扩缩容依据什么指标？

根据不同的场景来设计，如使用CPU的P50的百分位数来衡量资源的使用情况。如果有服务有内存的要求，可以把CPU和内存结合。而基于IO做扩缩容在目前技术上比较难实现。还有诸如QPS也不太适用。

微服务亲合性部署

核心收益：

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

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

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

image.png

流量治理

核心收益：

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

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

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

CPU水位负载均衡

核心收益：

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

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

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

image.png

4 后端架构实战

问题背景

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

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

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

考虑：CPU水位负载均很给，应该如何设计？

  1. 需要哪些输入？
  2. 设计时需要考虑哪些关键点？

问题提炼

输入：

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

关键点：

  • 紧急回滚能力，预防雪崩
  • 大规模，系统稳定性，计算瓶颈
  • 极端场景

image.png

拓展：浅谈微服务注册与发现

自适应静态权重

方案：

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

优势：

  • 复杂度低，使用调权代理只需关注自身宿主机的资源使用情况即可
  • 完全分布式，可用性高
  • 微服务中间件无适配成本

缺点：

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

image.png

自适应动态权重Alpha

动态决策中心主动拉取服务容器的指标，

方案：

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

演进方向：

  • 解决无法紧急回滚的问题，如若动态权重出现问题，可以切换为使用静态权重的方案实现回滚
  • 运行时权重自适应

缺点：

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

image.png

自适应动态权重Beta

方案：

  • 服务网格上报RPC指标

演进方向：

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

缺点：

  • 时序数据库压力较大
  • 动态权重决策中心职责越来越多，迭代->变更->风险 （需要对其进行拆分->微服务化）

image.png

自适应动态权重Release

方案：

  • 解决在线分析引擎的数据一致性问题：一致性哈希
  • 解决时许数据库压力：将其作为旁路工具，采用纯内存的在线分析引擎进行实时策略计算
  • 离线分析：使用消息队列解耦、削峰
  • 离线回馈在线

演进方案：

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

image.png

总结

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