后端架构初探——蛋糕店案例 | 青训营笔记

wee
152 阅读7分钟

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

前言

本文主要内容：

  • 架构介绍
  • 企业级后端架构剖析

1 架构

1.1架构定义

架构：又称软件架构：

  • 是有关软件整体结构与组件的抽象描述
  • 用于指导软件系统各个方面的设计
  • 简单说，架构对于往后的方法选择上能有至关重要的作用

架构的重要性：

  • 架构没设计好，软件容易崩，用户体验上不去。
  • 架构设计好了，软件才能有更好的稳定性和可拓展性，才能提高用户体验
  • 良好的架构基础，为软件的未来发展提供了更多的可能，其实就是站在巨人的肩膀上为用户赋能，实现自身价值

1.2 架构类型

1.2.1 单机

单机，把所有功能放在都在一个进程里，部署在一个机器上。

优点：

  • 简单

缺点：

  • c10k 问题承载能力有限。
  • 运维需要停服

拿蛋糕店案例来说，你只有一家店，一个师傅做蛋糕，卖给客户。

1.2.2 单体

在单机架构的基础上，将进程部署到多个机器上，即分布式部署。

优点：

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

缺点：

  • 进程职责太多，开发效率不高
  • 爆炸半径较大，即进程中一个很小的模块出现问题，都可能导致整个进程崩溃

对于蛋糕店案例，即在单机基础上，雇佣经理，多几个师傅进行蛋糕店的管理

1.2.3 垂直应用架构

  • 在单机架构基础上，将 A 和 B 的后端拆分为 A、B 两个进程，然后再按照单体模式的思路，部署在多个机器上。

  • 对于蛋糕店案例，即在单体基础上，对蛋糕和师傅进行分类（A、B、C、D）制作管理。

  • 垂直应用架构：一定程度上减少了单体的后端进程职责和缩小爆炸半径，但没有根本解决单体架构的问题

  • 因此，随着业务场景越来越复杂，服务的职责也越来越多。学过面向对象程序设计的同学都知道单一职责的重要性，在软件架构里也是一样的。开发者不仅要关心 Web 后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。长此以往，RD 很难分出精力专注于业务能力的开发业务发展需要上线、变更，将会影响所有其他不涉及的场景。

  • 为了解决上述问题，为了提高蛋糕店的效率，便提出了分工合作的方法，就有了SOA以及微服务的产生

1.2.4 SOA (面向服务架构)

SOA（Service-Oriented Architecture）

  • 将进程按照不同的功能单元进行抽象，拆分为『服务』
  • 为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性

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

优点：

  • 各服务的职责更清晰
  • 运维粒度减小到服务，爆炸半径可控

缺点：

  • ESB (企业服务总线) 往往需要一整套解决方案

1.2.5 微服务

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

优点：

  • 兼具 SOA 解决的问题
  • 服务间的通信更敏捷、灵活

缺点：

  • 运维成本

SOA以及微服务下的蛋糕店： image.png

但，由垂直切分——分布式和水平切分——分层/模块化所产生的一系列问题需要解决：

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

2 企业级后端架构剖析

2.1 云计算

云计算定义：

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

云计算基础：

  • 虚拟化技术

    • 硬件层面（VM 虚拟机）
      • KVM/Xen/VMware
    • 操作系统层面（Container 容器）
      • LCX/Docker/Kata Container
    • 网络层面
      • Linux Bridge/Open v Switch

  • 编排方案

    • 虚拟机编排方案（OpenStack）
    • 容器编排方案（Kubernetes）

云计算架构：

  • 云服务

    • IaaS
      • 云基础设施，对底层硬件资源池的抽象
    • PaaS
      • 基于资源池抽象，对上层提供的弹性资源平台
    • SaaS
      • 基于弹性资源平台构建的云服务
    • FaaS
      • 更轻量级的函数服务。
      • 如力扣刷题时只需要实现函数，不需要关注输入输出流

对于蛋糕店：

image.png

  • 虚拟化技术：整租 vs 合租
  • 编排方案：业主 vs 租赁平台
  • IaaS：买房子 vs 房屋租赁平台
  • PaaS：清包 vs 全包
  • SaaS：从零培训 vs 雇佣培训过的师傅
  • FaaS：纯手工制作 vs 蛋糕机批量生产

2.2 云原生

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

云部署模式类型：

  • 私有云
    • 企业自用
  • 公有云
    • AWS/Azure/Google Cloud/Huawei
  • 混合云

云原生，即云原生（计算）的简称，它是云计算发展到现在的一种形态。

云原生的代表技术：

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

2.2.1 弹性资源

基于虚拟化技术，提供的可以快速扩缩容的能力。可以分为弹性计算资源和弹性存储资源两个方面。

1 弹性计算资源：

  • 计算资源调度

    • 微服务
      • 如，和面、雕花
    • 大服务
      • 如，烤箱，占用实践长

  • 服务资源调度

    • 在线
      • 热销榜单
    • 离线
      • 热销榜单更新

  • 消息队列

    • 在线队列
      • 削峰、解耦
    • 离线队列
      • 大数据分析

2 弹性存储资源：

  • 经典存储

    • 对象
      • 视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
      • 如，宣传视频
    • 大数据存储
      • 应用日志、用户数据等。
      • 如蛋糕店的用户消费记录

  • 关系型数据库

    • 如收银记录

  • 元数据

    • 服务发现，如蛋糕店通讯录

  • NoSQL

    • KV 存储 - Redis，如来xx个蛋糕
    • 文档存储 - Mongo

在云原生的大背景下，不论是计算资源还是存储资源，他们都像是服务一样供用户使用。

2.2.2 DevOps

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

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

如图所示 image.png

2.2.3 微服务架构

微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的。

通信标准:

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

选择 HTTP 和 RPC 的标准（选RPC的原因）：

  • 性能
    • RPC 协议往往具备较好的压缩率，性能较高。
    • 如 Thrift, Protocol Buffers
  • 服务治理
    • RPC 中间件往往集成了丰富的服务治理能力。
    • 如 熔断、降级、超时等
  • 可解释性
    • HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好

image.png

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

2.2.4 服务网格

服务网格（service mesh）

  • 微服务之间通讯的中间层
  • 一个高性能的 4 层网络代理
  • 将流量层面的逻辑与业务进程解耦

服务网格相比较于 RPC/HTTP 框架：

  • 实现了异构系统治理体验的统一化
  • 服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更容易管理

image.png

3 企业级后端的蛋糕店

架构：

  • 售卖
  • 蛋糕制作
  • 会员激励
  • 满意度分析
  • 研发新品
  • 等等

云原生版本： image.png

心得

后端架构之前在做项目时有所了解，经过了今天的课程学习，更让我充分认识到企业级的后端项目应该考虑哪些方面的问题，以及对应问题一般以什么角度去解决，尤其在云原生剖析一块让我大受震撼，并在蛋糕店案例的引导下，我也能够更好理解微服务架构，举得例子十分生动形象且容易理解，明天继续加油学习后端知识！

引用

ppt：‌​⁣⁣‍⁣⁣‍⁢⁢​​⁡‍‬⁢⁤‌⁢⁣​⁢⁣‬⁡⁡⁣​​⁢​⁤⁤‍​⁣‌‍⁣‍⁢‌⁣⁡‌​规则引擎的设计与实现.pptx - 飞书云文档 (feishu.cn)

avatar
文章
阅读
粉丝