运送猫咪的难题：横跨型变更让按功能切分的微服务全体强耦合

[[服务本身不等于架构解耦合与独立部署的两个流行谬论]]用一个虚构的出租车调度系统案例落到实处：系统统一调度多个出租车提供商，为可扩展性大量采用微服务架构，研发团队按服务拆成许多小组各自负责——TaxiUI负责接单，TaxiFinder调用各TaxiSupplier查可用车辆，TaxiSelector按用户的价格/时间/豪华程度等条件筛选，TaxiDispatcher负责派单。系统运行一年多后，市场部宣布要新增”猫咪送达服务”：附近出租车去集散点取猫、送到指定地址；已加入的车企之外未来还会有别的车企参与、也会有不参与的；对猫过敏的司机不能被派去运猫，过去三天运过猫的车不能接对猫过敏的乘客。数一数这个新功能要改动多少个服务——答案是全部：TaxiUI要能收猫咪订单、TaxiFinder要能识别哪些供应商支持猫咪服务、TaxiSelector要加过敏排除逻辑、TaxiDispatcher要处理猫咪相关派单规则，而且这些服务之间还得彼此协调。这意味着这些服务事实上是强耦合的，根本无法真正独立开发、部署、维护——这被称为横跨型变更（cross-cutting concern）问题：所有软件系统都会遇到它，无论服务化与否；而按功能切分服务（图中每个服务对应一类职责）这种架构方式，恰恰是应对跨系统功能变更时最脆弱的形态，因为一个新功能天然会横跨多个按职责划分的服务边界。