背景介绍
腾讯云智聆白话评测（Smart Oral Evaluation，SOE）是腾讯云推出的中英文语音评测产品，支撑从儿童到成人全年龄掩盖的语音评测，供给单词、语句、段落、自由说等多种评测方法，从发音精准度、流利度、完整度等全方位打分机制，与专家打分类似度达 95% 以上，可广泛运用于中英文白话教育场景中。
在降本增效的大环境下，事务活跃寻求本钱更优的处理计划，且因为现已积累了 IDC 物理机、云上虚拟机和云上 Serverless 容器服务等多套布置环境，事务架构十分臃肿，运维难度十分高，事务急需一套更加一致的计划下降体系复杂度。
问题与应战
产品侧的降本诉求
问题
在当时降本增效大环境下，怎么操控产品本钱成为一个越来越重要的命题，阅历了两个开展时期后，咱们不得不试着上手抽丝剥茧，测验处理这个问题
应战
因为事务开展前史及事务架构原因，当时资源 buffer 较多，资源运用率较低，体系本钱居高不下，主要有以下两个问题
扩容本钱十分高 – 因为本身是 AI 评测类事务，依靠很多 GPU 资源，而 GPU 机器从资源申请到交付，再到服务布置调试与流量接入，周期通常是天级的，无法应对迟早顶峰的尖峰流量，所以需求为顶峰期预留很多 buffer
资源流通功率低 – 一起事务侧存在中英文评测服务，AI 引擎是两套模型，而模型间的布置切换本钱也比较高，这也导致咱们需求预留双份的 buffer
客户侧日渐丰富的流量模型
问题
日渐丰富的事务场景 – 在工作日非工作日、迟早顶峰和中英文评测的多种条件组合下产生了十分多场景，经过提早备量去 cover 所有场景本钱是不行行的
无法预估的事务增量 – 部分客户的量受疫情影响十分大，且经常是不行预期的，客户自己也无法预估评测用量会到达什么量级，这也导致咱们无法精准地提早备量
削不掉的尖峰流量 – 部分客户存在十分显着的尖峰流量，用户会集中在晚顶峰的某几个时间点进行评测，尖峰流量通常是平峰期的10倍以上，且客户依靠实时成果返回，无法经过异步评测的方法削峰
应战
运维难度高 – 当时架构下无法支撑事务侧高效地进行资源流通、更无法快速完结弹性扩容
服务质量难保障 – 引擎服务毛病节点除掉依靠人工操作，无法快速完结毛病自愈；引擎服务布置方法多样，物理机/虚拟机/容器计划并存，无法搭建一致的可观测体系
3. 新架构
需求
**资源利旧：**事务侧绝大部分机器还在 IDC 物理机房，且物理机性价比高于虚拟机，上云过程中希望能把这部分机器运用起来，下降全体本钱
**网络连通：**云上云下服务网络需打通，且事务侧跨地域调度流量容灾的需求，引擎层需求能够被多集群接入层拜访。一起，因为不同机型不同标准的引擎层消费才能不同，至少需求支撑自定义权重的静态负载均衡战略
**拥抱云原生：**晋级体系架构，落地混合云计划，全面拥抱云原生。云原生生态下现已有十分多最佳实践与处理计划，事务面对的许多问题在云原生场景下都能找到很好地解法，把事务搬迁上云不是意图，上云是更高效、高雅的处理事务面对的服务扩缩容、服务毛病自愈、服务可观测等问题的手法
选型 – TKE 注册节点集群
才能介绍
注册节点（原第三方节点）是腾讯云容器服务团队针对混合云布置场景，全新晋级的节点产品形态，答运用户将非腾讯云的主机，托管到容器服务 TKE 集群，由用户供给核算资源，容器服务 TKE 负责集群生命周期办理。事务侧能够经过注册节点的特性，将 IDC 主机资源增加到 TKE 公有云集群，保证在上云过程中存量服务器资源得到有用运用，一起支撑在单集群内一起调度注册节点、云上 CVM 节点及云上超级节点，便于将云下事务拓展至云上，无需引进多集群办理。
增加了注册节点的集群，或许包括很多不同网络环境的核算节点，如 IDC 网络环境和公有云 VPC 网络环境的核算节点。为了屏蔽底层不同网络环境的差异，TKE 容器团队推出了依据 Cilium Overlay 的混合云容器网络计划。完结在容器层面看到的是一致的网络平面，使得 Pod 无需感知其是运转在 IDC 的核算节点仍是公有云的核算节点，加上云梯环境与内网环境本就是互通的，这也就奠定了智聆事务上云选型的根底
TKE注册节点架构
（图自[注册节点-网络方法]官网文档：cloud.tencent.com/document/pr…
事务架构计划
在新架构各层布置方法较平台期时期都有了较大改动：
1、接入层布置在超级节点上，充分运用资源弹性才能；
2、引擎层服务经过不同的 Deployment 布置在 IDC 节点、CVM 节点和超级节点上，均以 Pod 的方法对外服务，屏蔽掉布置环境的区别；
3、依据第二点移除了 Serverless 容器服务 Pod 的流量接入层，削减一次转发，优化流量调度。
流量途径
客户流量就近接入云 API 网关后，云 API 网关经过北极星姓名服务进行服务发现，完结流量就近接入事务侧 CLB。事务侧 CLB 直连接入层 Pod，流量到达事务侧后，接入层服务再次依据姓名服务经过北极星进行服务发现，获取 RS IP 后恳求引擎层消费。新计划在接入层屏蔽了引擎布置环境和各资源池的区别，接入层仅经过装备去北极星获取对应 RS IP 后恳求即可，下降了流量调度的复杂度
服务布置
接入层
接入层经过节点亲和性调度至超级节点布置，经过 HPA 装备运用云上弹性扩缩容才能进行削峰填谷，比照布置在 CVM 节点上的计划有以下几个优势
1、扩缩容更便利、更活络。若布置在 CVM 节点上需求装备 Cluster Autoscaler 运用，需求先扩容出 CVM 节点，再扩容 Pod，耗时会到达分钟级，而超级节点能够完结秒级扩容
2、本钱更优。CVM 节点参加集群后需求扣除集群办理预留的部分，且集群组件本身有超10个 DaemonSet，也会额定再占用一部分资源，实际资源运用率显着低于超级节点
3、办理复杂度更低。不需求保护节点资源，超级节点可按需增加，依据事务状况灵敏调整
引擎层
引擎层则需求充分运用 TKE 集群注册节点才能，经过节点亲和性装备分别布置在 IDC 节点、CVM 节点和超级节点上，其中 IDC 节点为利旧资源，CVM 节点为后续常备的根底资源，超级节点为弹性伸缩资源
已然前面接入层布置时讲了那么多超级节点的优点，那引擎层布置时为什么又需求 CVM 节点呢？
**本钱更优：**引擎服务不仅依靠于 GPU 资源，对 CPU/MEM 也有高的需求，而超级节点支撑的 GPU 节点标准有限，推理型 GI3X 机型相对于 Serverless 容器服务 弹性出来的 T4 卡标准具有更强的 CPU 和更多的 CPU/MEM 配比，对于事务侧的性价比更高。
服务发现
北极星
接入层与引擎层全体均凭借北极星进行服务发现，但依据接入层与引擎层需求选取了多种露出服务的方法。
接入层
接入层经过内网 LoadBalancer 型 Service 露出服务，北极星绑定 LB IP。事务还选用了 LB 直连 Pod 的方法削减 NodePort 转发，这里其实最开始没有选用直连的方法，也是踩了个坑，后文中会说到。
引擎层
IDC 节点与 CVM 节点上的引擎容器经过 Docker Host Network 网络方法与节点共享网络堆栈，使得容器露出端口可直接映射到节点上，故北极星直接绑定 Pod IP（也是节点 IP）即可，而超级节点上的 Pod IP 为真实的内网 IP，也能直接在北极星上绑定 Pod IP，经过这样选型能够屏蔽掉 Pod 调度到不同节点上的差异，一致上报为容器 IP。
事实上如果要完结以上作用计划是比较多的，这里也大致比照了下，能够依据实际状况进行挑选。事务侧刚好单个 IDC/CVM 节点仅运转一个引擎 Pod，且节点上也不会再运转其他服务，故不存在端口争用的问题，比照下来事务侧挑选了功用更优，施行也更为简练的 hostNetwork 计划。
| 完结计划 | hostNetwork | hostPort | NodePort Service |
|---|---|---|---|
| 备注 | – | – | 需装备增加以下装备避免流量调度至其他 Node上 .spec.externalTrafficPolicy: True |
| 优点 | 功用最优 | – | 运用广泛，也是 K8s 官方更引荐的计划不存在端口争用的问题，支撑一个 Node 上运转多个 Pod 的状况 |
| 缺点 | 或许存在端口争用的问题 | 或许存在端口争用的问题； 需求事务侧自行保护 Node 与 Pod 的映射联系； 多一次转发，会有必定的功用损耗 | 需求事务侧自行保护 Node 与 Pod 的映射联系； 多一次转发，会有必定的功用损耗 |
服务运维
灰度发布
接入层
前文中说到运用 Service 来露出接入层服务，而 Service 经过 Label Selector 来选取 Pod，咱们能够经过两个 Deployments 来办理这组 Pod，然后经过调整 Pods 数量来调整流量份额，从而完结灰度发布的功用。
需求关注的是咱们选用 LB 直连 Pod 的计划，这种计划下默认仅在 Pod 被删除后才会从 LB RS 中移除，为完结服务高雅停机需新增两条装备，这样在 Pod 处于 terminating 状况时就会把 CLB RS 的权重调0，避免流量持续接入。
kind: Service
apiVersion: v1
metadata:
annotations:
service.cloud.tencent.com/direct-access: "true" ## 开启直连 Pod 方法
service.cloud.tencent.com/enable-grace-shutdown: "true" # 表明运用高雅停机
name: my-service
spec:
selector:
app: MyApp
引擎层
引擎层的完结更为简略，前文中也说到引擎服务的注册与反注册是由服务本身完结的，咱们只需求与接入层一样调整两组 Deployment 的数量就能完结灰度份额操控。
服务可观测
日志
日志计划一致运用 CLS 收集，并且经过 CLS 跨地域收集的功用收集至同一个日志 topic 中进行检索剖析，简化现网日志检索复杂度。
监控
监控计划一致为云监控计划，经过云 Prometheus 收集根底目标及事务目标进行展现剖析，削减多套监控体系学习与保护本钱。
根底监控 – 云 Prometheus 接入集群监控后自带多个面板，根本契合需求，事务侧只需求完结 GPU 数据的收集上报即可。
事务监控 – 事务侧引进 Prometheus SDK 露出并装备 job 进行收集即可。
告警
告警计划也一致为云监控告警，凭借云监控的才能掩盖邮件、企轻轻信、电话等多种渠道，削减告警渠道保护本钱与多套告警规矩装备学习本钱。
反常节点除掉
当 Pod 反常时应该及时切断流量，保证流量不会持续进到反常pod内导致现网服务受损，供给两种计划，经调研事务侧挑选计划二：
计划一：Liveness Probe
装备存活探针，事务健康检查反常时直接杀死 Pod，而后进入上文说到的 Pod 高雅退出流程，阻断流量进入反常 Pod。
计划二（引荐）：Readiness Probe + Readiness Gate
装备就绪探针，事务健康检查反常时将 Pod 状况置为 Not Ready，合作 ReadinessGate 机制，当检测到 Pod 状况为 Not Ready 时将相应 LB RS 权重调0，阻断流量进入反常 Pod。
该计划的优点是能够保留事故现场用于 debug，便于快速定位问题，合作云监控告警即可完结快速感知。
调度计划
服务调度-动态扩缩容才能
事务侧之所以挑选自研 scheduler 服务是因为事务侧有灵敏的扩缩容诉求，除了惯例的 HPA&HPC 的才能，scheduler 服务还有以下功用：
1、HPA&HPC 规矩均作用于资源池等级，原生 HPA&HPC 仅支撑 Deployment/StatefulSet 等级；
2、事务侧有资源流通的需求，如北京地域早顶峰中文评测的量很高，而英文早顶峰相对较低，需求支撑经过调整中英文引擎 Pod 数量的方法进步资源全体运用率；
3、事务侧有保障扩容成功率的需求，因为事务侧需求的 GPU 资源数量较多，故需求经过切换标准和切换地域等方法进步扩容成功率。
流量调度-资源阻隔
引擎层资源阻隔凭借北极星动态路由的才能完结，服务（大池子）、别号（公共池/各大客户专有池）和别号路由（池子划分规矩）需求提早创立好。自研 scheduler 服务依据装备为引擎 Pod 打标并注入别号列表，接入层在拿到对应别号后向北极星获取 RS IP 恳求即可，不需求感知流量路由到哪个池子。
前置工作
1、创立一致的北极星服务；
2、创立各资源池北极星别号；
3、在北极星服务下创立各别号路由规矩，选取对应 label 的 RS。
引擎发动注册流程
1、引擎服务发动后自行注册至一致的北极星姓名服务下；
2、scheduler 服务监听到存在未打 label 的 RS 则依据规矩及各资源池当时负载状况进行打标，用于标记是哪个资源池；
3、scheduler 服务依据规矩判断当时资源池是否收效，若收效则注入接入层拜访引擎层的别号列表。
用户恳求流程
1、接入层获取别号；
2、接入层经过别号向北极星获取 RS IP；
3、接入层恳求 RS IP。
取得作用
降本增效
服务扩容到流量接入耗时优化至分钟级，自研 scheduler 服务结合 EKS 弹性扩容才能进行削峰填谷，下降超30%体系本钱，节约2个运维人力
自研 scheduler 服务进行资源流通，早顶峰期将闲置的英文节点资源转换为中文节点资源，削减北京地域近90%早顶峰扩容需求
（上图是优化后作用，早顶峰仅扩容少数资源，下图是优化前作用，早顶峰需求扩容很多中文节点）
服务质量提升
接入层反常节点除掉
接入层经过事务侧装备的 Readiness Probe 勘探服务存活，当心跳失败时合作 ReadinessGate 机制将 CLB 中对应 RS 的流量路由权重置0，以此完结反常节点自动除掉，保障现网服务质量
引擎层反常流量除掉
引擎层经过北极星心跳上报的方法勘探服务存活，当心跳失败时北极星自动将对应 RS 状况置为反常，以此完结反常节点自动除掉，保障现网服务质量
过程遇到的问题
大集群计划未能完结
希望
最初想象是由一个 TKE 集群纳管所有节点（IDC 节点、云上 CVM 节点、云上超级节点），以此来简化全体服务布置，进步集群间资源流通功率，进一步下降全体计划复杂度。
问题
当时集群暂不支撑绑定多地域 CLB，也暂不支撑参加多地域超级节点，导致无法完结服务就近接入和弹性多地资源。
妥协计划
当时单地域大集群的计划，各地域均布置一个集群。
5.2. CVM转发功用瓶颈
问题表现
顶峰期呈现 connection reset by peer 的报错，报错份额低于0.01%，经排查均来自某个 CLB IP。
问题成因
检查 CLB、Pod 的监控均正常，在 Pod 内布置抓包也没发现反常的握手恳求，而且事务侧 LB 是内网四层 LB，当时流量应该远没有到达 LB 的功用瓶颈。
正在束手无策之际开始重头排查整条链路，发现事务虽然挑选的是 LB 型 Service，且 Pod 布置在超级节点上，但是 LB RS 却是 CVM 节点，流量仍是经过 NodePort 的方法进入集群，再由 K8s 内部网络转发至对应服务 Pod，接入层 Pod 能够凭借超级节点的才能弹性扩缩容，但是 CVM 节点数量却是固定的，就成为了体系的功用瓶颈。
知道有这么条链路之后再登录 CVM 节点验证，发现确实是 CVM 节点的连接数被打满了，导致部分连接被拒绝。
（图自容器服务官网文档）
处理计划
到这儿处理计划也十分清晰了，凭借 TKE 供给的 CLB 直连 EKS Pod 的才能去掉 NodePort 转发，流量均匀的打到 Serverless 容器服务 Pod 上， Serverless 容器服务 Pod 又能够弹性扩缩容，以此就处理了功用瓶颈的问题。
（图自容器服务官网文档）
总结
在不同的事务开展阶段需求挑选适宜的架构，没有完美的计划，需求随着技术迭代不断调整，抱残守缺只会让研制成为事务的短板。事务上云终究导向都应该是事务成功，服务于降本增效、进步服务质量等目标，上云后事务能够背靠腾讯云，凭借各云产品强壮的才能快速完结事务需求，下降技术运用门槛。