企业官网建设流程全解析

“我早已支离破碎”——这句话放在技术团队里，不是矫情，而是对代码库状态的准确描述。你接手一套跑了多年的订单系统，订单服务里直接查用户表，用户模块又反过来改订单状态；数据库里二十多张表没有外键，却有无数隐式关联；每次发布都要按固定顺序启动三个应用，少启一个登录就报错。更让人头疼的是，没有人能说清楚系统的边界到底在哪。

这篇文章要探讨的，就是这种“支离破碎”的系统如何治理。先给一个明确判断：支离破碎不是问题本身，问题是无序的破碎——耦合没有消除、边界没有建立、拆分缺少依据。很多团队一看到微服务流行就动手拆分，结果把单体的一团乱麻，切成了分布式的十团乱麻，也就是业内常说的“分布式单体”。这篇文章不教你怎么把系统拆得更碎，而是教你怎么把系统从“碎得失控”变成“碎得有理”。

读完之后，你能带走三样东西：一套从盘点现状、划定边界到落地拆分的完整流程；一份可以直接照着理解和改造的代码示例；一份避免拆分后二次返工的排查清单和工程建议。适合正在重构遗留系统的团队，准备做微服务改造的技术负责人，以及在服务化改造中已经踩了不少坑的开发同学。

1. 这篇文章真正要解决的问题

“系统支离破碎”通常来自两种完全不同的路径，认清是哪一种，比急着写代码更重要。

第一种路径是“从来没有被设计过”。业务起步阶段，为了快速上线，代码没有模块边界，没有分层约束，数据库表之间随意关联，业务逻辑散落在 Controller、工具类和 SQL 里。随着需求增加，代码库越来越大，但没有人能说清某个功能到底由哪些类、哪些表、哪些定时任务共同完成。这种系统的问题不是“太碎”，而是“没有形状”。

第二种路径是“过度拆分导致碎”。团队有意识做服务化改造，按照接口、工具类、甚至数据库表来切服务，拆出来几十个小应用，每个应用都只负责一小段逻辑。表面上看服务数量很多、架构很“先进”，实际上服务之间互相调用，调用链过长，一个业务请求要经过七八个服务，每个服务都直连同一个数据库。这种系统的破碎，是无边界设计的破碎，比单体更复杂、更难排查。

所以，本文要解决的核心问题不是“要不要拆分”，而是“什么该拆、什么不该拆、怎么拆才不会二次变碎”。一个关键判断是：拆分只是手段，边界和可维护性才是目的。如果拆分没有让变更更快、故障更少、团队协作更清晰，那么拆分本身就没有价值。

对大多数中大型遗留系统而言，真正值得做的是“先模块化、后服务化”：先在代码层面建立清晰边界，切断不合理的跨模块依赖，再根据业务能力逐步独立部署。这篇文章会按照这条路径，拆解具体做法。

2. 基础概念：模块化、服务化、微服务与分布式单体

2.1 三个层级的关系

很多讨论把“模块”“服务”“微服务”混在一起，其实它们属于不同的部署和抽象层级。

模块化意思是，在同一个代码库内部，把代码按业务能力分成相对独立的包或模块。模块之间通过明确的接口调用，避免跨模块直接访问内部实现。模块化的好处是成本低，不需要考虑网络调用，也不需要多环境部署，适合作为拆分的第一步。

服务化意思是，将某些模块独立成可部署的进程，通过 HTTP、RPC 或消息队列对外提供能力。每个服务有自己的生命周期、版本和扩展方式。服务化比模块化增加了网络问题，但同时带来了独立部署、独立扩展的灵活性。

微服务是服务化的一种风格，强调服务粒度足够小、围绕业务能力组织、每个服务拥有自己的数据存储。微服务的核心理念是“领域边界”，而不是“文件数量”。

这里用一个简单的对比表格帮助理解：

2.2 低耦合与高内聚

判断系统是否“支离破碎”，最核心的两个指标是耦合和内聚。

耦合衡量的是两个模块之间的相互依赖程度。高耦合意味着改一个模块，不得不改另一个模块。比代码层面的 import 更隐蔽的是数据层面的耦合：多个模块读写同一张表，或者一个模块通过 SQL 直接操作另一个模块的核心数据。

内聚衡量的是模块内部各元素在业务上的相关性。高内聚意味着一个模块里的类、表、流程都围绕同一个业务能力组织。例如订单模块里应该有订单创建、订单查询、订单状态流转，而不是把支付回调逻辑也塞进来。

好的系统边界就是“高内聚、低耦合”：模块内部可以很复杂，但模块之间只有必要的、稳定的接口。反之，如果看到每个模块都依赖一堆公共表、公共类、公共工具，那么即便服务拆得再多，本质还是一团乱麻。

2.3 分布式单体：不要以为拆了服务就变好了

有一个术语叫分布式单体（Distributed Monolith），描述的是“物理上拆开了，逻辑上还黏在一起”的系统。表现很典型：订单服务需要查用户数据，但它不是调用用户服务，而是直连用户服务的数据库；多个服务共享同一个 Redis Key；一个事务横跨三个服务，用分布式事务框架硬撑性能。

如果拆分只是把单体里的import换成了RPC 调用，而数据依赖和业务逻辑耦合没有任何变化，那么你得到的不是一个分布式系统，而是一个更慢、更难调试、更脆弱的单体。理解了这一点，就不会急着把代码拆到几十个仓库。

3. 拆分前的系统盘点：先画现状，再定目标

拆分最忌讳“看着代码差不多就开干”。没有盘点、没有边界规划，拆到一半才发现服务之间的循环依赖剪不断，只能推倒重来。无论采取哪种拆分策略，第一步都要完成系统盘点。

3.1 盘点四张清单

建议从以下四个维度收集信息：

第一，调用关系清单。画出从入口到数据库的完整调用链，包括 Controller、Service、Mapper、第三方接口、定时任务、MQ 消费者。重点标记跨模块调用和反向依赖。

第二，数据依赖清单。梳理每张表的读写方。很多系统里，订单表会被用户模块、营销模块、报表模块同时读写，这种“一表多吃”是拆分的最大阻力。

第三，变更频率清单。统计核心模块最近半年的变更次数和发布频率。变更多、发版频繁的模块，通常是团队业务的活跃地带，拥有最强的独立部署动力。

第四，团队协作清单。如果团队本身是多个小组共用一个代码仓库，那么代码归属的模糊会让拆分后的职责同样模糊。康威定律告诉我们，系统架构会镜像组织沟通结构，盘点时不要忽略组织现状。

3.2 画两张地图

盘点后输出两张关键图。

第一张是现状依赖图。不需要画得很标准，把模块、数据表、外部依赖之间的箭头标清楚即可。重点是找出“所有箭头指向中心”的上帝模块，以及“A 依赖 B，B 又依赖 A”的循环依赖。

第二张是目标边界图。根据业务能力重新划分模块，定义哪些数据、功能属于哪个模块，模块之间只允许哪些接口通信。这张图就是后续拆分的设计蓝图，宁可多花时间讨论边界，也不要急着写代码。

3.3 定义可验证的目标

拆分目标必须能用一组指标验证。常见的验证维度包括：核心接口的平均响应时间、服务发布频率、线上故障恢复时间、跨服务调用次数、模块间数据库直连数。

例如，目标可以是“三个月内将订单域相关模块的数据库直连数从 15 个降到 0”，或者“订单创建接口的发布周期从每周阻塞三次降到独立发版”。目标越具体，改造完成后越容易检查效果。

4. 拆分环境准备与工具链选择

在动手拆分前，建议先把工具链准备好。这里不会写死具体版本，因为每个团队的技术栈不同，版本以实际项目为准，重点讲清楚每个环节需要什么能力。

4.1 工程构建工具

多模块拆分需要构建工具支持模块化管理。Java 生态常用 Maven 或 Gradle。重点是能定义模块之间的依赖关系，并保证依赖方向单向可控。建议从一开始就开启依赖检查规则，例如 ArchUnit 可以禁止某模块反向依赖另一模块，避免边界被悄悄突破。

4.2 基础框架与通信方式

服务化改造通常会在 Spring Boot / Spring Cloud 体系内进行。Spring Cloud 提供的服务发现、负载均衡、熔断能力比较成熟，适合大多数团队。通信方式上，同步调用用 OpenFeign 或 Dubbo，异步解耦用 RocketMQ、Kafka 或 RabbitMQ。选择时主要看团队熟悉度，而不是追逐热度。

4.3 数据迁移与治理工具

数据拆分是拆分过程中风险最高的部分。需要准备数据库迁移工具，例如 Flyway 或 Liquibase，保证表结构变更可以版本化管理。还需要数据同步工具，在表拆分、分库过程中做双写或数据回放。没有数据同步方案前，不要直接对数据库做大手术。

4.4 可观测性组件

服务一旦拆开，问题排查难度会指数级上升。建议提前部署链路追踪（SkyWalking 或 Zipkin）、日志聚合和指标监控。很多系统拆完后查一个请求要翻三四个服务日志，体验非常痛苦。可观测性不是可选项，而是服务化之后的“基础生存设施”。

5. 核心流程拆解：从单体到模块再到服务

下面这套流程是很多团队验证过的安全路线：先把单体内部理顺，再逐步隔离和独立部署。核心原则是“一次只拆一步，每一步都能回滚”。

5.1 先抽模块：在单体内部建立边界

第一步不碰网络、不碰部署，只调整代码结构。按照目标边界图，将代码重新组织为多模块工程。例如识别出订单域、用户域、库存域，把相关代码移动到各自的模块中。

这一步的关键是消除循环依赖。如果一个订单 Service 中直接调用了用户模块的内部方法，那么应该先抽出用户在订单场景需要的接口，而不是让两个模块继续互相引用。这个过程可能比较痛苦，但它是后续所有工作的基础。

5.2 切断数据库直连：改走 API 或消息

模块边界建立后，最难改的是数据依赖。原本订单模块直接查询用户表，改造方向有三种：把用户表明确归属到用户域，并通过用户域提供的接口获取数据；如果只是低频读取，可以引入缓存副本；如果场景允许，通过消息事件同步一份订单域需要的用户数据快照。

这里要特别强调：跨模块访问数据库必须被禁止。无论后期是否拆成微服务，共享一张表会让边界名存实亡。最稳妥的做法是，数据库归属清晰化，其他模块只能通过接口访问数据。

5.3 用 API 暴露边界

当模块之间不再直连数据库，就需要提供足够的 API 来完成业务协作。API 可以分为两类：同步接口适合流程上需要实时结果的场景，例如创建订单时需要实时扣减库存；异步消息适合通知型场景，例如订单创建成功后通知营销系统。

接口契约要尽量稳定，参数和返回结果都需要版本意识。不要把内部实体对象直接当作 API 返回体暴露出去，否则服务端一改字段，调用方就崩。

5.4 按数据域拆分数据库

当模块已经通过 API 独立运行时，可以考虑移动数据库表。常见做法是先做逻辑拆分，再分物理库。以订单域为例，可以先把订单相关的表从共享库迁到一个新库，通过双写和回放保证数据一致，验证稳定后再切换读写流量。

数据库拆分是整个流程里最危险的一步，必须配合灰度、备份、回滚方案。不要在周五下午直接执行分库，更不要把拆库和发版放在同一天。

5.5 独立部署与灰度迁移

当一个模块已经不再依赖其他模块的数据库，也拥有了稳定的对外接口，就可以将它独立成服务。独立部署后，建议先灰度迁移部分流量，例如先让测试环境全部走新服务，再放少量线上请求，逐步扩大比例。

灰度迁移的关键是能快速回滚。新服务出现问题，要能在分钟级把流量切回旧服务。如果不能做到快速回滚，就不要灰度。

5.6 回滚策略必须提前制定

拆分过程中最容易被忽视的是回滚策略。很多团队拆数据库时才想到回滚，结果发现没有备份。正确做法是：每一步操作前都明确“出问题如何回到上一步”，并在测试环境演练一遍回滚脚本。回滚不是丢人，没有回滚计划才是事故前兆。

6. 完整示例：订单系统服务化改造

为了让上述流程更具体，这里用订单创建功能作为示例。假设老系统是一个 Spring Boot 单体，订单创建逻辑非常典型：一个方法里同时访问了用户表、库存表、支付系统和消息发送组件。

6.1 改造前：一个方法里什么都有

先看改造前的代码。这个例子可能出现在很多老系统中，它的问题不是编码水平，而是边界混乱。

// 文件路径：src/main/java/com/example/legacy/service/OrderServiceImpl.java @Service public class OrderServiceImpl { @Resource private UserMapper userMapper; @Resource private StockMapper stockMapper; @Resource private PayClient payClient; @Resource private MessageClient messageClient; @Resource private OrderMapper orderMapper; @Transactional public Order createOrder(Long userId, Long skuId, Integer count) { // 这里直接查询用户模块的数据表 User user = userMapper.selectById(userId); if (user == null || user.getStatus() != 1) { throw new BizException("用户不存在或已禁用"); } // 这里直接扣减库存模块的数据表 int rows = stockMapper.deductStock(skuId, count); if (rows == 0) { throw new BizException("库存不足"); } // 这里同步调用支付系统 String payUrl = payClient.createPay(userId, skuId, count); // 创建订单记录 Order order = new Order(); order.setUserId(userId); order.setSkuId(skuId); order.setCount(count); order.setPayUrl(payUrl); orderMapper.insert(order); // 发送消息通知其他模块 messageClient.send("order_created", order.getId()); return order; } }

这段代码看起来逻辑清楚，但它是“支离破碎”的典型样本：订单模块直接读用户表、直接扣库存表，用户和库存的真实业务规则完全绕过了它们所属的领域。一旦用户模块调整表结构，订单模块必然跟着改；一旦订单方法加了事务注解，用户和库存的数据操作也被拖进同一个事务，锁范围非常大。

6.2 改造后：多模块工程结构

按边界清理后，工程结构可以长这样：

order-system/ ├── order-common/ // 通用返回体、异常定义 ├── order-domain/ // 订单领域模型、领域服务 ├── order-infrastructure/ // 订单数据库、本地消息表 ├── order-api/ // 对外 HTTP 接口 └── order-application/ // 应用服务编排

order-domain不应该依赖外部模块的 Mapper，只依赖自身领域模型和仓库接口。order-application负责业务流程编排，但它调用的用户检查、库存扣减，都走外部服务提供的接口。

这种结构的价值在于：边界在工程结构上就能看出来，后来者改代码时不会随手加一个跨表 SQL。

6.3 服务间通过 API 访问：使用 Feign 代替数据库直连

订单服务不再直连库存表，而是通过库存服务暴露的接口扣减库存。以 Spring Cloud OpenFeign 为例，可以定义这样的客户端：

// 文件路径：order-api/src/main/java/com/example/order/client/StockFeignClient.java @FeignClient(name = "stock-service", path = "/stock") public interface StockFeignClient { @PostMapping("/deduct") Result<Void> deduct(@RequestBody StockDeductRequest request); }

对应的请求体和返回体需要单独定义，不要直接复用库存模块的内部实体：

// 文件路径：order-api/src/main/java/com/example/order/client/StockDeductRequest.java public class StockDeductRequest { private Long skuId; private Integer count; // 省略 getter/setter，实际代码中需要补齐 }

此时订单创建流程就变成了：

// 文件路径：order-application/src/main/java/com/example/order/service/OrderService.java @Service public class OrderService { @Resource private UserClient userClient; @Resource private StockFeignClient stockFeignClient; @Resource private OrderRepository orderRepository; @Resource private OrderEventPublisher orderEventPublisher; @Transactional(rollbackFor = Exception.class) public Order createOrder(OrderCreateCommand cmd) { UserInfo user = userClient.getUser(cmd.getUserId()); if (user == null || user.isDisabled()) { throw new BizException("用户不存在或已禁用"); } stockFeignClient.deduct(new StockDeductRequest(cmd.getSkuId(), cmd.getCount())); Order order = Order.create(cmd.getUserId(), cmd.getSkuId(), cmd.getCount()); orderRepository.save(order); orderEventPublisher.publish(new OrderCreatedEvent(order.getId())); return order; } }

这里能看到一个关键变化：@Transactional只属于订单自身的数据库事务，不再把用户库和库存库的操作也纳入同一个本地事务。用户检查通过远程接口完成，库存扣减通过远程接口完成，订单服务只负责自己范围内的数据一致性。

6.4 数据拆分与本地消息表

服务拆分后，不在同一个本地事务里的数据如何保持最终一致？以“创建订单同时扣减库存”为例，订单服务和库存服务各有自己的数据库，不能再依靠数据库事务。比较稳妥的过渡方案是本地消息表，也常被叫作 Outbox 模式。

先在订单库中创建消息表：

-- 文件路径：order-infrastructure/src/main/resources/db/migration/V20240601__create_outbox_table.sql CREATE TABLE order_outbox ( id BIGINT PRIMARY KEY AUTO_INCREMENT, aggregate_id VARCHAR(64) NOT NULL, event_type VARCHAR(128) NOT NULL, payload TEXT NOT NULL, status TINYINT NOT NULL DEFAULT 0, retry_count INT NOT NULL DEFAULT 0, created_time DATETIME NOT NULL, published_time DATETIME DEFAULT NULL );

订单创建成功后，在同一本地事务中写入订单表和消息表：

// 文件路径：order-infrastructure/src/main/java/com/example/order/outbox/OutboxEventPublisher.java @Component public class OutboxEventPublisher implements OrderEventPublisher { @Resource private OutboxMapper outboxMapper; @Override public void publish(OrderCreatedEvent event) { OutboxRecord record = new OutboxRecord(); record.setAggregateId(String.valueOf(event.getOrderId())); record.setEventType("OrderCreated"); record.setPayload(toJson(event)); record.setStatus(0); outboxMapper.insert(record); } }

消息表与订单表在同一个事务中写入，保证订单创建成功时事件一定存在。单独的定时任务扫描status = 0的记录，发送到 MQ 后更新状态。库存服务消费事件后完成扣减；扣减失败则根据重试次数和业务规则处理。

这种模式的本质是“用本地事务保证可靠记录，用异步消息实现最终一致”，相比直接跨服务调用，它对实时性要求不高的场景更合适，也更容易排查。

6.5 关键配置参考

独立服务部署后，需要配置服务发现和数据源。这里给出一个参考配置，实际参数以环境为准：

# 文件路径：order-api/src/main/resources/application.yml server: port: 8081 spring: application: name: order-service datasource: url: jdbc:mysql://localhost:3306/order_db?useUnicode=true&characterEncoding=utf8 username: order_app password: change-me cloud: nacos: discovery: server-addr: 127.0.0.1:8848

注意，不同版本的 Spring Cloud 对 Nacos 配置项的名称有调整，实际使用时以官方文档为准。本文重点是演示拆分思路，配置细节需要结合团队现有基础设施。

7. 运行结果与效果验证

代码改造完成后，需要从功能、一致性、性能三个层面验证。

功能验证可以用一个简单的创建订单请求：

curl -X POST http://localhost:8081/api/order \ -H "Content-Type: application/json" \ -d '{"userId":1001,"skuId":2002,"count":1}'

预期返回结果：

{ "code": 0, "data": { "orderId": 900001, "status": "CREATED" } }

如果请求返回成功，还需要确认三件事：订单表是否新增记录；库存服务是否收到扣减请求；消息表中是否出现了对应事件记录，并且定时任务是否成功推送。

可以执行下面这条查询来检查 Outbox 状态：

SELECT id, event_type, status, retry_count, created_time, published_time FROM order_outbox WHERE aggregate_id = '900001';

更进一步的验证要看监控指标。建议重点观察四个指标：创建订单接口的成功率、P99 耗时、库存服务扣减失败率、MQ 消息积压量。如果拆分后 P99 比单体时代大幅上升，需要判断是网络耗时还是 N+1 调用问题，而不是认定“微服务就是这样”。

如果请求失败，第一步看链路追踪。进入 SkyWalking 或 Zipkin 查询这次请求的完整调用链，确认卡在用户服务、库存服务还是订单数据库。日志聚合平台可以帮助快速定位是哪一段抛了异常。不要在生产环境逐个服务翻日志，那是服务化改造失败的重要信号。

8. 常见问题与排查思路

服务化拆分后踩到坑，不一定是拆分方向错了，很多时候是执行细节没有控制好。下面列出几个高频问题。

第一个问题最容易被误解为代码问题。其实服务化后网络是不可靠的，超时和抖动是常态。解决思路不是让每个接口都无限重试，而是明确哪些操作可以重试、哪些操作需要幂等。例如扣减库存前先查一次库存，扣减接口自身要保证同一请求编号只能成功一次。

第二个问题和第四个问题都涉及配置和数据安全。生产环境修改注册中心地址和数据库迁移，必须先在测试环境完整演练。数据迁移脚本至少要准备好“源库备份”和“回切脚本”，双写期间要持续校验两边数据。

第三个问题说明边界设计有缺陷。在拆分前期发现循环依赖，不要硬着头皮继续拆，先停下来讨论领域归属。例如用户地址信息，可以归用户服务提供，也可以归订单服务保存快照，关键是团队内达成一致并写清楚。

9. 最佳实践与工程建议

结合多数团队的改造经验，下面几条建议值得变成团队规范。

9.1 拆分顺序：先数据，后代码，再服务

最稳妥的顺序是：先明确数据归属，再改代码消除跨库依赖，最后才考虑独立部署。如果先拆服务，代码和数据仍然纠缠，就会陷入“服务拆了但数据库没拆”的半吊子状态，反而增加问题排查难度。

9.2 禁止跨服务访问数据库，没有任何例外

这条是服务化改造的底线。一旦允许某个服务直连另一个服务的数据库，边界就会迅速崩溃。团队里可以约定：发现跨库 SQL 的代码评审直接不通过。如果某个查询确实需要聚合多域数据，优先考虑 API 聚合、数据同步副本或引入分析型存储，而不是开放数据库连接。

9.3 接口契约要有版本意识

服务间的接口一旦发布，就进入了长期维护期。建议不要直接把数据库实体类作为接口返回值，而是定义独立的 DTO。新增字段要遵循“加而不用、用而必须向前兼容”的原则，破坏性变更要规划版本迁移窗口。

9.4 分布式事务能不用就不用

本地消息表、消息事务、SAGA 各有适用场景，但都比本地事务复杂得多。如果发现很多业务流程都强依赖跨服务强一致，不要急着引入分布式事务框架，先审视边界是不是切错了位置。把需要强一致的逻辑尽量放在同一个服务内，是降低复杂度的有效手段。

9.5 让可观测性走在拆分前面

服务化改造前，就应完成链路追踪和日志聚合。否则一旦拆出第一个服务，线上问题可能就查不动了。每个服务启动时自动注册到链路系统，日志输出必须包含追踪 ID，这样一次请求能通过一个 ID 串起所有服务日志。

9.6 灰度与回滚是刚性要求

无论拆分代码、切换数据库还是迁移流量，每一步都要有灰度窗口和回滚手段。灰度比例可以逐步增加：1%、5%、20%、50%、100%。任何一步异常，都优先回滚而不是继续“修一下再放量”。

9.7 组织边界要与代码边界对齐

如果团队是按前端、后端、测试划分的，而系统需要按订单、用户、库存划分服务，那么服务归属依然会模糊。拆分过程中，至少要让每个服务有一个明确的负责人团队，哪怕这个团队只是虚拟小组。否则代码边界画得再漂亮，迭代一段时间后又会变成大杂烩。

10. 总结与后续学习方向

回到开头那句话，“我早已支离破碎”不该成为团队对代码库的无奈总结，而应当成为一次系统治理的起点。拆分的正确判断标准很简单：边界是否清晰、变更是否顺畅、故障是否可控。服务数量少不是目标，服务数量多更不是成绩。

如果你接下来要动手实践，建议从一个小域开始，比如把系统中的“通知能力”或“基础数据字典”独立成模块，跑通“盘点、隔离、灰度、独立部署、回滚”的全流程。这个最小闭环会帮你建立信心，也会暴露团队在配置管理、监控、发布流程上的短板。

后续可以继续深入的方向包括：领域驱动设计中的限界上下文建模，事件驱动架构中的事件流设计，以及契约测试和消费者驱动契约（Consumer-Driven Contracts）。这些方法不是让你把系统拆得更碎，而是帮助你在每一次拆分时，都更接近“高内聚、低耦合”的稳定形态。系统不会因为变成微服务而自动变好，支离破碎的从来不是架构，而是缺少边界的协作方式。先把边界画清楚，让代码、数据和团队在一条线上生长，比追求任何热门架构都重要。