一、引言

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

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

随着出价业务最近几年来的快速发展，出价服务承接的流量虽然都是围绕卖家出价，但是已远远超过卖家出价功能范围。业务的快速迭代而频繁变更给出价核心链路高可用、高性能都带来了巨大的风险。

经总结有如下几个痛点：

• 核心出价链路未隔离：

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

• 大单体&功能模块定义混乱：

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

• B/C端链路未隔离：

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

• 发布效率影响：

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

• 业务抽象&分层不合理：

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

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

经过前期慎重的筹备，设计，排期，拆分，和测试。目前Bidding应用经过四期的拆分节奏，已经马上要接近尾声了。服务被拆分成三个全新的应用，目前在小流量灰度放量中。

本次拆分涉及：1000+Dubbo接口，300+个HTTP接口，200+ MQ消息，100+个TOC任务，10+个 DJob任务。

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

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

二、服务拆分的原则

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

• 单一职责原则 (SRP)：  每个服务应该只负责一项特定的业务功能，避免功能混杂。

• 高内聚、低耦合：  服务内部高度内聚，服务之间松耦合，尽量减少服务之间的依赖关系。

• 业务能力导向：  根据业务领域和功能边界进行服务拆分，确保每个服务都代表一个完整的业务能力。

拆分原则之下，还有不同的策略可以采纳：基于业务能力拆分、基于领域驱动设计 (DDD) 拆分、基于数据拆分等等。同时，拆分时应该注意：避免过度拆分、考虑服务之间的通信成本、设计合理的 API 接口。

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

三、Bidding服务拆分的设计

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

• 出价基础服务-Bidding-foundation：

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

• 出价服务-Bidding-interfaces：

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

• 出价运营服务-Bidding-operation：

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

1. 出价管理相关配置：出价规则配置、指定卖家规则管理、出价应急隐藏/下线管理工具等；
2. 业务大任务：包括控价生效/失效，商研鉴别能力变更，商家直发资质变更，品牌方出价资质变更等大任务执行。

• 业务扩展服务-Bidding-biz：

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

应用拆分前后流量分布情况：

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

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

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

• 解决Bidding大单体问题： 对Bidding应用进行合理规划，完成代码和应用拆分，解决一直以来Bidding大单体提供的服务多而混乱，维护成本高，应用编译部署慢，发布效率低等等问题。
• 核心链路隔离&提升稳定性： 明确出价基础能力，对出价基础能力下沉，出价基础能力代码拆分出独立的代码库，并且部署在独立的新应用中，实现出价核心链路隔离，提升出价核心链路稳定性。
• 提升迭代需求开发效率： 完成业务层代码抽象，业务层做组件化配置化，实现业务层抽象复用，降低版本迭代需求开发成本。
• 实现出价业务应用合理规划： 各服务定位、职能明确，分层抽象合理，更好服务于企/个商家、不同业务线运营等不同角色业务推进。

• 出价服务应用结构优化：

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

• 完成业务层整体设计，业务层抽象复用，业务层做组件化配置化，提升版本迭代需求开发效率，降低版本迭代需求开发成本：

  按业务类型对业务代码进行分类，统一设计方案，提高代码复用性，支持业务场景变化时快速扩展，以引导降价为例，当有类似降价换流量/降价换销量新的降价场景需求时，可以快速上线，类似情况每个需求可以减少10-20人日开发工作量。

• 代码质量提升 ：

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

• 开发效率提升 ：

  1. 缩短应用部署时间： 治理后的出价服务将加快编译和部署速度，缩短Bidding-interfaces应用发布(编译+部署)时间 由12分钟降低到6分钟，从而显著提升开发人员的工作效率，减少自测、调试和部署所需的时间。以Bidding服务T1环境目前一个月编译部署至少1500次计算，每个月可以节约150h应用发布时间。
  2. 提升问题定位效率： 出价基础服务层与上层业务逻辑层代码库&应用分开后，排查定位开发过程中遇到的问题和线上问题时可以有效缩小代码范围，快速定位问题代码位置。

五、测试计划设计

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

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

如本迭代，我们投入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实践到团队协作的优化思考｜得物技术

4.入选AAAI-PerFM｜得物社区推荐之基于大语言模型的新颖性推荐算法

5.Galaxy比数平台功能介绍及实现原理｜得物技术

关注得物技术，每周一、三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点攒～

未经得物技术许可严禁转载，否则依法追究法律责任。