SOA Reflex 才是问题

有时候，招聘启事里只需要一句话，我脑子里就会听见某本老 ESB 手册啪地合上。

我曾看到一个 Staff Engineer 职位，大意是：

You lead the technical migration of our legacy monolith towards a modular, service-oriented architecture – from planning to hands-on delivery.

这句话会触发我的警报。

不是因为 Service 不好，也不是因为 Modularization 错了，更不是因为 “service-oriented” 这个词本身有罪。

而是因为这种表述很像一种旧的 Enterprise Reflex：

Legacy Monolith 坏了？ 那我们就设计一个 Service-oriented Target Architecture。 有 Planning，有 Governance，有 Service Cut，有 Integration Logic，最好再配一套 PowerPoint。

问题不在 “Service” 这个词。

问题在背后的 Reflex。

SOA 并不愚蠢

现在高喊 “SOA is dead”，然后因此感觉自己很现代，这太廉价了。

SOA 是对真实问题的一种合理回应。

企业当时面对的是 Point-to-Point Integration、技术野蛮生长、Monolith、直接 Database Coupling、Proprietary Interface，以及越来越难解释的依赖关系。

通过 Service 暴露 Capability 的想法并不荒谬。

恰恰相反，很多现代架构形式也继承了类似思想：Loose Coupling、Contract、Reusable Capability、Clear Responsibility、Technical Decoupling。

Service 不是问题。

Centralized Intelligence 才是。

旧式 SOA Reflex 为什么危险

在真实企业里，SOA 经常长成另一种东西。

Domain Orientation 变成 Service Inventory。 Decoupling 变成 Central Integration Logic。 Reuse 变成 Dependency Network。 Architecture 变成 Governance。 Knowledge 变成 Expert Monopoly。

这才是 2026 年真正应该警惕的部分。

如果一个 Legacy Monolith 已经无法高效交付，把它拆成一组技术命名的 Service，再在上面铺一层 Central Integration，并不会让问题消失。

Monolith 只是换了形状。

以前是一个可以 Deploy 的问题。

以后是一个 Distributed Problem，再附带固定会议系列。

错误的边界可以生产很多 Service，却生产不了 Autonomy。

那不是现代系统。

只是一个营销包装更好的 Distributed Monolith。

早期批评并不是凭空出现的

早在 2000 年代末，SOA 就已经遭到相当严肃的质疑。

一项 Burton Group 研究——后来经常在 Gartner 语境中被引用——大意是：只有大约五分之一 SOA Project 可以被认为真正成功。报道中的数字大致是：约一半明显失败，另外大约 30% 既算不上成功，也没有彻底失败。也就是说，大约只有 20% 被明确视为成功。

这当然不是自然定律。

也不证明所有 Service-oriented Architecture 都会失败。

但它是警告信号。

2014 年一篇关于 SOA Governance 的论文也再次引用了这个数字，并指出大约只有五分之一的 SOA Initiative 真正成功。

有意思的不是精确百分比。

而是：SOA 的问题显然并不只是缺少 Tool、Standard 或 Diagram。

很多时候，它失败在组织并没有真正处理自身的依赖关系。

ROI 的问题也类似。2009 年 Gartner 被引用指出，大量 SOA Initiative 并没有认真衡量 Return on Investment：大约 40% 的 SOA User 不测量何时达到 ROI；在 Non-user 中，大约一半甚至无法清晰表达或证明 Business Value。

这很残酷。

如果无法解释或衡量 Business Value，那么你做的可能不是 Architecture。

而是一项带着希望色彩的 Integration Program。

带 Enterprise 术语的 Bus Factor

我对 SOA Landscape 的经验并不是“那里的人不聪明”。

恰恰相反。

很多时候那里有非常聪明的人。

甚至聪明到系统已经离不开他们。

少数 Architect 知道为什么 Service A 必须通过 Route C 和 Service B 交互。 少数 Integration Specialist 知道 ESB 里的哪条 Transformation 绝对不能动。 少数老员工知道 Central Data Model 为什么在某个地方是禁区。

这些人一旦离职、生病，或者真的被那辆传说中的 Bus 撞上，系统技术上也许还在运行。

但业务上已经几乎没人真正理解它。

这就是把 Bus Factor 做成了 Architecture Principle。

只是用了 Enterprise Vocabulary。

你得到的不是 Robust System。

而是一个带 SLA 的 Knowledge Monopoly。

这不是 Decoupling。

这是对理解能力的集中化。

现代 Migration 应该先问别的问题

现代架构不应该首先问：

那个漂亮的目标系统最终长什么样？

更应该先问：

哪些 Team 必须能够独立做出哪些业务决策？

这是完全不同的思维方式。

Team Autonomy 比抽象的 System Beauty 更重要。

好的边界让 Team 能够独立理解、修改、测试、Deploy 自己负责的业务，而不必同步五个其他 Team。

坏的边界在 Diagram 上可能非常干净，现实中却不断产生 Alignment Meeting、Ticket Chain、Release Coordination 与 Integration Anxiety。

架构应该通过 Delivery Capability 来衡量。

不是通过 Diagram 是否好看。

这也是为什么 Strangler Fig 作为反例那么重要。

不是因为名字好听。

它是对 Big Bang Architecture 的解毒剂。

核心思路不是一次性重建 Monolith，而是在旧系统旁边逐步建立新的 Capability，抽离单个 Flow，封装业务断点，从真实使用中学习，并一点点缩小旧 Monolith。

它没有 Target Architecture Presentation 那么壮观。

但有一个优势：

它更可能真的工作。

EDA 不是魔法棒，但它代表了更好的思考方向

到了 2026 年，我们更常谈 Event-driven Architecture、Domain Event、Loose Coupling、Autonomous Team 与 Independent Changeability。

这是好事。

但也不要天真。

EDA 不会魔法般解决所有问题。

Event 自己也会带来很多麻烦：Debugging、Event Versioning、Schema Evolution、Consistency Model、Observability、Domain Coordination、Reprocessing、Ownership。

如果没有 Discipline，只是把 Event 扔进系统，那不是现代架构。

那只是带 Kafka 的 Logfile Bingo。

但 EDA 背后的思考方式值得重视。

它不是因为 Event 比 Service 听起来更酷才现代。

只有当 Domain Event 真正支持 Autonomy 时，它才有意义。

一个好的 Event 不应该只是：

Record 4711 changed.

更应该表达业务事实：

• Invoice was approved.
• Order was cancelled.
• Membership was activated.
• Payment failed.
• Review was completed.

这类 Event 可以尊重 Context Boundary。

其他业务领域可以响应它们，而不需要 Central Integration Intelligence 编排每一个决定。

这才是区别。

不是中央控制。

而是业务职责通过稳定 Event 相互沟通。

DRY Reflex 也是问题的一部分

很多 SOA Landscape 非常热爱 Reuse。

Central Model。 Central Schema。 Central Service。 Shared Data Type。 定义一次，到处使用。

听起来很高效。

但往往很危险。

因为 Reuse 可能只是伪装成 Efficiency 的 Coupling。

尤其对于 Domain Model，共享模型知识并不自动是好事。它可能意味着多个业务 Context 同时拉扯一个概念，直到这个概念最终不再真正属于任何一个 Context。

Vaughn Vernon 在 DDD 语境里曾强调，DRY 并不只是“不要重复一行代码”，而更接近 “Don’t repeat knowledge”。

核心是 Knowledge，不是 Cosmetic Duplication。

很多情况下，每个 Context 拥有自己的 Model，比所有人共享一个没人真正负责的 Central Model 更健康。

Shared Model 不是架构奖杯。

它是一项需要主动承担的 Liability。

SOA Reflex 的警告信号

Monolith Migration 中如果出现下面这些话，应该认真听一听：

• “我们先定义 Target Architecture。”
• “需要一个 Central Data Model。”
• “Feature 可以由这个 Team 做，但 Integration 交给另一个 Team。”
• “所有 Service 都经过 Central Layer。”
• “Reuse 是我们的主要目标。”
• “业务边界以后再切。”
• “我们的 Event 就是技术上的 Change Notification。”
• “Deployment 是分布式的，但 Decision 是集中式的。”
• “只有两个人真正理解 Integration Logic。”

单独一句，在某些 Context 下可能合理。

放在一起，就形成了一个 Pattern。

这个 Pattern 不是 Modernization。

而是 Regression。

更好的做法是什么

对 Legacy Monolith，不应该第一步就按技术结构切割。

先找业务上的断裂线。

哪里变化最频繁？ 哪里经常发生业务冲突？ 哪里让 Team 等待？ 哪里的 Data Ownership 模糊？ 哪里必须协调 Release？ 哪里因为 Coupling 阻碍真正的 Product Development？

这些问题会产生更好的 Architecture Question：

• 哪一项业务 Responsibility 可以真正由一个 Team 拥有？
• 哪些 Data 属于这项 Responsibility？
• 哪些 Decision 可以由这个 Team 独立完成？
• 它需要哪些 External Interface？
• 哪些 Event 真正表达业务事实？
• Monolith 的哪些部分可以增量 Strangle？
• 这条边界产生什么 Business Value？
• 减少什么 Risk？
• 改善什么 Delivery Capability？

只有当 Responsibility、Data Ownership 与 Change Pressure 对齐时，才值得创建新的 Service。

只有当 Domain Event 真正支持 Loose Coupling 时，才值得使用 EDA。

Central Data Model 不应该被当成万能解。

Shared Model 应该被怀疑，而不是默认接受。

Integration Layer 不能成为新的 Monolith。

Architecture Knowledge 也不能只存在于三个永远不能同时休假的人脑中。

2026 年的 “service-oriented” 必须意味着更多

如果 2026 年还在说 “service-oriented architecture”，就应该非常明确地说明具体含义。

如果指的是：Domain Responsibility、Clear Ownership、Autonomous Team、Stable Interface、Independent Changeability——很好。

那我们讨论的是有意义的东西。

如果指的是：Central Integration Layer、Central Data Model、Service Catalog、Governance Board、Technical Reuse 与 Target Architecture Theater——那就是警告信号。

SOA 并不愚蠢。

但旧式 SOA Reflex 很危险。

如果组织仍然集中式思考，Service 救不了 Monolith。

Distributed Deployment 不等于 Distributed Responsibility。 Technical Service 不等于 Domain Autonomy。 Integration Hub 也不会因为吸引了很多箭头就自动成为 Architecture Model。

真正的测试其实很简单：

一个 Team 能不能理解、实现、测试并 Deploy 一项业务变化，而不需要先同步半个组织？

如果不能，这个架构就不自治。

无论它有多少 Service。

SOA 很少是因为 “Service” 这个概念本身失败。

它更常失败在企业把 Centralized Intelligence 当成了 Architecture。

因此，2026 年拆 Monolith 时，不应该首先问最终会产生多少 Service。

应该问：

最终增加了多少真正的业务 Autonomy？