容器化过程记录：稳定性提升和利用率提升

容器化过程记录

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

容器化

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

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

稳定性提升

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

1. 调用量波动较大的服务由于频繁扩缩容导致业务失败
2. 一些客户传的大图在低核容器上处理效率较低
3. 集群资源紧缺导致的容器无法按需扩容等。

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

灵活使用探针

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

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

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

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

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

针对大图进行筛选适配

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

多集群部署

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

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

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

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

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

利用率提升

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

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

成果