什么是架构
- 又称软件架构，是有关软件整体结构与组件的抽象描述。
- 用于描述软件系统各个方面的设计。
- 有利于实现软件的方法选择。
单机
就是把所有功能都实现在一个进程里，并部署在一台机器上。
- 优点：简单
- 缺点：C10K problem（c10k用来命名并发处理10k连接的问题，表示提供的服务能力有瓶颈）、运维需要停服
单体、垂直应用|垂直切分
- 单体架构：分布式部署
- 垂直应用架构：按应用垂直切分的单体
- 优点：水平扩容、运维不需要停服
- 缺点：职责太多，开发效率不高、爆炸半径大
SOA、微服务|水平切分
- SOA：Service-Oriented Architecture
- 将应用的不同功能单元抽象为服务
- 定义服务之间的通信标准
- 微服务架构：SOA的去中心化演进方向（服务之间自由沟通）
总结
- 架构的演进初衷，好比做蛋糕🍰。
- 需求量越来越大，终归要增加人手
- 越做越复杂，终归要分工合作
- 架构的演进思路，就像切蛋糕🍰。蛋糕越来越大，一口吃不下终归要切分
- 竖着切（垂直切分）
- 横着切（水平切分）
企业级后端架构剖析
云计算
是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石。 👉基础
- 虚拟化技术 - 整租 vs 合租
- 编排方案 - 业主 vs 租赁平台 👉架构
- laaS（Infrastructure as a Service）：买房子 vs 房屋租赁平台
- PaaS（Platform as a Service）：清包 vs 全包
- SaaS（Software as a Service）：从零培训 vs 雇佣培训过的师傅
- FaaS（Function as a Service）：纯手工制作 vs 蛋糕机批量生产
云原生
云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性扩展的应用提供了可能。“云”是云计算的“云”。
- 弹性资源：虚拟化容器、快速扩缩容
- 微服务架构：业务功能单元解耦、统一的通信标准
- DevOps：敏捷开发、CI/CD
- 服务网络：业务与治理解构、异构系统的治理统一化、复杂治理能力
弹性计算资源
弹性计算资源类型：
- 服务资源调度：微服务（和面、雕花），大服务（烤箱）
- 计算资源调度：在线（热榜榜单）、离线（热销榜单更新）
- 消息队列：在线（削峰、解耦）、离线（大数据分析）
弹性存储资源
弹性存储资源类型（用户在使用时，只需要将存储资源当成服务即可）：
- 经典：
- 对象：宣传视频
- 大数据：用户消费记录
- 关系型数据库：收银记录
- 元数据： 服务发现：蛋糕店通讯录
- NoSQL KV：来个 xx 蛋糕
DevOps
DevOps是云原生时代软件交付的利器，贯穿整个软件开发周期。结合自动化流程，可以提高软件开发、交付效率。
微服务架构
👉通信标准
- HTTP（RESTful API）
- RPC（Thrift，gRPC） 👉微服务中间件RPC vs HTTP
- 性能
- 服务治理
- 协议可解释性 👉云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做。
服务网格
👉服务网格（Service Mesh）：
- 微服务之间通讯的中间层
- 高性能网络代理
- 业务代码和治理解耦 👉相较于RPC/HTTP框架：
- 异构系统治理统一化
- 与业务进程解耦，生命周期易管理
云原生蛋糕店
企业级蛋糕店架构：售卖、蛋糕制作（肉松、慕斯）、会员激励、满意度分析、研发新品
企业级后端架构的挑战
- 基础设施层面：物理资源是有限的（机器、带宽）、资源利用率受制于部署服务
- 用户层面：网络通信开销较大、网络抖动导致运维成本提高、异构环境下，不同实例资源水位不均
离在线资源并池
- 核心收益：降低物理资源成本、提供更多的弹性资源，增加收入
- 解决思路：离在线资源并池
- 在线业务的特点：IO密集型为主、潮汐性和实时性
- 离线业务的特点：计算密集型占多数、非实时性
自动扩缩容
- 核心收益：降低业务成本
- 解决思路：自动扩缩容（利用在线业务潮汐性自动扩缩容）
- 依据指标：内存和CPU等
微服务亲合性部署
- 核心收益：降低业务成本、提高服务可用性
- 解决思路：微服务亲合性部署（将满足亲合性条件的容易调度到一台宿主机、微服务中间件与服务网格通过共享内存通信、服务网格控制面实施灵活、动态的流量调度）
流量治理
- 核心收益：提高微服务调用容错性；容灾；进一步提高开发效率，DevOps发挥到极致
- 解决思路：基于微服务中间件 & 服务网格的流量治理（熔断和重试、单元化、复杂环境（功能、预览）的流量调度）
CPU水位负载均衡
- 核心收益：打平异构环境算力差异、为自动扩缩容提供正向输入
- 解决思路：CPU水位负载均衡（laaS：提供资源探针、服务网格：动态负载均衡）
后端架构实战
- 问题背景（CPU水位负载均衡类比）：不同的师傅干活的效率差距较大、有些师傅希望【能者多劳多挣】。
问题提炼
👉输入
- 服务网格数据面：支持带权重的负载均衡策略
- 注册中心存储了所有容器的权重信息
- 宿主机能提供：容器的资源使用情况、物理资源信息（如CPU型号） 👉关键点
- 紧急回滚能力
- 大规模
- 极端场景
问题解决
自适应静态权重
- 方案：采集宿主机物理资源信息、调整容器注册的权重
- 优势：复杂度低、完全分布式，可用性高、微服务中间件无适配成本
- 缺点：无紧急回滚能力、缺乏运行时自适应能力
自适应动态权重Alpha
- 方案：容器动态权重的自适应调整、服务网格的服务发现 & 流量调度能力
- 演进方向：解决无法紧急回滚的问题、运行时权重自适应
- 缺点：过度流量倾斜可能会有异常情况
自适应动态权重Beta
- 方案：服务网格上报RPC指标
- 演进方向：极端场景的处理成为可能
- 缺点：时序数据库压力较大、动态权重决策中心职责越来越多，迭代->变更->风险
自适应动态权重Release
- 演进方向：
- 微服务化
- 引入消息队列削峰、解耦
- 离在线链路切分
- 梳理强弱依赖
总结
- 没有最好的架构，只有最合适的架构。
- 如何做架构设计：需求先行->业界调研->技术选型->异常情况
