1. 摘要

2023年12 月，笔者主导研发了中部某省社区电商平台的流量录制平台，研发完成投产后，获得了各产品业务的开发人员和测试人员的一致认可。本文以公司业务技术演进过程为背景，立足于《分布式链路流量录制平台的研发与实现》项目在敏捷开发方法下最佳实践。首先会简要的介绍项目背景，再简述敏捷开发的具体引入过程。然后详述在本人负责的流量录制平台研发项目过程中，如何应用极限编程来加速开发进度，缩短迭代周期。最后总结敏捷开发方法在当下软件系统开发，尤其是分布式微服务系统架构下，所发挥的重要作用。

2. 背景介绍

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

3. 敏捷开发引入

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

开发效率低：继续采用原型模型、瀑布模型、演化模型开发等指导方法，采用固定的需求分析、概要设计、详细设计、编码实现、测试、部署等流程，可以开发出可行的软件系统，但按部就班的行进，难以满足当下的快速变化的用户需求。尤其是在多个微服务系统协同通信、业务交互的场景下，过长的时间放在详尽设计文档的编写上，会加长整个项目周期，最终导致版本无法按时上线；
沟通成本高：当下的业务系统经过一系列是的拆分、作到了高内聚、低耦合。但是，遇到多系统协同作业时，各业务线的程序员需要花费大量时间在沟通上，并且会议的静态内容，追不上需求的动态变化；
实际产品偏移：按照需求文档、设计文档、技术方案来编码实现的系统，在许多细节、外部系统交互方面并没有纳入考虑范围（如支付功能时，外部的支付渠道的异常码，公司产品在需求分析没有考虑，在技术方案时，自然也就没有作处理），导致上线的产品与产品文档一致，但和用户实际需求偏移；
快速迭代：过去10年间，大型的软件系统，都有固定的发布周期，比如一周或一个月。但当下的需求快速变化，各类活动层出不穷，同一个系统，一天发一版或是多版都是正常。所以要进一步提升自动化部署的水平综上所述，我们需求一种高效、注重沟通、适应当前发展需要的开发指导方法，为此引入了敏捷开发。

4. Scrum与极限编程

如文中先前所描述的那样，我们引入敏捷开发的指导方法，具体实践是结合Scrum与极限编程，在研发《分布式链路流量录制平台》时，主动将组内10名成员精简到5员，每个都是自己的产品经理。

4.1. 可工作的软件优于详尽的文档

我们参考了业界的主流解决方案分布式链路平台Skywalking以及阿里巴巴开源的Jvm-sandbox，剖析其原理（字节码增强技术）后，结合本地需求背景，将二者结合，基于Jvm-sandbox的技术背景以及Skywalking的分布式平台思想，在每次业务调用时（Http通信、Rpc调用），在不同的网络通信的报文体中，会携带一个业务上下文，Http协议中，上下文是放在header中，RPC是放在RpcContext中，这样可以通过网络通过，将最初入口（如下单时，第一个访问的导购系统）生成的一个链路ID，在分布式的云服务器中，持续传递下去，并且增加parent ID字段来保留调用关系，requestBody保留请求的参数，response Body保留返回的结果，errorInformation保留异常信息。经过上述的原理，可以实现了分布式调用链路，并保留了调用关系和报文。以测试驱动开发，提前编码了一个简易的被测系统，在快速开发了最基本的单机版链路流量录制插件后，在本地将这个插件部署在被测系统中，进行测试，验证通过，进行组内讨论，再安排后续的人员分工。

4.2. 关注个体互动和客户协作

基座插件研发完成后，需要和小组讨论具体的总体功能和功能设计。在小会议室，除了开发人员5名，从我们客户：各条业务线（营销线、交易线、库存线）各找寻一名开发人员和测试人员，共11名与会人员在固定30分钟上的精简会议中，收集客户的需求，从中选取最关键、最优先、最能提效的5点（请求报文与返回报文的保留、父子调用关系的保留、异常信息的保留、UI交互、是否可以实时MOCK），再次讨论，从5点再选择出3点更优先实现的功能，开发人员与客户达到一致，先实现请求报文与返回报文的保留、父子调用关系的保留、UI交互的关键功能，后续功能放在二期迭代。在此过程中，不需要过多的讨论和会议时长，在有限的时间，决策出最关键的功能，没有详尽的需求文档、概要设计与详细设计文档，只有简单的Scrum看板上几点功能。却把握了第一期系统的关键方向。会议结束后，前后端之间的接口文档是非常重要的，概要设计和详细设计文档并不是不需要了，只要这些文档也是跟着开发周期逐渐完善。开发周期内，每天上班前通过10分钟的站立会议，在Scrum看板上同步下进度和风险，5名成员也安排同一组工位中，方便组内成员的沟通。

4.3. 响应变化

立项后，经过一周研发，初版已经成型，自测完成后，在测试环境进行灰度。灰度过程中，用户返回使用过程查询超时。发现是遇到了性能的瓶颈，从电商中台的交易线、营销线、库存线的30机测试环境机器，扩张到电商中台的所有业务线：支付线、资金线、业财线、供门商线，以及部分用户增长部分的营销线、用户线、导购线等200多台机器，被录制下来的流量数据从每天10万，迅速膨胀到2小时就达到了100万（因为接入了用户线和商品线，商品每次访问都会调用这2个微服务的接口），原来的Mysql存储已经无法满足当下的需要，面对未来日均千万（200台机器），全量铺开后的亿级流量（1000台机器），必要对流量平台的数据交互方式进行重构。最终我们采用了Elastic Search作为数据存储服务，部署了8台8核16G的Elastic Search服务器组成的集群，其中1主7从，并且根据日期来横向切片，每天都根据日期新建一个Index，单个Index又横向均分为8版（例如20231101_1_postfix,20231101_2_postfix,20231101_3_postfix），让每个index的数据总量不超过500万，以免出现慢查询，影响用户使用。在此过程中，小组成员快速响应用户反应的总量，在次日就解决上线，做到快速响应突发变化。

4.4. 持续集成

为了让敏捷开发的可以在实际项目开发过程，得到落实，有一方面是公司提供自研的Devops平台，加速了集成和部署的过程，让组内开发成员可以不断的合并分支，集成部署，进行集成测试，将问题发现在时间左移，完善我们的产品。

5. 总结与展望

目前，软件系统的飞速发展、硬件设备性能快速增长，让软件系统的升级更新愈加频繁，继续传统的开发方法，越来越难以满足现实发展的需要，我们需要响应时代的变化，主动学习新方法，新技能，敢于实践。也不并是完全摈弃了之前的方法，在采用敏捷开发的过程中，依然会采用如原型方法、瀑布模型等指导思想融入到作业过程。