3.2 离在线资源并池

核心收益: 降低物理资源成本 提供更多的弹性资源，增加收入 解决思路:离在线资源井池 在线业务的特点 10密集型为主 潮汐性、实时性 离线业务的特点 计算密集型占多数 非实时性

问题:同一个机器怎么做离在线隔离?

3.3 自动扩缩容

核心收益: 降低业务成本 解决思路: 自动扩缩容 利用在线业务潮汐性自动扩缩容 问题:扩缩容依据什么指标?

3.3 微服务亲合性部署

核心收益: 降低业务成本 提高服务可用性 解决思路:微服务亲合性部署 将满足亲合性条件的容器调度到一台宿主机 .微服务中间件与服务网格通过共享内存通信 服务网格控制面实施灵活、动态的流量调度

3.4 流量治理

核心收益: 提高微服务调用容错性 容灾 进一步提高开发效率，DevOps 发挥到极致 解决思路:基于微服务中间件&服务网格的流量治理 熔断、重试 单元化 复杂环境(功能、预览)的流量调度

3.5 CPU水位负载均衡

核心收益: 打平异构环境算力差异 为自动扩缩容提供正向输入 解决思路: CPU 水位负载均衡 laaS 提供资源探针 服务网格 动态负载均衡

04. 后端架构实战

4.1 问题背景

兰师傅蛋糕店也碰到了类似的问题: 不同师傅干活的效率差距较大 有些师傅希望「能者多劳多挣」 在这个背景下，继续像之前一样为每个师傅分配完全相同的工作，会引起他们的不满。 回到03最后的挑战一CPU 水位负载均衡，应该如何设计? 1.需要哪些输入? 2.设计时需要考虑哪些关键点?

问题提炼

输入: 服务网格数据面 支持带权重的负载均衡策略 注册中心存储了所有容器的权重信息 宿主机能提供 容器的资源使用情况 物理资源信息(如CPU型号) 关键点: 紧急回滚能力 大规模 极端场景

4.2 自适应静态权重

方案: 采集宿主机物理资源信息 调整容器注册的权重 优势: 复杂度低 完全分布式，可用性高 微服务中间件无适配成本 缺点: 无紧急回滚能力 缺乏运行时自适应能力

4.3 自适应动态权重Alpha

方案: .容器动态权重的自适应调整 ●服务网格的服务发现&流量调 度能力 演进方向: ●解决无法紧急回滚的问题 运行时权重自适应 缺点: 过度流量倾斜可能会有异常情况

4.3 自适应动态权重Beta

方案: 服务网格.上报RPC指标 演进方向: 极端场景的处理成为可能 缺点: 时序数据库压力较大 动态权重决策中心职责越来越 多，迭代-变更-风险

4.4 自适应动态权重Release

演进方向: 微服务化 引入消息队列削峰、解耦 离在线链路切分 梳理强弱依赖

1.没有最好的架构，只有最合适的架构 2.如何做架构设计 需求先行。弄清楚要解决什么问题 业界调研。业界都有哪些解决方案可供参考 技术选型。内部/社区都有哪些基础组件 异常情况。考虑清楚xxx不行了怎么办 3.架构与工程师成长 技术经理 架构师