导语

为了满足AI能力在公有云SaaS场景下，服务和模型需要快速迭代交付的需求，保障服务在不稳定高并发时的高成功率，以及进一步提升资源利用率，AI应用产品中心进行了一系列的调研与实践，本篇将重点介绍团队在容器化方面的实践经验。

背景和问题

公有云AI SaaS产品（如人脸融合[1])的一般服务流程为：C端或B端客户通过采集设备采集图像、音视频等，经由云API等接入方式传入，服务端利用强大的计算能力、充足的资源和相对成熟的算法对客户输入的多媒体内容进行处理。

如上图所示，对于一般流程来说，我们面临着三个挑战。

1.采集质量不稳定：由于采集设备之间存在差异，采集到的质量也会存在差异，拿图像处理来说，大图和小图会给我们的服务带来不同的压力，有时服务会因为集中的大图并发产生失败。

2.短期、高并发需求多：我们的客户会用我们的能力实现不同的玩法，使用人脸融合来进行游戏活动宣传就是一个很常见的运营手段，但是这种活动会给我们的服务带来短期内的高并发压力。

3.模型、服务迭代快：AI SaaS服务的竞争非常激烈，经常会有客户提出新的需求，加上算法难免会有badcase，所以我们的服务也要进行很频繁的升级迭代。

我们再来看下我们容器化前的精简架构（如上图所示），物理机的开发部署大背景下，我们的逻辑服务不论是结构上还是基础上都属于大泥球模式，另外算法服务也常有混布的现象存在。

这种架构也导致了忙时服务间抢占资源的情况频繁发生，影响服务成功率及耗时，导致我们没有办法很好的满足客户的需求；而闲时资源利用率非常低，容易造成资源浪费。

以两个实际的例子来说明：

升级发布时，我们需要先从LB中剔除一个节点，并在节点上观察没有流量进入后进行服务升级。升级完成后，人工对服务进行成功性检测，检测结果OK后再加回LB中。

客户搞活动时提出高并发需求，如果当前物理机/vm资源池不满足，需要向资源同学紧急提物理机需求，资源同学协调到机器后，我们需要人工对机器环境/网络重新初始化，然后执行上述1操作。待活动结束后机器闲置，易造成成本浪费。

为了更好的满足客户不断迭代的需求，减轻研发的运维负担，补齐弹性能力和接入高效的服务管控平台对我们来说是迫切需要的。趁着公司推动上云的时机，我们对架构组件进行了几轮调研和优化。本文主要对容器化过程进行阐述。

容器化过程记录

我们的容器化上云到现在为止可以分为三步：容器化，稳定性提升和利用率提升。

容器化

这里的容器化映射到业务上来说，除了将服务载体由物理机迁移到容器上，更主要是将原来的复杂逻辑解耦，微服务化。

如下图所示，我们先对服务本身做了瘦身微服务化，另外借助于容器的能力，将原来混布的服务彻底分开。如何进行微服务化会因业务的不同存在差异，本篇对此不做赘述。

稳定性提升

在第一步容器化之后，我们很快享受到了飞一般的服务升级和扩容速度。同时对容器化比较浅显的理解也给我们带来了一些新的问题。

1.调用量波动较大的服务由于频繁扩缩容导致业务失败

2.一些客户传的大图在低核容器上处理效率较低

3.集群资源紧缺导致的容器无法按需扩容等。

对于上述三个问题，我们也分别找出了应对方案。

灵活使用探针

起初我们的服务都是没有设置存活和就绪检测（探针[2]）的，Prestop给缩容时加上了一层保护，但是并不彻底，而且在扩容时难免会有服务失败。

探针给我们提供了另一种强大的解决方式。一开始时，我们参照链接中的示例，进行简单的端口检查来判断服务是否正常运行。后来我们发现了更多灵活的运用技巧和使用场景。以下列出几个例子供大家参考以及发散出更多有趣实践。

例子1：在一开始时大家经常遇到LB Agent启动时获取路由必然失败的情况，我们可以使用就绪探针来进行LB的预加载（如下图），即可达到LB获取成功后标记服务启动成功的效果。

例子2：由于一些低版本OS的实例存在弱口令的问题，大家需要把所有依赖旧版OS的镜像全部升级，这个工作对我们来说是及其繁重的，于是我们同样利用了探针，在容器标记服务启动前把弱口令全部干掉。

例子3：某个服务比较特殊，内存占用经常波动，当内存小于某个值时，服务会偶现失败，但是端口正常存活。这时我们可以使用ConfigMap+python脚本来进行一些复杂的检测：

针对大图进行筛选适配

容器化后，我们发现某个算法在接收到高分辨率图片时，服务成功率会出现波动，原因是算法在对提特征时会出现更多的消耗，这一现象在物理机上部署时被物理机核数多的优势掩盖住了，一旦到了核数较低的容器上就显露了出来。为了解决这个问题，我们在上层逻辑中新增了大图筛选功能（如下图所示），如果检测到是大图，则走回物理机集群（由于初始时TKEx提供最高规格容器核数为8核，后来才扩充支持了24核及以上），如果是一般图片，则走容器集群。

多集群部署

在使用TKEx时，我们经常会碰到部署的workload会因为整体集群资源不足的原因，无法扩容到指定的max值，一度非常苦恼。

TKEx的同学也是推荐我们在其他的集群复制一份资源，当一个集群扩不出来时，另一个集群充当备份角色。在这么调整过后，我们的扩容成功率逐步上升。

后来又出现了整个地域的资源都比较紧缺的情况，于是我们把一些对时延不那么敏感的服务进行了多地域部署（如下图），最终将集群资源不足的风险进一步降低。

当一地资源不足的情况下使用多地域部署以及LB时，一般LB都会根据后端响应时间动态调整各节点权重，所以我们应注意以下两点：

关闭就近访问

根据上下游调整LB权重（比如上游服务部署在广州，下游同时部署了南京和广州，这是南京和广州的LB权重分别为130，100）

利用率提升

在进行过一轮稳定性提升之后，我们可以更加自信的利用弹性能力，利用率也有了显著提升。不过依旧有两个问题阻碍着我们的利用率更进一步。一个是有些服务模型大，启动慢，流量突增时服务无法很及时的扩容出来，这时我们必须要提前占用一些资源导致利用率提不上去。

针对第一个问题，我们挑选了部分流量有规律的服务。利用TKE提供的定时HPA能力，在已知流量高峰前定时进行一轮扩容。

成果

当前我们的AI服务已经基本完成容器化的升级。成功率高，扩容快，欢迎大家扫码进行体验。

参考资料

[1]人脸融合:【https://cloud.tencent.com/product/facefusion】

[2]探针:【https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/】