这是我参与「第五届青训营」伴学笔记创作活动的第 6 天
[ 初识后端架构 | 青训营笔记 ]
零、前言：
本文记录和整理了本人在跟随字节青训营学习的一些我个人感觉比较重要的内容和知识，也有一部分内容是我认为自己比较难理解或记忆的，也一并记录于此文。
撰写本文的目的主要是方便我自己的复习和查阅，倘若各位读者有与我相似的问题，也可以参考之，如果对各位有帮助那就是我莫大的荣幸，也期望各位不吝赐教，多多指出我的问题，可以在下方留言或者私信我。
一、本堂课重点内容：
本节课将以实际案例切入，深入浅出，帮助理解软件架构的定义及形态。
- 什么是架构？
- 企业级后端架构剖析
- 企业级后端架构的挑战
- 后端架构实战
二、详细知识点介绍：
0. 什么是架构？用来干什么？
A：架构是非常重要的基石，其全称是软件架构：
- 是有关软件整体结构与组件的抽象描述
- 用于指导软件系统各个方面的设计
单机架构
Q：举个例子呗？
A：软件系统一定是要对外提供服务的，单机架构就是最基本的架构。
Q：单机又是什么？
A：单机就是把所有需要的功能集成在一个进程里，并部署在一台机器上。
Q：哦，那我懂了，这种架构有什么优缺点吗？
A：问得好，单机服务的模式，除了简单之外没有任何优点，甚至运维的时候还需要停服，所以说这个模式只适合出现在项目的预研或初创阶段，但凡业务有进一步发展的诉求就需要做结构迭代。
单体架构与垂直应用架构
Q：怎么样让架构更优秀呀？
A：把进程部署到多个机器上，并引入负载均衡层，经过垂直切分，就变成了单体架构。
Q：等会儿等会儿，整不明白了，把进程部署到多个机器上，相当于是分治了吗？
A：你说的很对，就相当于切蛋糕，然后负载均衡层负责引导用户去吃哪块蛋糕。
Q：负载均衡层...？能不能整点接地气的名字？
A：负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。说白了，可以理解成一个分配任务的leader。
Q：你这么说我就明白了，那垂直切分又是什么捏？
A：垂直切分是根据业务来拆分数据库，同一类业务的数据表拆分到一个独立的数据库，另一类的数据表拆分到其他数据库。垂直切分可以降低单节点数据库的负载。原来所有数据表都放在一个数据库节点上，无疑所有的读写请求也都发到这个MySQL上面，所以数据库的负载太高。如果把一个节点的数据库拆分成多个MySQL数据库，这样就可以有效的降低每个MySQL数据库的负载。
Q：写的真啰嗦，不过差不多看明白了，这玩意有什么缺点吗？
A：垂直切分不能解决的是缩表，比如说商品表无论划分给哪个数据库节点，商品表的记录还是那么多，不管你把数据库垂直拆分的有多细致，每个数据表里面的数据量是没有变化的。
Q：那垂直应用架构是什么？
A：在单体架构的基础上，进一步拆分，按应用拆分进程，就是垂直应用架构。优点是可以水平扩容，以及不停服运维，但是也有问题是职责太多，开发效率并不高，而且爆炸半径太大。
SOA 微服务与水平切分
Q：既然有垂直切分，那么是不是也有水平切分？
A：真聪明，不过我们先来了解一下什么是SOA (Service-Oriented Architecture)，也就是面向服务的架构；
- 将应用的不同功能单元抽象为服务（服务是根据功能抽象出来的概念）
- 定义服务之间的通信标准（通信标准是服务之间通信的基石）
Q：真高级，那微服务又是什么？
A：微服务架构是SOA的去中心化演进方向，当然也有中心化的发展方向，但是太臃肿了，拓展性和普及性都不咋地。微服务架构的效果：
- 不同模块的RD可以专心于自己的业务逻辑了，开发迭代效率得到了显著提高
- 各个服务独立运维，变更操作的影响面可控，应用整体的稳定性得到了提高
Q：差不多明白了，有没有图示？
A：那我们就用课程里的一张图来解释吧：（水印是讲师PPT自带的）
Q：好好好，那水平切分是什么？
A：水平切分是按照某个字段的某种规则，把数据切分到多张数据表。一张数据表化整为零，拆分成多张数据表，这样就可以起到缩表的效果了。
A：总结一下，架构的演进如同做蛋糕（借用课件的比喻，笔者实在是想象力匮乏）：
- 需求量越来越大，终归要增加人手
- 越做越复杂，终归要分工合作
- 有时需要横着切，有时需要竖着切，蛋糕做大了（架构复杂了）就需要横竖都切（水平切分+垂直切分）
1. 企业级后端架构剖析
云计算
Q：云计算云计算，总是听到这个词，但是具体是什么呢？
A：云计算是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模分析和存储的基石。
Q：云计算的基础是什么？
A：一个是虚拟化技术，一个是编排方案；
- 虚拟化技术：硬件（虚拟机）、操作系统（容器）、网络
- 编排方案：虚拟机编排方案（OpenStack）、容器编排方案（Kubernetes）
A：还有架构方面：
- IaaS（Infrastructure as a Service）
- PaaS（Platform as a Service）
- SaaS（Software as a Service）
- FaaS（Function as a Service）
云原生
Q：云原生，emmm好像听过，但是这个就比较陌生了，可以解释一下吗？
A：云原生技术为组织在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能，全称是云原生计算，是元计算发展到现在的一种形态，有如下几种代表技术：
- 容器化
- 服务网格
- 微服务
- 不可变基础架构
- 声明式API
A：可以说，云原生的四个要点就是DevOps + 持续交付 + 微服务 + 容器
Q：等等，DevOps是什么？能吃吗？
A：很遗憾，不能吃，DevOps 是开发 (Dev) 和运营 (Ops) 的复合词，它将人、流程和技术结合起来，不断地为客户提供价值。
Q：DevOps 对团队意味着什么？
A： DevOps 使以前孤立的角色（开发、IT 运营、质量工程和安全）可以协调和协作，以生产更好、更可靠的产品。通过采用 DevOps 文化、做法和工具，团队能够更好地响应客户需求，增强对所构建应用程序的信心，更快地实现业务目标。一图以释之：
Q：那云原生是怎么和微服务扯上关系的呢，刚才不是在架构里面提到了吗？
A：你说得对，但是《微服务》是一款后面忘了，在云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架的微服务中间件来做，其中通信标准是有HTTP(Rustful API)和RPC(Thrift gRPC)两个。
A：还有一点要补充的是，服务网格也是云原生的很重要的一部分，我们直接来看一张图：
2. 企业级后端架构的挑战
挑战概览
- 基础设施层面
- 物理资源是有限的
- 机器
- 贷款
- 资源利用率受制于部署服务
- 物理资源是有限的
- 用户层面
- 网络通信开销较大
- 网络抖动导致运维成本提高
- 异构环境下，不同实例资源水位不均
法一：离在线资源并池
核心收益：
- 降低物理资源成本
- 提供更多的弹性资源，增加收入
Why？
在线业务的特点：
- IO密集型为主
- 潮汐性、实时性
离线业务的特点
- 计算密集型占多数
- 非实时性
法二：自动扩缩容
核心收益：
- 降低业务成本
Why？
- 利用在线业务潮汐性自动扩缩容
法三：微服务亲合性部署
核心收益：
- 降低业务成本
- 提高服务可用性
Why？
- 将满足亲合性条件的容器调度到一台宿主机
- 微服务中间件与服务网格通过共享内存通信
- 服务网格控制面实施灵活、动态的流量调度
法四：流量治理
核心收益：
- 提高微服务调用容错性
- 容灾
- 进一步提高开发效率，令DevOps发挥到极致
Why and How？
- 熔断、重试
- 单元化
- 复杂环境（功能+预览）的流量调度
法五：CPU水位负载均衡
核心收益：
- 打平异构环境算力差异
- 为自动扩缩容提供正向输入
Why？
- IaaS：提供资源探针
- 服务网格：动态负载均衡
三、后端架构实战部分
问题概述：
Input：
- 服务网格数据面
- 支持带权负重的负载均衡策略
- 注册中心存储了所有容器的权重信息
- 宿主机能提供
- 容器的资源使用情况
- 物理资源信息（如CPU型号）
Key：
- 紧急回滚能力
- 大规模
- 极端场景
这里我们直接给出课件中的四个方案，不加以过多解释（实际上是笔者也没有搞明白，后续再补充）：
- 自适应静态权重
- 自适应动态权重Alpha
- 自适应动态权重Beta
- 自适应动态权重Release
未完待续...（随时补充修改）
谢谢大家的阅读，欢迎互动，也欢迎访问我的博客！
