代码越写越多怎么办？在线等挺急的！

Bidding-interface服务代码库代码量已经达到

Bidding-interface应用是出价域核心应用之一，主要面向B端商家。跟商家后台有关的出价功能都围绕其展开。是目前出价域代码量最多的服务。

随着出价业务最近几年来的快速发展，出价服务承接的流量虽然都是围绕卖家出价，但是已远远超过卖家出价功能范围。

业务的快速迭代而频繁变更给出价核心链路高可用、高性能都带来了巨大的风险。

出价链路各子业务模块间代码有不同程度的耦合，迭代开发可扩展性差，往往会侵入到出价主流程代码的改动。每个子模块缺乏独立的封装，而且存在大量重复的代码，每次业务规则调整，需要改动多处，容易出现漏改漏测的问题。

历史原因上层业务层代码缺乏抽象，代码无法实现复用，需求开发代码量大，导致需求估时偏高，经常出现20+人日的大需求，需求开发中又写出大量重复代码，导致出价服务代码库快速膨胀，应用启动耗时过长，恶性循环。

B端卖家出价链路流量与C端价格业务场景链路流量没有完全隔离，由于历史原因，有些B端出价链路接口代码还存在于price应用中，偶尔B端需求开发会对C端应用做代码变更。存在一定的代码管控和应用权限管控成本。

代码量庞大，导致编译速度缓慢。代码过多，类的依赖关系更为复杂，持续迭代逐步加大编译成本，随着持续迭代，新的代码逻辑 ，引入更多jar 依赖，间接导致项目部署时长变长蓝绿发布和紧急问题处理时长显著增加；同时由于编译与部署时间长，直接影响开发人员在日常迭代中的效率（自测，debug，部署）。

历史原因出价基础能力领域不明确，出价底层和业务层分层模糊，业务层代码和出价底层代码耦合严重，出价底层能力缺乏抽象，上层业务扩展需求频繁改动出价底层能力代码。给出价核心链路代码质量把控带来较高的成本， 每次上线变更也带来一定的风险。

以上，对于Bidding服务的拆分和治理，已经箭在弦上不得不发。否则，持续的迭代会继续恶化服务的上述问题。

经过前期慎重的筹备，设计，排期，拆分，和测试。目前Bidding应用经过

的拆分节奏，已经马上要接近尾声了。服务被拆分成

1000+Dubbo接口，300+个HTTP接口，200+ MQ消息，100+个TOC任务，10+个 DJob任务。

本人是出价域测试一枚，参与了一期-四期的拆分测试工作。

项目在全组研发+测试的ALL IN投入下，已接近尾声。值此之际输出一篇文章，从测试视角复盘下，Bidding服务的拆分与治理，也全过程揭秘下出价域内的拆分测试过程。

首先，在细节性介绍Bidding拆分之前。先过大概过一下服务拆分原则：

拆分原则之下，还有不同的策略可以采纳：基于业务能力拆分、基于领域驱动设计 (DDD) 拆分、基于数据拆分等等。同时，拆分时应该注意：

避免过度拆分、考虑服务之间的通信成本、设计合理的 API 接口。

服务拆分是微服务架构设计的关键步骤，需要根据具体的业务场景和团队情况进行综合考虑。合理的服务拆分可以提高系统的灵活性、可扩展性和可维护性，而不合理的服务拆分则会带来一系列问题。

如引言介绍过。Bidding服务被拆分出三个新的应用，同时保留bidding应用本身。目前共拆分成四个应用：Bidding-foundtion，Bidding-interface，Bidding-operation和Bidding-biz。详情如下：

出价基础服务，对出价基础能力抽象，出价领域能力封装，基础能力沉淀。

商家端出价，提供出价基础能力和出价工具，提供商家在各端出价链路能力，重点保障商家出价基础功能和出价体验。

出价运营，重点支撑运营对出价业务相关规则的维护以及平台其他域业务变更对出价域数据变更的业务处理：

更多业务场景扩展，侧重业务场景的灵活扩展，可拆出的现有业务范围：国补采购单出价，空中成单业务，活动出价，直播出价，现订现采业务，预约抢购，新品上线预出价，入仓预出价。

四、Bidding拆分的节奏和目标收益

服务拆分是项大工程，对目前的线上质量存在极大的挑战。合理的排期和拆分计划是重点，可预期的收益目标是灵魂。

经过前期充分调研和规划。Bidding拆分被分成了四期，每期推进一个新应用。并按如下六大步进行：

完成对Bidding大单体应用合理规划拆分，向下沉淀出出价基础服务应用层，降低出价基础能力维护成功；向上抽离出业务扩展应用层，能够实现上层业务的灵活扩展；同时把面向平台运营和面向卖家出价的能力独立维护；在代码库和应用层面隔离，有效减少版本迭代业务需求开发变更对应用的影响面，降低应用和代码库的维护成本。

按业务类型对业务代码进行分类，统一设计方案，提高代码复用性，支持业务场景变化时快速扩展，以引导降价为例，当有类似降价换流量/降价换销量新的降价场景需求时，可以快速上线，

类似情况每个需求可以减少10-20人日开发工作量。

通过拆分出价基础服务和对出价流程代码做重构，将出价基础底层能力代码与上层业务层代码解耦，降低代码复杂度，降低代码冲突和维护难度，从而提高整体代码质量和可维护性。

服务拆分的前期，研发团队投入了大量的心血。现在代码终于提测了，进入我们的测试环节：

为了能收获更好的质量效果，同时也为了不同研发、测试同学的分工。我们需要细化到最细粒度，即接口维度整理出一份详细的文档。基于此文档的基础，我们确定工作量和人员排期：

如本迭代，我们投入4位研发同学，2位测试同学。完成该200个Dubbo接口和100个HTTP接口，以及20个Topic迁移。对应的提测接口，标记上负责的研发、测试、测试进度、接口详细信息等内容。

基于该文档的基础上，我们的工作清晰而明确。一个大型的服务拆分，也变成了一步一步的里程碑任务。

接下来给大家看一下，关于Bidding拆分。我们团队整体的测试计划，我们一共设计了五道流程。

每批次拆分接口提测前，研发同学必须完成接口自测。基于新旧接口返回结果对比验证。验证通过后标记在文档中，再进入测试流程。

对于拆分项目，自测卡的相对更加严格。由于仅做接口迁移，逻辑无变更，自测也更加容易开展。由研发同学做好接口自测，可以避免提测后新接口不通的低级问题。提高项目进度。

在这个环节中。偶尔遇见自测不充分、新接口参数传丢、新Topic未配置等问题。（三期、四期测试中，我们加强了对研发自测的要求）。

这一步骤基本属于测试的人工验证，同时重点需关注写接口数据验证。

回归时要测的细致。每个接口，测试同学进行合理评估。尽量针对接口主流程，进行细致功能回归。由于迁移的接口数量多，历史逻辑重。一方面在接口测试任务分配时，要尽量选择对该业务熟悉的同学。另一方面，承接的同学也有做好历史逻辑梳理。尽量不要产生漏测造成的问题。

该步骤测出的问题五花八门。另外由于Bidding拆分成多个新服务。两个新服务经常彼此间调用会出现问题。比如二期Bidding-foundation迁移完成后，Bidding-operation的接口在迁移时，依赖接口需要从Bidding替换成foundation的接口。

灰度打开情况下，调用新接口报错仍然走老逻辑。（测试时，需要关注trace中是否走了新应用）。

出价域内沉淀了比较完善的接口自动化用例。在人工测试时，测试同学可以借助自动化能力，完成对迁移接口的回归功能验证。

同时在发布前天，组内会特地多跑一轮全量自动化。一次是迁移接口开关全部打开，一次是迁移接口开关全部关闭即正常的自动化回归。然后全员进行排错。

全量的自动化用例执行，对迁移接口问题拦截，有比较好的效果。因为会有一些功能点，人工测试时关联功能未考虑到，但在接口自动化覆盖下无所遁形。

在拆分接口开关打开的情况下，在预发环境进行流量回放。

线上录制流量的数据往往更加复杂，经常会测出一些意料之外的问题。

迭代过程中，我们组内仍然会在沿用两次回放。迁移接口开关打开后回放一次，开关关闭后回放一次。（跟发布配置保持一致）。

为保证线上生产质量，在迁移接口小流量灰度过程中。我们持续监测线上问题告警群。

以上，就是出价域测试团队，针对服务拆分的测试流程。同时遵循可回滚的发布标准，拆分接口做了非常完善的灰度功能。下一段落进行介绍。

出价流程切新应用灰度控制从几个维度控制：总开关，出价类型范围，channel范围，source范围，bidSource范围，uid白名单&uid百分比(0-10000)：

Dubbo接口、HTTP接口、TOC任务迁移、DMQ消息迁移分别配有不同的灰度策略。

拆分的过程中，伴随着很多迭代需求的开发。为了提高迁移效率，我们会在需求排期后，并行处理迭代功能相关的接口，把服务拆分和迭代需求一起完成掉。

目前，我们的拆分已经进入尾声。迭代发布后，整体的技术项目就结束了。灰度节奏在按预期节奏进行~

值得一提的是，目前我们的流量迁移仍处于第一阶段，即拆分应用出价域内灰度迁移，上游不感知。目前所有的流量仍然通过bidding服务接口进行转发。后续第二阶段，灰度验证完成后，需要进行上游接口替换，流量直接请求拆分后的应用。

1.大模型网关：大模型时代的智能交通枢纽｜得物技术

2.从“人治”到“机治”：得物离线数仓发布流水线质量门禁实践

3.AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术

代码越写越多怎么办？在线等挺急的！Bidding-interface服务代码库代码量已经达到100w行！！

服务拆分之旅：测试过程全揭秘｜得物技术

技术运营

后端

测试

架构设计

Bidding-interface服务拆分治理实践：100万行代码大单体应用拆分为四个独立服务，解决核心链路耦合、代码复用率低、编译部署慢等问题。通过四期拆分实现出价基础能力下沉、业务层组件化，提升开发效率50%，部署时间缩短至6分钟。测试团队采用五道流程保障拆分质量，包括接口对比、功能回归、自动化测试等，确保千万级流量平稳迁移。

微服务架构

llmsgw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Bidding-interface服务拆分治理实践：100万行代码大单体应用拆分为四个独立服务，解决核心链路耦合、代码复用率低、编译部署慢等问题。通过四期拆分实现出价基础能力下沉、业务层组件化，提升开发效率50%，部署时间缩短至6分钟。测试团队采用五道流程保障拆分质量，包括接口对比、功能回归、自动化测试等，确保千万级流...

服务拆分之旅：测试过程全揭秘｜得物技术

服务拆分之旅：测试过程全揭秘｜得物技术

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐