本周我感染了新冠病毒，一共在家待了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占用率双高的情况也很少再出现。
