背景

云原生（CloudNative）是一个组合词，“云”表示应用程序运行于分布式云环境中，“原生”表示应用程序在设计之初就充分考虑到了云平台的弹性，就是为云设计的。可见，云原生并不是简单地使用云平台运行现有的应用程序，而是一种能充分利用云计算优势对应用程序进行设计、实现、部署、交付和操作的应用架构方法。

上云不等于云原生，阿里亚马逊都推崇：Re-host->Re-platform->Re-architect。将迁移之路分为 3 类：
Re-host：叫新托管，将线下物理机替换成为云上虚拟机或者裸金属实例，不改变原有的运维方式。
Re-platform：叫新平台，指利用托管的云服务替换线下自建应用基础设施，比如通过北极星服务替代TAF主控；通过腾讯云TKEx容器替代MIG的sumera。
Re-architect：叫新架构，包括单体应用的微服务架构改造，应用容器化，利用云上组件完成环境路由和治理，提升开发的效率和自动化率，同时增加业务系统的弹性，可观测性和韧性，最终能按业务需求，支持所需类型下的交付（公有云，私有云，混合云）。

腾讯云也制定了自己的云原生成熟度模型：

腾讯云的成熟度模型，主要从研发效能和资源效能2个方面引导内部云原生建设。云小微在进行云原生建设和实践前，项目的研发效能和资源效能也确实存在诸多问题，例如：

1. 环境缺乏治理。测试、开发环境紊乱、不稳定：多个版本同时进行提测时存在版本互相覆盖，错误路由与指向的问题，极大地影响了开发和测试的效率。生产环境未隔离: 所有租户都使用一套环境，缺少压测环境、灰度环境、KA客户的环境。有时因为一个异常版本，影响到了所有客户，影响了云小微的SLA数据和客户印象。

2. 可观测性差。用户反馈的问题，开发常常需要拉个大群，自上而下卷入很多人进行排查和定位，降低了定位、解决问题的效率。

3. 弹性能力差。云小微的大数据模型服务，启动时需要加载10-70G的大模型数据到内存，因此启动速度、扩容速度较慢。业务高峰期仅依赖HPA来扩容，有时因为扩容太慢导致客户请求失败，影响了云小微的SLA数据和客户印象。

4. 韧性能力差。对服务的韧性没有把握，缺乏系统容灾、服务降级等策略，部分故障无法自愈，手动应对时手忙脚乱。

5. 自动化能力不够。发版没有通用的流水线，需要大量的人工测试、人工确认、人工发布。大量的人工操作，导致发版的流程不规范、效率低，版本迭代慢，无法快速响应线上的问题和客户的需求。

为了改善上述问题，更好地服务TOB客户。云小微团队结合云小微现状以及公司云原生成熟度标准1.0和2.0的导向，横向对比业界做法，重点在云原生5大核心能力上进行了建设：服务化、可观测性、韧性、弹性、自动化能力，并逐步提升可调度能力。

服务化能力建设

随着业务的不断发展，单体应用能够承载的容量将逐渐到达上限，即使通过应用改造来突破垂直扩展（Scale Up）的瓶颈，并将其转化为支撑水平扩展（Scale Out）的能力，在全局并发访问的情况下，也依然会面临数据计算复杂度和存储容量的问题。因此，需要将单体应用进一步拆分，按业务边界重新划分成分布式应用，使应用与应用之间不再直接共享数据，而是通过约定好的契约进行通信，以提高扩展性。而服务数量的增加必然导致运维的成本增加，因此微服务化、容器化和环境治理成为了服务化能力建设的三个重点。

微服务化、容器化

• 传统服务容易出现服务耦合、影响开发速度、增加现网变更的风险等问题。云小微服务进行了比较彻底的微服务化，降低服务之间的耦合度，提升研发效率和质量。
• 微服务数达到了600+个，其中TAF服务400+个，TRPC服务200+个，新服务统一使用trpc。

由于历史原因，云小微的后台服务大部分都是TAF框架的服务，TAF框架对于拥抱云原生存在诸多障碍：

1. TAF框架在2022年已经官方下线不再维护，其对应的周边配套组件仍在继续运行，但不再更新。

2. 可观测性差，无法低代码地接入主流的观测组件（天机阁、TAPM）。有些服务因为TAF CPP接入可观测性组件困难，服务上线2年都无法接入全链路观测。

3. 跟主流的服务发现组件（tracing）结合差，无法低代码实现多环境路由、动态路由。

4. 老服务无法新增监控项，导致监控、告警不完善。

面对这种风险，云小微开始了TAF转TRPC的历程:

1. 新增的服务使用脚手架工具生成，统一使用trpc 框架。

2. 存量的服务，梳理出核心链路，核心链路全部重构成trpc框架。

3. 非核心链路，但是频繁改动的服务也都尽量改造成trpc框架。

目前整体trpc服务整体占比32%，核心链路trpc服务占比80%，继续改造中。

• 600+微服务全面接入腾讯云tkex，实现100%微服务化、100%容器化

环境治理

环境治理可以分为生产环境的治理和测试环境的治理。

生产环境治理

在环境使用过程中，存在诸多问题：

• 灰度环境没有真实的客户流量，无法起到真实的灰度效果。
• 所有客户的生产环境都是一套，一旦版本质量出现问题，直接影响到所有客户，包括KA客户。
• 无法在生产环境上进行压测和混沌。

为了解决上述问题，治理方案如下：

生产环境规划包含：普通客户环境（formal）、灰度环境(gray)、压测环境（prod-stress-env）、KA客户环境（formal-ka-env，暂时没有部署）

• 在生产环境内部署一套完整的服务作为压测环境，使用单独的域名接入。压测环境使用时部署，用完即销。
• 独立部署三套完整的服务，分别作为普通客户环境、灰度环境、KA客户环境。这3套环境使用相同的域名、相同的接入层。在接入层实现流量分发。
• 流量分发的原理是根据配置和北极星的规则路由，将不同的客户的请求，转发到不同的下游逻辑层环境。
• 已经拥有可以在15分钟内，快速部署一套生产环境的能力，节省人工成本超95%

应用client端：外部请求发起端。

接入层(公司级)：IAS平台对域名请求按规则转发，将请求转发到对应ENV的接入层。

接入层(系统级)：自研的接入层模块，根据请求信息获取请求的客户ID和应用Client，将该客户的请求转发到下游对应的环境。

逻辑层： 后台的主体业务逻辑，按照ENV划分逻辑环境。每个环境都部署全量的服务，且流量一旦进入环境后，就会在该环境的服务内流转，不会串流到其他环境。流量不会串流的原理是，使用了北极星的规则路由，按照ENV进行路由，北极星的规则如下：

存储层：每个环境使用相同的存储组件和实例。后续优化项：对存储组件也按照环境进行隔离。

治理后达到的效果如下：

• 灰度环境使用真实的客户流量，起到有效的灰度效果。
• 将KA客户的计算资源隔离，增加了客户维护的分批发布。大大降低了因为版本质量问题导致影响大量客户的情况。
• 具备在生产环境上快速隔离出压测环境的能力，是公司内少数几个可以在生产环境内压测的平台。在生产环境上的压测和混沌有助于我们发现系统的瓶颈，提前暴露系统的问题，提升系统的服务质量。

测试环境治理

业务上云后，测试环境（原预发布环境）仍采用SET化部署，部署了近60个Set（环境），其中3个固定的CI Set专用于流水线日常构建和接口测试使用，1个固定的Common Set用于提测/集成测试。

在测试环境使用过程中，存在诸多问题：

• 提测服务相互覆盖：多个版本同时进行提测时，仅有1套set环境(common set1)用于测试，存在版本相互覆盖的问题。
• 提测环境错误指向：测试环境的服务指向灰度/正式环境，导致测试返工、测试结果不准确。
• 资源冗余：测试环境部署多套Set环境，浪费资源，维护成本比较高。
• 流水线等待环境：3个CI环境，如果超过3个服务同时进行CI时，则第4个服务的CI因为没有环境可用，导致长时间等待，降低整体CI的效率。节假日及下班时间使用比较少，3套CI环境利用率不高，浪费资源。

业界环境治理的方案对比：

为了解决上述问题，整理些业界在环境治理方面的方案。

测试环境治理方案的选择：

由于云小微的微服务数量600+，所以测试环境的治理不适合使用泳道式部署多套完整环境的方案。该方案资源冗余严重，且维护成本太高。

service mesh是个好方案，适合测试环境的治理。但是我们开始环境治理时，service mesh还不支持taf、trpc协议，且service mesh方案整体的改造工作量比较大。

自定义路由的方式，需要业务方自定义每个节点的上下游，维护整个路由表，对业务侵入性较大，维护成本高。

所以最终选择了基于CODING+北极星规则路由的动态环境方案。

方案原理简介：

部署一套完整的服务作为基线环境。其他需要修改测试环境的场景，都新建立一个特性环境，特性环境只增量部署有变更的服务。整体路由时，特性环境增量部署的服务优先路由，特性环境不存在的服务，复用基线环境的服务。效果如下：

• 与CODING共建“CODING云小微服务”，在CODING上新建负载时，自动创建北极星，自动设置北极星路由规则。
• 利用HTTP请求或者RPC请求，将目标环境名称传入后台微服务。
• 后台微服务根据目标环境名称，请求北极星时，将目标环境名称传给北极星。
• 北极星根据规则路由选择下游服务。请求下游时，优先请求特性环境的负载。当特性环境的负载不存在时，才复用基线环境的负载。

治理后达到的效果如下：

• 拥有一套稳定的基线测试环境 + N套特性环境。
• 快速创建一个特性环境用于提测、CI；提测、CI完成后自动销毁特性环境和上面的资源。
• 解决提测服务互相覆盖、提测环境错误指向、资源冗余、流水线等待环境等问题。
• 每天平均使用动态环境进行CI80+次。
• 解决日常部署多套测试环境，造成资源浪费的问题。测试环境核心数从3456核降低到2001核，负载数从1900降低到1081，总成本从13W/月降低到5W/月。

特色与沉淀

我们将大体量的单体服务微服务化为互相解耦的微服务，完成所有服务的容器化部署，并且实现核心服务的trpc改造。

在解决了生产环境和测试环境的使用难点和痛点的基础上，跟CODING共建，沉淀了“CODING云小微服务”，并把灰度环境、压测环境、KA用户环境、动态环境，以及快速创建一套隔离环境的流水线沉淀为基础设施，部门内可以直接复用，部门外可以参考使用。

其中测试环境的动态化改造，是公司中为数不多的采用动态路由解决环境冲突，提高研效的产品。

可观测性能力建设

随着云计算的全面发展，企业的应用架构发生了显著变化，正逐步从传统的单体应用向微服务过渡。在微服务架构中，各服务之间松耦合的设计方式使得版本迭代更快、周期更短；在微服务架构中，系统的故障点可能出现在任何地方，因此我们需要针对可观测性进行体系化设计，以降低MTTR（故障平均修复时间）。

指标（Metric）、链路跟踪（Tracing）、日志（Logging）是构建可观性系统的“三大支柱”。在此基础上，让各数据之间产生更多的关联，有效的关联分析可以实现对故障的快速定界与定位，从而提升故障处理效率，减少不必要的损失。

因此Tracing、Metric、Loging数据的采集和关联成为可观测性建设的重点。

自研事件上报系统（event + logging）

因为微服务模块多，链路深，缺乏一个完备的可观测系统，导致我们在日常经营过程中存在诸多问题：

• 无法打通终端和后台的链路，客户反馈终端请求后台失败，无法联动终端和后台快速定位问题。
• 每次排查定位问题，都从接入层往下推导，最终拉了个大群，把链路上的同学都拉进来，定位问题大费周章且效率低下。
• 客户、产品、测试在体验产品时碰到问题，也有自己进行快速定位的需求。而现在TAPM、天机阁内的logging、tracing都普遍比较晦涩难懂。

基于以上的问题，云小微自研了语音助手事件系统：

• 业务上拉通终端和后台，在链路上根据业务逻辑，提取关键的链路事件。
• 事件ID为整形数据，每个模块预先划分事件ID段。
• 将事件ID转化成通俗易懂的描述和逻辑。
• 后台的日志服务接收事件后落盘，存储到CLS。
• 提供完整界面和入口，进行快速查询和个性化展示查询结果。

典型案例：合作伙伴反馈在10月27日下午15:30分，他的设备ID（f014e3fxxxxxxxxx）请求云小微后台的响应不符合预期。

排查步骤：

1. 根据时间和设备ID，查询这段时间唤醒设备的所有事件

2. 根据事件和时间判断是哪条记录。例如客户当时是希望设备“空调温度调高一度”时返回异常，结合时间和事件可以快速定位到请求的业务reqid是xxxxxxxd416668558183172750

3. 根据业务reqid下钻，查看这个业务reqid关联的所有事件。

4. 查看事件列表，获取异常事件。发现终端上报了一个“不支持调节空调温度”的异常事件。从而在2分钟内就判断出是客户的终端类型设置错误，快速帮助客户和合作伙伴定位问题。与之前定位问题时，需要拉个20人的大群，定位1-2个小时相比，这个小白系统解放了95%的人力。

达到的效果：

• 端到端全链路打通。
• 多维度快速查询(RequestID、GUID、DialogID、Appkey等)。
• 通过“事件”的概念，对后台逻辑通俗化，简易化输出。让客户、测试、产品都可以使用并且快速确认问题。
• 实现70%的问题在30分钟内定位模块，并确认大致原因。车载语音助手场景运用广泛，内外部团队普遍认可这里的价值。

可观测性tracing能力建设

BG内外tracing方案的对比：

2. 根据找到的tracing 日志下钻找到tracing-detail

3. 分析调用链路、查看耗时、下钻错误链路找到错误日志

核心链路具备接入TAPM能力

TAPM是腾讯云上的Tracing和应用性能监控的主流产品，我们也具备了接入TAPM能力。

• trpc go接入TAPM：因为trpc go服务有大量的流式的请求，所以自研了trpc插件支持trpc 流式接口接入TAPM。插件的代码和使用可以参考这里：trpc go流式接口接入tapm插件
• trpc cpp接入TAPM：trpc cpp没有流式接口，但是tapm没有提供直接接入的方式，我们给trpc cpp贡献了代码，支持了这个特性。MR可以参考：trpc-cpp#3210。最后trpc cpp接入tapm的具体方法可以参考这里：trpc cpp接入tapm
• 接入后的效果：

特色与沉淀

我们自研了事件上报系统，打通了端到端的链路事件，70%问题可以通过该系统，1个人半小时内定位。同时客户、合作伙伴、测试同学也能自主地使用该系统，不需要什么问题都上报到开发团队排查，大大节约了双发的时间，提高问题定位的效率。

同时我们也接入了天机阁和TAPM，开发同学借助他们进行更深的问题的定位和系统瓶颈的定位。

通过上述的建设，我们沉淀了自研的事件上报系统平台和trpc cpp流式接口接入天机阁、TAPM的能力。实现了logging、tracing、metric的多维数据监控和数据联动，完善了对整个云小微平台的可观测性。其中自研的事件上报系统在部门内可以复用，只需业务端主动写日志到本地即可完成接入；trpc cpp流式接口接入TAPM已经提交代码到Trpc框架，所有trpc cpp的业务都可以复用。

韧性能力建设

韧性是指当软件所依赖的软硬件组件出现异常时，软件所表现出来的抵御能力。这些异常通常包括硬件故障、硬件资源瓶颈（如CPU或网卡带宽耗尽）、业务流量超出软件设计承受能力、影响机房正常工作的故障或灾难、所依赖软件发生故障等可能造成业务不可用的潜在影响因素。业务上线之后，在运行期的大部分时间里，可能还会遇到各种不确定性输入和不稳定依赖的情况。当这些非正常场景出现时，业务需要尽可能地保证服务质量，满足当前以互联网服务为代表的“永远在线”的要求。因此，韧性能力的核心设计理念是面向失败设计，即考虑如何在各种依赖不正常的情况下，减小异常对系统及服务质量的影响并尽快恢复正常。韧性原则的实践与常见架构主要包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、多AZ（Availability Zone，可用区）的高可用、单元化、跨区域（Region）容灾、异地多活容灾等。

因此韧性能力的建设，主要是主动发现韧性问题的能力，以及服务和架构中处理故障场景的能力。

主动发现韧性问题 -- 混沌工程

什么是混沌工程

混沌工程是指通过主动在后台微服务系统上注入各种异常来模拟云上多变环境。

为什么要进行混沌工程

在公司自研上云及微服务的进一步解耦的大背景下，后台微服务系统复杂度极大增加，在面临云上天然多变的运行环境，如何增强系统的可用性，成为摆在开发、测试、运维同学面前的难题。而混沌工程可以通过模拟注入故障，提前找到系统的脆弱点，以检验微服务系统及相关人员、应对机制是否具备让系统自愈的能力，以增强系统的韧性。

我们当前做了什么

• 故障类别场景沉淀，不断新增故障注入的用例，目前已经有如下故障注入case。

• 保持核心链路不定期演练，通过演练验证告警的有效性，保障链路问题的可发现、可触达能力。
• 完善故障后的处理方案，保障故障发生后可以在1小时内自愈。
• 演练故障不可自愈的case，演练运维流程、方案验证，保障故障出现时的可应急能力。
• 家居语音助手业务生产环境混沌演练：核心链路涉及共 400+ 服务生产监控告警有效性验证；资源配置不合理处 3 项，提前发现业务可用性潜在隐患 6 处，均已反馈并解决。
• 车载语音助手隔离环境混沌演练：提前发现高可用隐患 6 项，发现监控告警配置不合理 4 项；资源配置不合理 1 项； 问题均已反馈并解决。

典型案例

故障注入：通过星云提供的tkex-container资源挤占场景，模拟CPU资源飙高，持续触发HPA扩缩容策略，验证环境弹性可用性。

• 策略：hpa开启，cpu每分钟提高到90%占用率每轮持续1分钟，间歇30秒，负载持续10分钟。
• 预期结果：CPU达到60%后，可以正常触发hpa，快速扩容出新的pod。
• 实际结果：在多次演练后发现，可能出现部分服务触发HPA后，扩容失败情况。
• 结果复盘：扩容失败的负载，是AI大数据模型的服务，由于业务原因使用了大内存的EKS（8核64G）。在tkex上CPU和内存占比1:8的EKS资源较少，且各大BG、部门都使用的同一个池子，所以很可能出现资源抢占，扩容失败的场景。EKS的同学建议业务的资源配比尽量使用1:2和1:4。
• 后续处理：改造服务，尽量将1:8配比的服务，改造成1:4的资源配比。并将该故障注入case作为常规case，频繁进行混沌验证。

服务和架构中处理故障场景的能力

韧性原则的实践与常见架构主要包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、多AZ（Availability Zone，可用区）的高可用、单元化、跨区域（Region）容灾、异地多活容灾等。

服务异步化

目前云小微的微服务数有600+个，其中TAF服务400+个，TRPC服务200+个。TAF框架支持主调服务以同步、异步（单向实际上也是异步的）的两种模式访问被调服务，其中同步方式因为在调用过程中会阻塞当前线程，业务处理逻辑不能并行化，吞吐量一般较低，因而云小微的taf微服务间调用都使用异步模式。对于TRPC服务，也通过协程的方式实现服务异步化。

业务示例：云小微的语音助手的DM（对话管理）服务，需要调用下游较多，如NLU（语义理解）、Chat（闲聊）和TSKM（技能分发）服务。NLU和Chat是并行异步调用的，得到落域结果后再异步调用TSKM。通过并行异步和串行异步，提升对话流程的性能。

重试

由于出现过部分地区网络异常的问题，所以云小微提供了iplist的方式，供端使用。后台服务会对客户端请求的域名， 返回云小微对应域名全量的VIP 列表。当某一个VIP 访问异常时，由客户端决策使用哪个VIP，并可以进行重试，大大提高弱网环境下，客户端接入后台的成功率。

限流

为了保证后台服务的可用性，需要对一些非法流量、异常流量进行流量限制。云小微的业务统一网关TVSGatewayServer支持Appkey（标识一个接入方）、Guid（标识一台设备）等维度的流量控制。

统一网关的基本处理流程如下：

降级

对于一些核心服务，会有降级处理。如音乐服务，下游依赖比较多，如账号接口、QQ音乐接口、全局控制接口等。为降低下游服务异常对用户体验的影响，音乐服务对异常情况设计了降级方案。

例如： 当QQ音乐接口异常时，对收藏歌曲和收藏歌单做了不同的处理：

播放收藏歌曲，降级使用用户缓存的收藏列表返回；

播放收藏歌单，降级使用随便听听的免费电台歌曲。

异地多活容灾

云小微服务上云后，将服务进行了三地部署，包括广州、上海和天津。实现了国内终端的就近接入和后台服务的异地容灾。

特色与沉淀

通过上述的建设，我们在代码和部署层面增加众多增强服务韧性的手段，确保了在可预测的故障范围内，我们在服务能够自愈故障。

同时我们通过常态化地进行混沌工程，人工模拟注入故障，来演练和发现系统的韧性薄弱点。最后通过调整代码或者部署架构来修复系统的韧性弱点。云小微也是公司内极少数具备常态化混沌工程能力的产品。

这里的建设使我们沉淀了一套比较健硕的服务代码，同时也沉淀了进行混沌工程的理论和实践经验，以及处理线上故障的应急方案。同时这整套方案和实际方法论，在公司内都是可以低代码复用。

弹性能力建设

弹性原则是指系统部署规模可以随着业务量变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。优秀的弹性能力不仅能够改变企业的IT成本模式，使得企业不用再考虑额外的软硬件资源成本支出（闲置成本），也能更好地支持业务规模的爆发式扩张，不再因为软硬件资源储备不足而留下遗憾。

基础HPA的建设

生产环境的所有服务，都基于tkex的能力，配置了HPA，在CPU、内存层面进行了弹性扩容。

AI大模型数据的弹性优化

AI大模型数据服务的特点： 启动时需要读取大量的模型数据，数据大小一般在10G-70G。

老的方案：

• 将模型数据上传到CFS。服务负载挂载CFS。
• POD启动时，拉取CFS上的模型数据到本地。
• 加载本地数据到内存，加载完成后，POD才ready，开始对外服务。

痛点：

• 扩容该类负载时，数据量太大，每次启动从CFS读取数据，导致服务启动太慢，加载30G模型并且启动完成，大约需要10分钟。
• 高峰期大规模扩容时，因为CFS带宽的影响，速度并不稳定。跨区时可能需要1个小时。大大影响了高峰期的HPA效果，导致现网服务请求超时。

新的方案：

• 使用EKS镜像缓存，解决模型管理和扩容速度慢的问题
• 将模型数据制作成镜像，并且调用EKS接口将镜像制作成镜像缓存，得到镜像缓存ID。
• 负载的yaml设置使用镜像缓存

spec: 
  template:
    metadata:
      annotations:       
        eks.tke.cloud.tencent.com/image-cache-disk-retain-minute: '1440'
        eks.tke.cloud.tencent.com/use-image-cache: imc-450yp7sy

• Pod扩容时，EKS会将镜像快照拷贝到容器系统盘的CBS上。云盘快照的优先拷贝机制，大大加速了服务的启动。

• CBS磁盘可以设置保留时长，即便POD销毁了，CBS依然可以保留一段时间。这期间如负载触发扩容，则可复用这个CBS，完全避免了数据从镜像快照拷贝到CBS的过程。

新方案效果：

• 30G的模型，服务扩容速度速度可以控制在5分钟以内，最快可以在1分钟左右完成扩容。

特色与沉淀

AI大数据模型服务启动速度慢是个行业通性问题。通过上述的建设，云小微的AI大数据模型服务，扩容速度从10分钟左右，优化到5分钟以内，命中缓存时可以达到1分钟左右。优秀的扩容速度，让我们无需进行过多的冗余部署，从而提高了大数据模型服务的CPU利用率。

这个过程云小微沉淀了一套大数据模型服务启动速度优化的方案和配套的流水线。因为是直接使用了EKS的镜像缓存能力，所以只需要进行流水线的低代码改造，就能快速复用到其他产品。

自动化能力建设

技术是把“双刃剑”，容器、微服务、DevOps以及大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，也提高了软件技术栈的复杂度，加大了组件规模，从而不可避免地导致了软件交付的复杂性。如果控制不当，应用就会无法体会到云原生技术的优势。通过IaC、工蜂、CodeAnalysis和大量自动化交付工具在CI/CD（持续集成/持续交付）流水线中的实践，企业可以标准化企业内部的软件交付过程，也可以在标准化的基础上实现整个软件交付和运维的自动化。

CI/CD标准化

在进行云原生改造前，云小微的CI/CD存在许多问题：

1. 使用物理机编译，不同的机器编译环境不同，可能导致制品存在质量风险。

2. 每个服务一条流水线，流水线维护成本高。流水线之间可能存在流程不一致的情况。

3. 没有环境分级、制品分级，流程紊乱，质量未达标的制品可能会被直接发到生产环境，存在发布风险。

于是我们做了以下标准化动作：

• 使用自定义编译机，实现编译环境统一
  • 将编译环境输出成镜像，申请devnet机器，在机器上展开镜像，确保编译环境统一，编译资源可调度
  • 一些编译依赖比较多的模块，为其分配性能较强的编译机，减少其编译时间，提升CI效率。
• 统一流水线模版，每种开发语言一个模板

因为每种语言的依赖不同，所以按照开发语言来区分了流水线模板。每个服务实例化时，根据开发语言选择正确的模版即可。从维护N个服务流水线，到维护6套流水线模版，大大降低了流水线的维护工作量，提高了流水线修改的效率。

• 环境分级、制品分级，发布流程标准化

环境按照用途分为开发环境、测试环境、预发布环境、灰度环境、压测环境、普通客户环境、KA客户环境。

制品按照质量等级分为 CI通过、测试通过、可灰度、可发布、已上架（发布）、已下架（回滚）。

在不同的环境上升级对制品有不同的要求。例如升级测试环境要求制品等级>=CI通过，升级普通客户环境要求制品等级>=可发布。通过这种措施，杜绝了研发人员通过不正规的手段，将不符合标准的镜像发布到目标环境，确保发布流程的正确性。

• 分批发布，降低版本发布风险

发布时按照开发环境->测试环境->预发布环境->灰度环境->普通客户环境->KA客户环境的顺序进行发布。

发布普通客户环境和KA客户环境时，还需要对发布的负载进行分批次发布，尽量减少异常的版本对客户的影响。

测试自动化

• 单元测试用例8600个，覆盖代码60%
• 接口测试用例9400个，覆盖代码56%
• 使用星海和智研平台，建立分钟级自动化拨测体系：包括探活类拨测、功能类拨测和AI效果类拨测，用例数15W+，核心接口100%覆盖。

服务免测率建设

免测服务指服务的发布上线无需通过人工介入测试和验证，而是通过自动化的指标测试和验证，一旦达到了免测标准，就可以直接发送到灰度环境和生产环境。

• 制定智平服务免测标准（自动化测试行覆盖率>80%,分支覆盖率>60%,方法覆盖率>80%）。其中代码覆盖率的度量方法见：云小微代码覆盖率度量方法
• 服务通过增加足够多的单元测试、接口测试，使得测试覆盖范围达到80%的代码行，60%的代码分支和80%的代码方法。
• 核心服务的免测率大幅提升，车机语音助手免测率46.4%，家居语音助手免测率37.4%，预计年底车机语音助手免测率达到75%，家居语音助手免测率达到56%。

服务通过免测标准后，CI/CD流水线将会走到免测流程，流水线的代码安全、质量检查、CI等通过后，跳过人工测试等待流程，直接部署到灰度环境。大大节约了测试的人力成本，提升版本迭代的速度。修复bug的速度得到了明显提升，也得到客户的一致好评。如下图所示，免测服务整体上4个小时内可以完成上线，非免测服务整体上需要2天时间。

达到的效果

通过上述的自动化建设，最终体现在了发布的效率和质量上。

• 每天流水线执行100+次，CI平均执行时长8分钟，降低60%。CD平均执行时长33分钟，降低10%
• 家居语音助手2022年平均无故障时长达143.1天，相比去年延长100%
• 客户反馈问题下降50%+

典型案例

比亚迪因为出海需要，10月13日周四晚上22:00左右，给老板提了个需求，希望我们对出海的服务做些定制化，下周一进行POC。需求紧急，给的时间也很短。在未进行自动化建设前，肯定是要让开发、测试同学周末加班推进版本。但是在自动化建设后基础上，我们周五一天就完成了版本的开发、自动化测试和发布。

因为开发的服务是免测服务，完全依赖服务的接口测试用例、单元测试用例、代码覆盖率来保障服务的质量，无需走人工测试和校验，这里节约了大量的时间。

10月13日22时收到需求，10月14日早上对齐需求后，17点左右完成了代码改造、自测和用例完善，晚上21点就已经跑完整个CI/CD流程，实现24小时内版本迭代的效果。

特色与沉淀

通过上述的建设，我们标准化了服务CI、CD的流程，同时通过自动化测试和免测服务，提高了CI、CD的速度和版本的质量。最终使得我们的版本迭代速度，响应速度和产品质量都有了极大的提升。

这期间我们沉淀了部门的流水线通用模板，数量可观的用例集，以及与CODING共建的“CODING云小微服务”，这些都是我们产品质量和效率的基础设施和基础保障。

总结

在智平各中心同学和CSIG质量部/智能产品质量中心同学的共同努力下，云小微重点在云原生的5大领域（服务化、可观测性、韧性、弹性、自动化能力）上进行了建设，完成了Re-host、Re-platform、Re-architect的转变。

• 服务化能力建设，完成了服务的微服务化和容器化，并且实现了一个顺滑、高效的环境治理方案，充分利用微服务化和容器化的特性。
• 可观测能力建设，完成了自研事件系统，接入了天机阁和TAPM，实现了logging、tracing、metric的多维数据监控和数据联动，实现了云小微产品360度的SLA监控。
• 韧性能力建设，实现了攻击方发现问题，防守方主动防御的常态化演练。二者配合互相推动，实现云小微服务韧性的正向演进。
• 弹性能力建设，解决了AI大模型数据的弹性问题痛点，使得所有容器服务均具备快速弹性的能力。
• 自动化能力建设，实现了研发流程和CI/CD流程的标准化，通过自动化测试和免测服务机制，提升了版本迭代的效率，达到免测版本不过夜的效果。

当然随着对云原生的实践越来越多，我们也发现云小微在云原生的资源利用率、可调度性等方面建设和实践相对比较薄弱。接下来我们也将继续云原生的实践，不断完善自身的薄弱点，更好地服务客户和合作伙伴。