这是我参与「第三届青训营 -后端场」笔记创作活动的的第7篇笔记
什么是架构
- 架构：又称软件架构，是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计
- 换一个说法来说，架构是在选择如何实现一个软件的方法
- 单机：把所有的功能都是现在一个进程里，并部署在一台机器上
- 优点是简单
- 缺点是运维的话需要停服和存在 C10K problem（单机并发问题，限制了服务能力，存在瓶颈）
- 单体架构：对单机架构做一个分布式部署
- 优点：有一定的并发能力，及应对一定复杂业务，实现了水平扩容
- 缺点：每个进程都要有处理所有功能的能力导致重复开发
- 垂直应用架构：按应用垂直切分的单体架构
- 可以视作单体架构
- 优点：
- 实现了水平扩容，这样可以容纳更多客户，同时提供更多的服务
- 运维不需要停服
- 缺点：
- 职责依旧还是太多，开发效率不高，虽然进行了一定的分工，但是每个还是要负责某项功能的全部步骤
- 爆炸半径大，资源无法隔离，一旦某个功能模块对资源使用不当，整个系统都会被拖垮
- SOA（Service-Oriented Architecture）：面向服务的架构
- 将应用的不同功能单元抽象为服务
- 定义服务之间的通信标准
- 微服务架构就是 SOA 的去中心化的演进方向
- 缺点：
- 数据一致性：怎么保证数据是一致的，怎么做统计，不同进程中间产生的数据应该怎么保存
- 高可用：众多服务之间会产生复杂的调用和沟通，怎么保持合作，如果某些链路中间发生了问题，怎么保证整个链路网络还是通畅的
- 治理：对链路出现的问题怎么容灾
- 解耦 VS 过微：运维成本会变高，应该如何拆分
- 架构的演进初衷：好比于做蛋糕
- 需求量越来越大，终归需要增加人手
- 业务越做越复杂，终归需要分工合作
- 架构的演进思路：如同切蛋糕一样，一口吃不下终归要进行切分
- 垂直切分：具备横向拓展的能力
- 水平切分：层级越来越深，每个模块的独立性更强，降低耦合性
企业级后端架构剖析
- 云计算：通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的技术
- 基础：
- 虚拟化技术（整租/合租）：决定于机器虚拟化后得到的虚拟机是整个都交由自己使用还是虚拟化出很多个虚拟机但自己使用其中一部分，其他部分交由他人使用
- 编排方案（业主/租赁平台）：如何去管理和安排分配资源，使其能够服务于特定的工作或项目，
- 架构（通过不同服务的多少是由供应商管理的来区分类型）：
- IaaS（Infrastructure as a Service）：服务商提供底层/物理层基础设施资源（服务器，数据中心，环境控制，电源，服务器机房），客户自己部署和执行操作系统或应用程序等各种软件
- PaaS（Platform as a Service）：可以视作是 SaaS 的一种，在 PaaS 下服务商将底层的平台已帮你铺建好，你需要开发自己的上层应用
- SaaS（Software as a Service）：软件及服务，在这种情况下，用户只需要租用供应商提供的软件就可以实现对企业的经营活动的管理，并且不需要对软件进行维护，全部功能由供应商管理和维护
- FaaS（Function as a Service）：服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护通常与开发和启动应用程序相关的基础架构的复杂性
- 除此之外还有 BaaS、DaaS、NaaS
- 假设现在有一个披萨师傅，他要做披萨，对于以上四种，他有四种选择的方法：
- 如果他选择 IaaS，那么相当于已经有人为他准备好了灶台和烤炉，披萨师傅需要使用这些基础设施来做出他的披萨
- 如果他选择 PaaS，那么此时相当于有人为他准备好了皮萨饼坯，披萨师傅要做的是将披萨选好相应的配料、做好披萨的设计、决定披萨的口味
- 如果他选择 SaaS，那么此时是有人将一个完整的披萨成品交给了披萨师傅，他要做的就是直接进行售卖即可，可以加上自己的包装等等
- 如果他选择 FaaS，类似于 PaaS，但是 FaaS 是在平台的基础上，披萨师傅不再需要单纯地依靠手工去做披萨，而是直接使用披萨机器自动化制作披萨
- 使用云计算可以使得企业更加关注业务层次的事情，而不需要去关注具体后面实现的事情
- 基础：
- 云原生（Cloud Native）：为组织在公有云、自由云、混合云等新型动态环境中，构建和运行可弹性拓展的应用提供了可能
- 弹性资源：
- 弹性资源类型：
- 服务资源调度（根据服务的量度）：微服务和大服务
- 计算资源调度：在线资源和离线资源
- 消息队列：在线消息队列（削峰和解耦）和离线消息队列（大数据分析）
- 弹性存储资源类型（将存储资源当成服务一样）：
- 经典：对象 + 大数据
- 关系型数据库
- 元数据
- NoSQL
- 特点：
- 虚拟化容器：不需要关注底层的物理资源的形态
- 快速扩缩容：使用的时候扩容，闲置的时候缩容
- 弹性资源类型：
- 微服务架构：
- 业务功能单元解耦
- 统一的通信标准（HTTP/RPC）
- DevOps：
- 结合自动化流程，提高软件开发、交付效率
- 敏捷开发
- CI/CD
- 结合自动化流程，提高软件开发、交付效率
- 服务网格：微服务之间通讯的中间层
- 高性能网络代理
- 业务代码与治理结构解耦，使得生命周期易于管理
- 异构系统的治理统一化
- 复杂治理能力
- 弹性资源：
企业级后端架构的挑战
- 基础设施层面
- 物理资源（机器、带宽）是有限的
- 资源利用率受制于部署服务
- 用户层面
- 网络通信开销较大
- 网络抖动导致运维成本提高
- 异构环境下，不同实例资源水位不均
- 离在线资源并池（不同的时间点对两个池子的资源的分配不同）
- 核心收益：
- 降低物理资源成本
- 提供更多的弹性资源、增加收入
- 在线业务的特点
- IO 密集型为主
- 潮汐性、实时性（要求立刻能够得到响应）
- 离线业务的特点
- 计算密集型占多数
- 非实时性
- 同一个机器通过容器和虚拟化对 CPU 的核心做在线和离线的隔离
- 核心收益：
- 自动扩缩容
- 核心收益：降低业务成本
- 解决思路：利用在线业务潮汐性自动扩缩容
- 扩缩容依据以下指标
- CPU 的一些统计分配数：CPU 的 P50
- 微服务亲和性部署
- 核心收益：
- 降低业务成本
- 提高服务可用性
- 解决思路：
- 将满足亲核性条件的容器调度到一台宿主机
- 微服务中间件（相比于服务网格的流量调配能力是非常有限的）与服务网格通过共享内存通信
- 服务网格控制面实施灵活、动态的流量调度
- 核心收益：
- 流量治理
- 核心收益：
- 提高微服务调用容错性
- 容灾
- 进一步提高开发效率，将 DevOps 发挥到极致
- 解决思路（基于微服务中间件 & 服务网格的流量治理）：
- 熔断、重试
- 单元化
- 复杂环境（功能、预览）的流量调度
- 核心收益：
- CPU 水位负载均衡
- 核心收益：
- 打平异构环境算力差异
- 为自动扩缩容提供正向输入
- 解决思路：
- laaS：提供资源探针
- 服务网格：动态负载均衡
- 核心收益：
后端架构实战
- 问题提炼
- 输入：
- 服务网格数据面：支持带权重的负载均衡策略
- 注册中心存储了所有容器的权重信息
- 宿主机能够提容器的资源使用情况和物理资源信息
- 关键点：
- 紧急回滚能力
- 大规模
- 极端场景
- 输入：
- 自适应静态权重：
- 方案：通过采集宿主机物理资源的信息来调整容器注册的权重，在原本的宿主机内新增了一个调权代理模块
- 优点：
- 复杂度低
- 完全分布式，可用性高，不会影响到其他机器
- 微服务中间件无适配成本
- 缺点：
- 无紧急回滚能力
- 缺乏运行时自适应能力
- 自适应动态权重
- 方案：利用服务网格的服务发现和流量调度能力实现容器动态权重的自适应调整
- 在原本的自适应静态权重的基础上新增了一个动态权重决策中心，并将资源探针的信息直接传输给动态权重决策中心，经由动态权重决策中心将服务注册信息发送给注册中心并通过配置中心像动态权重决策中心获取服务在注册中的名称
- 演进方向：
- 解决了无法紧急回滚的问题——立即切换回静态权重的状态
- 运行时权重自适应
- 缺点：过度流量倾斜可能会有异常情况
- 自适应动态权重
- 方案：服务网格上报 RPC 指标
- 演进方向：极端场景的处理成为可能
- 缺点：
- 时序数据库的压力较大
- 动态权重决策中心指责越来越多，迭代导致的变更会带来风险
- 自适应动态权重 release
- 演进方向：
- 微服务化
- 引入消息队列削峰、解耦
- 离在线链路切分
- 梳理强弱依赖
- 演进方向：
