哈啰云原生架构落地实践

2024-03-27 架构

一、弹性伸缩技术实践
1.全网容器化后一线研发的使用问题

文章插图
全网容器化后一线研发会面临一系列使用问题，包括时机、容量、效率和成本问题，弹性伸缩是云原生容器化后的必然技术选择。
2.使用原生弹性HPA遇到的问题

文章插图
当时第一时间考虑用原生HPA组件，但在实际调研和小规模使用的时候发现了很多问题。一方面是内置的问题，如原生不支持自定义指标和定时扩缩容，使用率计算基于resources.requests，使用单个Goroutine执行。更大的痛点在业务场景上，微服务在线实例拉出状态，特殊业务Job任务实例不能中断，要考虑下游DB层可用性。
3.基于业务实例实际水位、有效负载的弹性能力

文章插图
我们基于业务实例实际水位、有效负载构建弹性能力。

高低双阈值控制，像一些有浮动的业务，可以尽量把底层的稳定性去做有效的约束；
最大可用原则，扩容用Ceil向上取整，缩容使用Floor向下取整；
数据降噪，去除实例状态不ready的，去除强业务关系的实例计算，应用启动毛刺问题缓解， metrics空值、获取不到值；
性能增强，按业务namespace监听，实现并发度控制。

4.水位阈值弹性和定时弹性的融合实现

文章插图
这里同时做了水位阈值弹性和定时弹性的融合，保证单个的应用能够同时使用阈值和定时弹性。基本原则是扩容时大者取大，缩容时不能低于定时副本数。
5.业务使用弹性后的生产效果

文章插图
业务使用弹性后产生了一定的效果，如图是高低阈值和定时的区间。这里解决了一些问题：

代码预热，在高峰前准备就绪；
周期性波动型应用变更明显减少；
应用冗余减少，业务“初见原型”；
突发流量应对，稳定性提升；
告警、应用状态可控性。

最终弹性接入90%以上，扩缩容消息触达率100% ，业务可用算力增加了 30%以上。
6.混合云模式下的 ClusterAutoScale

文章插图
集群可用资源变多，不等于整体开支降低，因此我们考虑去做混合云模式下的ClusterAutoScale 。这里有一些关注点，包括镜像即服务、CloudProvider 适配、节点初始化和节点回收。

文章插图
右图是基本流程，有两个触发策略，一是基于不可调度事件，二是基于资源池水位阈值。这里我们也解决了一些问题，包括 CloudProvider 对接私有云资源API，Pod网段分配域路由宣告，私有云可用容量评估及资源打散，以及资源灰度回收逻辑。
7.注意事项

文章插图
在实际业务时生产使用的时候，有很多关注点，包括业务池的容量、应用维度的实例波动率标准、存活探测和就绪探测的接口区别、指标阈值和弹性规则的合理性巡检、不做过多filter、不强依赖其他系统平台。
二、中间件容器化及混部填谷
1.业务独立池水位与混部预期

文章插图
针对业务特性，将redis和flink资源池进行融合，达到分时复用的效果。之前的形态会带来很多问题：

每种业务独占一个资源池或集群，产生大量资源碎片，造成成本浪费；
多个集群多个对外API，数据需要多次聚合计算；
各业务池服务器规格不一致，运维管理复杂。

2.混部的总体思路

文章插图
混部里面这里做了一些思考，考虑了应用分级、资源需求、潮汐分布等等。将这些因子抽象归纳，分为应用分级、混部调度、资源QOS三层。我们也确定了几个总体方向，包括服务资源保障的策略实现和资源分配决策的算法实现。

文章插图
在服务资源保障上，主要是对应用分级打标。我们把所有的业务做了S1-S4的分级，并落到了CMDB里，最终落到K8S的优先级标签里面。第二部分是资源池化，优先去考虑以底层的业务为重保，把一些优先级较低的应用分别打散到各个资源池。

推荐阅读

上一篇：跳转链接代码怎么写？

下一篇：大模型应用的 10 种架构模式