这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记
云计算
- 云计算：是指通过软件自动化管理，提供计算资源的服务网站，是现代互联网大规模熟悉分析和储存的基石
- 虚拟化技术-整租vs合租
- 编排 - 业主 vs 租赁平台
- 架构：
- IaaS（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
- RPC 微服务中间件 RPC vs HTTP：
- 性能
RPC由于通讯压缩，性能往往好于HTTP - 服务治理
RPC具有一定的服务治理能力，熔断、限流、超时控制、负载均衡等。 - 协议可解释性
HTTP具有比较好的可解释性
云原生场景下，微服务大可不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做
服务网格
服务网格：
- 微服务之间通信的中间层
- 高性能网络代理
- 业务代码与治理解耦
相比较于 RPC/HTTP框架：
- 异构系统治理统一
- 与业务进程解耦，生命周期易管理
企业级后端架构的挑战
挑战：
- 基础设施层面
- 物理资源是有限的
- 机器
- 带宽
- 资源利用率受制于部署服务
- 物理资源是有限的
- 用户层面
- 网络开销较大
- 网络抖动导致运维成本提高
- 异构环境下，不同实例资源水位不均
解决方案:离线资源并池:
核心收益：
- 降低物理资源成本
- 提供更多的资源弹性，增加收入 解决思路：离在线资源并池
特点：
- 在线业务的特点
- io密集型为主
- 潮汐性，实时性
- 离线业务的特点
- 计算密集型占多数
- 非即时性
自动扩缩容
- 利用在线业务潮汐性自动扩缩容
扩缩容依据什么指标？ 根据不同场景讨论，一般使用cpu使用量的作为标准，某些内存需求高的服务，也可以使用内存
微服务亲和性部署
- 将满足亲和性条件的容器调度到一台容器
- 微服务中间件与服务网格通过共享内存通信
- 服务网格控制面实施灵活性、动态的流量调度
流量治理
核心收益：
- 提高微服务调用容错性
- 容灾
- 进一步提高开发效率，DevOps发挥到极致
解决思路：基于微服务中间件&服务网格的流量治理
- 熔断、重试
- 单元化
- 复杂环境的流量调度
CPU水位不均
核心收益：
- 打平异构环境算力差异
- 为自动扩缩容提供正向输入 解决思路： COU水位负载均衡
- IaaS
- 提供资源探针
- 服务网格
- 动态负载均衡
后端架构实战
CPU 水位负载均衡，应该如何设计
自适应静态权重
方案
- 采集宿主机物理资源信息
- 调整容器注册的权重
优势：
- 复杂度低
- 完全分布式，可用性高
- 微服务中间件无适配
自适应动态权重 Alpha
方案
- 容器动态权重的自适应调整
- 服务网格的服务发现&流量调度能力 演进方向：
- 解决无法紧急回滚的问题
- 运行时权重自适应 缺点：
- 过度流量倾斜可能会有异常情况
