这是我参与「第三届青训营 -后端场」笔记创作活动的的第二篇笔记.
- 本次青训营课程中，微服务架构课程分为上下两篇，这是上篇《架构初探-谁动了我的蛋糕》。后续相关课程有《微服务架构原理与治理实践》。
- 我把《架构初探-谁动了我的蛋糕》的笔记也分为上下两篇。这是下篇，主要介绍了目前企业级架构面临的挑战，以及架构的实战。
- 上篇链接(架构初探-谁动了我的蛋糕 (上篇)| 青训营笔记 - 掘金 (juejin.cn))
话不多说，我们开启本篇笔记~
3.企业级后端架构的挑战
挑战
带来的问题主要有两大块：
1.基础设施层面：
- 物理资源是有限的
- 机器
- 带宽
- 资源利用率受制于部署服务
2.用户层面：
- 网络通信开销较大
- 网络抖动导致运维成本提高
- 异构环境下，不同实例资源水位不均
离在线资源并池
一般线上的业务都具有潮汐性和实时性，它的资源的用量是有时间段的，比如凌晨两点的时候，它使用的资源量就比较少，而到了中午，在线的资源它使用量越来越多。离在线资源并池，可以：
- 提高物理资源成本
- 提供更多的弹性资源
自动扩缩容
核心收益：
- 降低业务成本
解决思路:自动扩缩容
- 利用在线业务潮汐性自动扩缩容
微服务亲合性部署
核心收益：
- 降低业务成本
- 提高服务可用性
解决思路：微服务亲合性部署
- 将满足亲合性条件的容器调度到一台宿主机
- 微服务中间件与服务网格通过共享内存通信
- 服务网格控制面实施灵活、动态的流量调度
流量治理
核心收益:
- 提高微服务调用容错性
- 容灾
- 进一步提高开发效率，DevOps发挥到极致
解决思路：基于微服务中间件&服务网格的流量治理
- 熔断、重试
- 单元化
- 复杂环境（功能、预览）的流量调度
CPU水位负载均衡
核心收益：
- 打平异构环境算力差异
- 为自动扩缩容提供正向输入
解决思路：CPU 水位负载均衡
- IaaS
- 提供资源探针
- 服务网格
- 动态负载均衡
4. 后端结构实战
问题描述：
类比一个蛋糕店来说，不同的师傅他干活的效率实际上还是差距蛮大的。就有些师傅他手脚比较麻利，干活很快，有些可能比较追求极致，所以相对来说干的活比较精细，但是速度没有那么快。对于一种场景，有些师傅他就希望说我干的活比较多，我想多挣点钱。然后那些干的少的同那个师傅可能也觉得我就想少干一点，因为我的身体吃不消，所以说这就是两个非常核心的问题。那在这个背景之下，然后我们如果还按照之前的方式说，你每个师傅都要干相同的工作，那这个他们可能会不满，有些的能力比较强的，她就想多挣钱，她觉得你给我的工作太少了，我太闲了。然后那些能力相对来说干活比较慢的，他就会觉得我太累了，而且工作还做不完，会影响整个的一个效率。所以我们可以带着第三部分的CPU水位负载均衡来看这个问题。
问题提炼：
输入:
- 服务网格数据面
- 支持带权重的负载均衡策略
- 注册中心存储了所有容器的权重信息
- 宿主机能提供
- 容器的资源使用情况
- 物理资源信息(如CPU型号)
关键点：
- 紧急回滚能力
- 大规模
- 极端场景
自适应静态权重
方案：
- 采集宿主机物理资源信息
- 调整容器注册的权重
优势：
- 复杂度低
- 完全分布式，可用性高
- 微服务中间件无适配成本 缺点：
- 无紧急回滚能力
- 缺乏运行时自适应能力
自适应动态权重Alpha
方案：
- 容器动态权重的自适应调整
- 服务网格的服务发现&流量调度能力
演进方向：
- 容器动态权重的自适应调整
- 服务网格的服务发现&流量调度能力
缺点：
- 过度流量倾斜可能会有异常情况
自适应动态权重Beta
方案：
- 服务网格上报RPC指标
演进方向：
- 极端场景的处理成为可能
缺点：
- 时序数据库压力较大
- 动态权重决策中心职责越来越多，迭代->变更->风险
自适应动态权重Release
演进方向：
- 微服务化
- 引入消息队列削峰、解耦
- 离在线链路切分
- 梳理强弱依赖
架构初探-谁动了我的蛋糕全篇总结
- 没有最好的架构，只有最合适的架构
- 如何做架构设计？
- 需求先行。弄清楚需要解决的问题是什么！
- 业界调研。业界都有哪些成熟的解决方案可供参考。
- 技术选型。内部/社区都有哪些基础组件
- 异常情况。考虑清楚xxx不行了怎么办
