1. 摘要

2023年12月，笔者主导研发了中部某省社区电商平台的流量录制平台，研发完成投产后，获得了各产品业务的开发人员和测试人员的一致认可。本文以公司业务技术演进过程为背景，立足于《分布式链路流量录制平台的研发与实现》项目在云原生平台在最佳实践。首先会简要的介绍项目背景，再简述云原生的具体引入过程，落实到每条细分业务线的生产过程。然后详述在本人负责的流量录制平台研发项目过程中，如何应用云原生结合Devops来提高分布式系统的运维效率，加速业务系统的更新迭代。最后总结云原生在当下软件系统开发，尤其是分布式微服务系统架构下，所发挥的重要作用，以及对未来云原生的一些发展作简要展望。

2. 背景介绍

公司背景：中部省份某社区电商互联网公司，自2021年起，社会电商业务从本省逐渐覆盖华东、华中、华南等地区，日均活跃用户在200万以上，并持续增长，提货门店在从原省内的50万家，逐步推广到全国100多万家，并不断的新门店入驻。电商平台的业务线拆分清晰，总计达到1000套微服务系统，主要采用基于微服务的分布式架构。笔者背景：作者作为技术质量中台的高级测试开发工程师，主要负责性能平台、流量录制平台、数据回放平台的开发维护工作，以及电商中台部分业务的质量工作。项目背景：从公司背景的用户规模、系统总数可以看出，在用户数量持续增长、需求快速变化背景下，采用基于微服务的分布式架构的设计，正面临着系统维护数量多、种类杂、项目迭代快、并行项目多等项目管理问题。这为质量保障人员（测试工程师）带来了许多挑战，其中一个最费时的问题就是：如何快速定位问题的发生，例如测试工程师在测试用户优惠下单时，报错后难以定位发生在哪些业务线，可能是用户被风控、库存超卖、营销锁券失败等等，前台提示只有系统繁忙，具体的后台错误，需要测试人员自己去每个业务系统的后台日志时搜索具体的原因，工作链路会非常长，所以需要一个分布式的流量录制平台，可以跨机器的生成一链完成的业务链路，帮助我们快速定位问题所在，分析原因，提出缺陷。为此我们研发了流量录制平台。

3. 云原生引入

随着移动互联网的快速普及，中国互联网网民达到11.08亿（截止2024年12月）。随之而来的是膨胀的数据总量、多变的用户需求、持续新推的软件产品。如果还是采用传统的运维方式，加上人工的过程管理，低效的人员沟通（运维人员、开发人员、测试人员、UI设计师）很难满足现在市场环境的互联网公司发展，随着时间的推移，许多问题暴露出来：

部署效率低：在需要求多、产品快速演进背景下，每次新版本发布，如何还是传统的人工作业：提前准备好物理机器，手工设置虚拟机或是不设置，直接将系统部署在物理机。先远程登陆新机器，执行脚本启动新服务，再远程登陆网关或是流量入口的机器，将流量转发到新机器，最后下线旧机器。这样的过程太过低效，且人工操作需要保障执行的可靠性，所以我们需一个可以持续部署（Continuous Deployment）的服务器平台，可以和Docker和K8s等技术融合，自动化的部署、运维我们的系统，在简化我们的运维工作的同时，可以统一高效地管理运维过程，保证系统的可靠性；
弹性扩张：用户增长、数据总量激增，意味系统的请求数是同时增长的，尤其是在一些节假日，系统的访问量会达到极限，此时需要快速的、自动化的横向添加机器，以应对流量突发问题，如何采用人工的部署，在部署期间，现有服务器可能因为无法承载巨大的流量而自动熔断限流，导致服务不可用，极端情况下服务器没有提前作好限流等主动防御，有可能直接宕机。因为需要可能弹性扩张的服务器集群为业务的稳定发展保驾护航。
资源利用不高：不管物理机，还是虚拟机，资源是固定分配的，无法动态调整，比如：一个低负载的应用只占用 4 核 8GB 内存的资源，物理机在采购时，是16核32G的，而资源无法被其他应用复用。
快速迭代：在物理机、虚拟机时代，大型的软件系统，都有固定的发布周期，比如一周或一个月。但当下的需求快速变化，各类活动层出不穷，同一个系统，一天发一版或是多版都是正常。所以要进一步提升自动化部署的水平综上所述，我们急需一种高效、资源管理协调、可弹性扩张的服务器集群技术，克服现存的问题。为此我们引入了云原生技术，选择Docker作为容器虚拟化技术，Kubernetes作为容器编排平台，结合Devops平台（主要包括了代码管理、持续集成、持续部署、监控与反馈、容器管理、协作和流量管理）以及质量管控等几个重要组成部分，极大简化了集成部署工作，同时更高效地利用了硬件资源，流量激增的情况下，也可以自动部署机器，分散流量，将请求压力分散，保障服务的可用性。

4. 云原生实践

如文中先前所描述的那样，在公司内部按具体的业务特征，采用基于微服务的分布式架构方式构建整个技术生态，做到了高内聚、低耦合，但存在一个问题就是，分布式的架构下各微服务之间的通信，如何在业务的视角下，做到可追踪。以用户下单为例：用户通过微信小程序通过Http请求到达网关，请求到达云服务器中第一个微服务【导购系统】，导购系统通过RPC调用另一个微服务【用户系统】验证用户信息，在验证用户信息时，用户系统又通过RPC调用【风险系统】，来验证此用户是否为灰产或黑产用户。这样的调用链路后续还是非常多，在功能测试时，如何定位问题发生在哪次调用，问题发生时的入参是怎样的，最开始的入参是怎么样的。为此我们参考了业界的主流解决方案分布式链路平台Skywalking以及阿里巴巴开源的Jvm-sandbox，剖析其原理（字节码增强技术）后，结合本地需求背景，将二者结合，研发了分布式录制平台，并全量部署在测试的1000多台云服务器中。具体的步骤如下：

4.1. 流量平台的研发

参考分布式链路平台Skywalking以及阿里巴巴开源的Jvm-sandbox，基于Jvm-sandbox的技术背景以及Skywalking的分布式平台思想，在每次业务调用时（Http通信、Rpc调用），在不同的网络通信的报文体中，会携带一个业务上下文，Http协议中，上下文是放在header中，RPC是放在RpcContext中，这样可以通过网络通过，将最初入口（如下单时，第一个访问的导购系统）生成的一个链路ID，在分布式的云服务器中，持续传递下去，并且增加parent ID字段来保留调用关系，requestBody保留请求的参数，response Body保留返回的结果，errorInformation保留异常信息。经过上述的原理，可以实现了分布式调用链路，并保留了调用关系和报文。

4.2. 流量平台的云原生部署

如何在每个微服务的应用系统中部署分布链路的集成包？在物理机、虚拟机时代，需要人工的部署，1000台机器（遇到大型营销活动，扩张到2000台，3000台都有可能），这无疑是巨大工作量，尤其是每次更新都需要的手工部署，为此，和云原生服务器的运维工程师沟通，预留了环境变量，和安装Shell脚本。不同的微服务负责人需要启用分布式流量功能，会在Devops平台的流水线配置时，环境变量被设置为启动，当容器被启用时，业务系统的Jar被加载启用后，就会调用这个Shell脚本，判断是环境变量是否已开启，如果已开启就是将分布式链路流量录制插件，对系统中的请求进行上下文和通信报文的保存。

5. 总结与展望

目前，软件系统的飞速发展、硬件设备性能快速增长，让软件系统的升级更新愈加频繁，之前的人工处理阶段，越来越难以满足现实发展的需要，继续采用人工处理，不仅会增加各类人员的工作量，提高工作难度，在一定层面还会增加业务风险、降低工作效率，因为一般情况下，大的项目迭代，线上发布都会在活跃用户较少、业务请求回落的凌晨，人员工作效率相对白天更低下，带来的风险更高。引入了云原生技术，结合Devops平台极大的提升了工作效率，可以通过CI/CD，满足现实快速迭代、全过程管理、项目闭环的需要。北上广深杭等主要经济发达的企业基本都引用了Devops的相关实现平台，在其他一些省会城市，这方面的技术发展并没有完成铺开，随着时间推移，建设会更加完善，当时新的技术在解决一些问题，多少会遗留一些问题，比如在环境隔离的流水线配置过程，还是需要大量的人工操作（redis、mysql、支付密钥、网关密钥），这些配置信息、配置流程繁琐却又十分重要，能否和AI融合，实现对开发者透明的自动化配置，这无疑将更加简化运维部署工作，降低人工出错的机率。