稳定、可控、高可用：运维最应该加持哪些技术 buff？

如何保障开发需求高效交付，系统高峰扛得住、长期平稳，是项目组中的每位技术人必须面对的问题。

本文大纲

1、强稳定性Buff
2、风控服务实时性Buff
3、高资源利用率Buff

1.强稳定性Buff

强稳定性背后有三大挑战，其一是应对发布变更引起故障问题的挑战，从历史数据中得知，70% 以上的故障都是由于变更引起的。做好变更管控，就能减少大部分的故障。

其二是保障跨云网络链路持续可用的挑战。TT语音业务采取跨云部署策略，实现跨云容灾价值的同时，也对跨云流量治理提出更高的要求。当跨云之间发生网络波动或者中断时，将造成业务波动或不可用的后果。

其三是面对故障的快速响应的挑战，就算有再优秀的架构、再完美的设计，故障始终难以全部避免。当故障真正发生时，做到故障问题的快速感知、快速定位和快速恢复，是保障业务稳定性的关键一环。

1.1 加强变更管控管理

通过系统化的手段来管理是最理想的方式，包括发布时间（如规避业务高峰期），发布方式（如灰度），验收及回滚等。当企业底层基础服务和中间件服务的系统化建设处于尚未完善的阶段，通过设定变更管控的规则，严格控制变更的需求，强化变更人员的意识，是较为有效的举措。

对于成本优化、统一网格服务化治理所需的架构改造，以及容灾演练活动等进行严格的评估，避免突然变更。同时，技术团队制定重大变更执行方案评审机制、对所有变更执行变更通知规范性检查，以及执行高危命令审计及预警切实保障变更的规范性。

1.2 保障跨云链路高可用

基础架构团队设计了多云互联互通的多条专线和多条 VPN 线路互相备份方案。具体而言，当专线链路不可用时，自动实现通过 VPN 线路承载全部业务流量。该方案有几大特点：

• 基于 BGP 协议实现秒级自动切换
• 多条 VPN 线路实现负载均衡
• 专线线路恢复后 VPN 流量自动切换回专线

通过以上举措，TT 语音年度盛典项目组的技术团队实现了不同云厂商的互联互通高可用，该技术方案在行业内处于较为领先水平。

1.3 提高运维保障能力

AIOps 监控感知问题

当出现故障时，快速感知是故障处理的关键能力。以往，技术团队采用比较传统的手段，针对不同级别的应用和基础组件，通过阈值调优，增加监控项等手段精细化管理。

为了更快更全面的感知用户侧问题，今年盛典期间，技术团队引入 AI 算法能力，通过文本识别和 NLP 语义理解，在用户反馈侧提前感知故障问题，大大提高了故障处理的效率。

强化故障处理意识

采取“多沟通多同步勿慌乱”以及“先恢复快止损后根因”两大策略，从人员意识上，提升故障定位和恢复的执行力。

云商风险识别治理

技术团队完成了云商迁移，所有流量第一次全部承载在一个全新的基础设施上，其风险不言而喻。为此，与云厂商技术团队深入合作，系统性地对云服务进行风险识别和治理，共发现风险41个，并完成了36个风险治理，将故障隐患提前消除。

2. 风控服务实时性Buff

合规安全是当前业务的底线和生命线，实时风控与业务流程强绑定，一旦风控服务实时性差或不可用，直接导致用户体验差或者业务不可用。业务侧对于风控的实时性，也提出了明确的技术指标：99.5% 的请求在 200 毫秒内响应。

为保障风控合规能力的实时性，大数据团队需通过存算分离、数据分级、服务降级三个方面来保证每天上百亿行为实时计算和服务。因此，在海量数据场景中，保障风控服务实时性及可用性是个巨大的挑战。

2.1 存算分离

故障随时随地迁移，不影响数据实时性

采用 on K8S 的架构方案，计算应用 docker 化运行在 k8s 环境，实现了计算逻辑和计算资源的解耦。同时引入对象存储来存储计算状态，解决资源迁移时可随时随地读取计算状态的问题。最终实现计算和存储能力的可迁移可扩展性，应对突发的大计算资源水平扩展及节点异常自动迁移。

2.2 数据分级

根据数据和业务场景分级优化，提升存储查询引擎响应性能

面对风控识别高并发(30KQPS)的请求，服务过程中同时涉及多用户多特征(全平台亿级用户 300+ 维特征)更新，大数据团队根据数据热度和实时程度对数据进行分级处理。

• 活跃用户特征存储在内存 KV 库，全量用户特征存储在分布式 NoSQL KV 库；
• 实时性高的使用 Pipline 方式微批更新到内存 KV 库，实时性低的数据以文件形式批量更新到分布式 NoSQL KV 库，以此来降低更新数据带来的压力；

通过优化数据分区算法，数据分布更均衡大幅提升并发查询性能。

2.3 服务降级

数据服务链路解耦，极端情况可实现降级保障稳定性

风控服务链路分为用户特征计算、用户特征更新及风控识别服务。

• 特征计算利用流平台和大数据 IDP 平台灵活定制特征；
• 特征更新集中作业统一优化更新数据到 KV 库；
• 风控识别服务采用分布式+异步查询+默认特征兜底，保障服务高可用。

大数据生产和服务技术组合多且复杂，为了避免极端情况，风控服务不可用的情况，首先整体服务采用异步式架构解耦相互关联性，其次在无关性的基础上，可根据下游压力情况灵活调整上游策略。若 KV 库负载压力大，可降低数据更新频率降低负载；若极端情况 KV 库全部宕机，服务仍在线，保障业务过程不受影响，对用户无感知。

通过以上优化，盛典期间零故障，99.9% 服务响应在 50 毫秒内，大幅提升用户使用产品的体验。

3.高资源利用率Buff

在保证业务稳定的情况下尽可能降低成本，需要提升资源的利用率。具体来说，技术团队需要提升应用服务 Pod 利用率和容器 Node 节点的分配率，达成节点利用率的提升。而资源利用率越高，服务受负载影响导致业务受损的可能性就越大。

因此，在不降低稳定性的前提下，最大限度的节省资源成本，是资源调度平台面临的较大挑战。

3.1 提高应用的资源利用率

3.1.1 应用弹性伸缩

应用资源的弹性伸缩是当前云原生架构下常见的提升利用率的手段，得益于技术团队较早在云原生领域探索，应用的云原生化覆盖率比较高，95% 的应用具备弹性伸缩的能力。

然而，弹性伸缩若太频繁，也将对服务稳定性造成威胁。为了提升应用利用率资源，同时兼顾业务稳定性，需要设置合理的 Pod 资源申请与 HPA 的阈值。

• 案例分享

有一个关键的业务 Pod，由于红框标记部分为 HPA 和 request 值设置不合理导致的频繁伸缩，不仅影响资源利用率，同时也为业务稳定带来影响。

图1：某业务优化前的应用负载趋势图

如图，红框标记部分为 HPA 和 request 值的不合理设置。技术团队根据自己的业务情况特征建立了一套 Pod 资源申请模型，解决应用资源的不合理使用问题，最大化应用资源利用率，集群应用 CPU 均值利用率达到 57%。

3.1.2 应用定时伸缩

对于赛事活动，会遇到突发流量，往常的做法是人工提前扩容，以应对高峰期的访问压力，使服务保持稳定。人工扩容比较繁琐、低效且有一定的浪费。技术团队针对突发流量，上线了定时伸缩策略，较好地解决业务稳定性。同时，精准的定时伸缩策略，也进一步提升了资源利用率。

如下图，通过采用定时伸缩方案，在业务突发流量到来前，提前扩容。

图2：优化后的应用负载趋势图

如下图，从业务指标看，较好地解决了突发流量带来的异常。

图3：接口页面指标检测图

3.2 提升 Node节点的分配率

3.2.1 集群节点弹性伸缩（定时伸缩）

借助于云商的 CA （集群自动扩缩）能力，技术团队在所有集群上开启了这个功能。然而，当存在突发流量时，集群节点资源无法满足业务需求，此时 CA 扩容需要 5 分钟。

• 案例分享

如下图所示，节点扩容时间晚于业务峰值时间。

图4：业务峰值时期的应用负载趋势图

由于节点扩容不及时存在瞬间失败的情况，一般应对手段是准备更大的集群空闲资源，但造成资源一定程度的浪费。如下图，由于节点扩容不及时，出现访问异常数升高的情况。

图5：接口页面指标监测图

为此，开启了集群节点的定时伸缩机制，在 20:00 和 00:00 两个高峰期提前扩容节点，解决了服务瞬时失败问题，同时提升节点的资源利用率。

图6：集群节点趋势图

3.2.2 优化机型配置

Kubernetes 是基于 Pod 的 request 资源进行调度的，任意一种资源不满足 request 就不会把 Pod 调度到该节点。为了提升节点的分配率，减少资源碎片化，节点的机型选择就需要一定的技巧。

• Pod 申请的 CPU 和 MEM 的比例尽可能跟 Node 的 CPU 与 MEM 的比例接近
• Pod 的 CPU 和 MEM 的使用尽可能和申请资源的比例接近

*注意：这里统计的是整个集群的 Pod 情况，不针对单一 Pod。

技术团队根据历史业务对 CPU 资源与 MEM 资源的需求情况，选择最配匹的 Node 机型，将全部集群的分配率提升到 85% 以上，尽可能减少了无法分配的资源碎片。

3.3 离在线混部

行业内都知道，分时复用是提升资源的利用率有效手段，将离线和在线业务负载时间段正好错开，是分时复用的最佳场景。

离在线混部系统是基于业务特征设计的一套调度系统，主要实现包含基于实时资源感知的动态调度算法、离线 Pod 调度算法、基于优先级的 Pod 资源隔离方案、 Node 资源过载干预方案等。此系统在保证在线业务 SLA 的情况下，充分利用 Node 空余资源。

来源：本文转自公众号“码上跃见”