DDD

引子：一次失败的微服务拆分 2019年某月，某金融科技公司CTO李明决定将单体应用拆分为微服务。 拆分方案（按技术层拆分）： 前端服务：负责所有页面渲染 业务服务：负责所有业务逻辑 数据服务：负责所有数据访问 3个月后的结果： 部署次数：从每周1次降到每月1次（更慢了！） 数据库连接：3个服务共享同一个数据库（还是耦合） 代码冲突：业务服务有50个类，15个人修改，冲突率40%（比单体更高） 故障影响：数据服务挂了，整个系统不可用（单点依旧存在） 李明的困惑： “我们明明拆分了，为什么比单体还糟糕？” “什么才是正确的拆分方式？” “服务边界应该如何划分？” 这个案例揭示了一个核心问题：拆分微服务的本质不是"拆分技术层"，而是"拆分业务领域"。 让我们从第一性原理出发，系统化解答这个问题。 一、服务拆分的本质问题 1.1 什么是服务边界？ 服务边界的定义： 物理边界：独立的进程、独立的数据库、独立的部署单元 逻辑边界：独立的业务职责、独立的团队所有权、独立的变更频率 好的服务边界的三个特征： 高内聚：服务内部的功能紧密相关（订单创建、订单查询、订单取消都在订单服务内） 低耦合：服务之间的依赖最小化（订单服务不依赖评论服务） 独立演进：服务可以独立开发、测试、部署（订单服务升级，不影响商品服务） 1.2 拆分的三个核心目标 目标1：独立部署 单体架构的问题： 改订单服务的一个Bug，整个系统重启 部署时间：120分钟 微服务的解决方案： 改订单服务的Bug，只重启订单服务 部署时间：15分钟 目标2：独立扩展 单体架构的问题： 订单服务压力大，整体扩容，浪费80%资源 微服务的解决方案： 订单服务压力大，只扩容订单服务 目标3：独立演进 单体架构的问题： 整个系统必须用同一技术栈（Java + Spring） 微服务的解决方案： 订单服务用Java，推荐服务用Python，搜索服务用Go 1.3 拆分的代价 不要忘记：拆分微服务是有代价的！ 代价维度 单体架构 微服务架构 增加幅度 网络调用延迟 0ms（本地调用） 10-50ms +∞ 事务复杂度 ACID（本地事务） BASE（分布式事务） +10倍 运维复杂度 1个服务 100+服务 +100倍 问题定位难度 单进程堆栈 链路追踪 +5倍 核心原则：只有当拆分的收益 > 拆分的成本时，才应该拆分！ ...

引子：一个仓库主管的抱怨 “为什么拣货员每天要走10公里路？明明商品就在那里，为什么不能放得更合理一点？” 这是2022年夏天，我们深圳仓库主管老张的抱怨。他给我看了仓库的热力图——拣货员的行走轨迹遍布整个仓库，像一张密密麻麻的蜘蛛网。 数据更触目惊心： 8个仓库，总面积50,000+平方米 每天处理2万+出库单 拣货员人均每天行走路径：10.5公里 单笔订单平均拣货时间：18分钟 问题的根源在于：我们的库位分配策略太随机了。新到货的商品，系统找到第一个空闲库位就塞进去，完全不考虑商品的出库频率、拣货路径、库位高度等因素。 经过3个月的算法优化和系统重构，我们实现了： 拣货效率提升40% 人均行走路径减少至6.3公里 单笔订单拣货时间缩短至10分钟 空间利用率提升15% 这篇文章，就是那段时间算法演进的完整技术总结。 库位分配的业务价值 在讲算法之前，先理解为什么库位分配如此重要： 1. 拣货效率 核心指标：拣货路径长度 场景：订单包含3个商品（A、B、C） 方案1（随机分配）： 入口 → A(100m) → B(300m) → C(50m) → 出口(150m) 总路径：600m 方案2（优化分配）： 入口 → A(20m) → B(30m) → C(40m) → 出口(50m) 总路径：140m 效率提升：(600-140)/600 = 76.7% 2. 空间利用率 核心指标：库位满载率 重货在下层（承重强） 轻货在上层（便于搬运） 大件在地面库位 小件在货架 3. 作业安全 易碎品避开高层库位 危险品单独存放 高频商品避开拥挤区域 算法演进：从V1.0到V3.0 V1.0：随机分配（最简单，最差） 实现逻辑： @Service public class LocationAllocationServiceV1 { /** * V1.0：找第一个空闲库位 */ public Location allocate(Product product) { // 查询所有空闲库位 List<Location> emptyLocations = locationRepository.findByStatus(LocationStatus.EMPTY); if (empty Locations.isEmpty()) { throw new NoAvailableLocationException(); } // 返回第一个 return emptyLocations.get(0); } } 优点： ...