本周我感染了新冠病毒，一共在家待了 9 天。在此期间，工作上的最主要的事情是评估一 款小程序的推广上线，对我所负责的基础服务体系的影响。这款小程序切中了当时国人的需 求，预计有大量流量涌入，可能对基础服务体系的核心服务造成冲击。原先，他们有也一个 功能将要上线，流量也很大，我已经评估过并且扩容了。但是，这次还是在他们推送了上亿 的量级的通知后，发生了大批量的超时现象。 早上八点钟，躺在床上修养的我就被叫起 来，说是登录接口出现大量超时现象。
我马上拿出笔记本，连上内网一看，这个接口流量直接翻了 20 多倍。我都捏了一把汗，首 先是怀疑业务容器数量不足，无法承接这么大的流量。然后通过筛选日志，发现并不是这个 问题。问题分为两个部分，其一是内部某个接口有限流，当前流量已经超出限流；另一个是 缓存数据库挂接的数据库打满。 内部接口限流比较好解决，通过紧急呼叫找到了对应的同 事调高了限流的阈值。另一个缓存数据库，由于大量老用户涌入导致不断要从数据库中读取 老数据到缓存中，而且频率随着流量的增长不断提升，最终打满了缓存后面挂接的数据库的 I/O。后续针对几个核心的缓存数据库，再次做了一批扩容，提升了缓存容量和节点数量以 应对后续更大的流量和并发。
在日常维护上面，主要是将某个网关服务 Pod 的 k8s 调度策略做了调整，将其调度到由 CVM 虚拟化直接支持（一层调度）的计算节点上。原先，这个服务调度的到的计算节点是我 们公司采购的物理服务器上虚拟出来的 CVM，用作计算节点。调度到这上面以后，再于这个 CVM 上虚拟出一个执行空间（参考 Docker 技术），然后将 Pod 调度到这个节点开始运行 （二层调度）。一个计算节点上，可能存在几个甚至十几个 Pod。这些后台程序都运行于同 一台操作系统中，并且只是执行空间不同罢了。这就导致了 CPU、内存、网卡等资源的隔离 性不强，常常会互相干扰。并且当这台 CVM 计算节点需要重启或者升级的时候，其上的所 有 Pod 都会被驱逐。
计算节点操作系统中的风吹草动，会影响到其上所有 Pod。这对于这种网关这种可靠性和延 迟要求苛刻的服务，来说并不合适。 而一层调度计算节点，其实是由云来分配计算资源并 虚拟出 CVM 来单独执行这个程序，CVM 资源是从整个云资源池中取得。并且这种方式支持 k8s，因为这种新的调度方式会虚拟成 k8s 上的一种“超级节点”。k8s 可以直接将 Pod 调 度到超级节点上，Pod 可以直接基于一层调度运行，也就是直接运行在一个单独 CVM 上。 这种方式隔离性强，互相之间不会受到影响。由于每个 CVM 只运行一个节点，所以当单独 一个 Pod 出现问题时，可以针对这个 Pod 的问题进行修复，而不会影响到其他 Pod。 通 过修改调度策略，将服务的所有 Pod 调度到超级节点后，整个服务运行更加稳定了。在高 峰期超时率和 CPU 占用率双高的情况也很少再出现。