面向服务的方法（SOA）：20年前的"老古董"，为什么今天还在救你的命

2006年，你能在网上找到一堆SOA的PPT和咨询报告。

那时候SOA概念火得不行，企业们排队找IBM和Oracle做"企业服务总线"，仿佛接上ESB就能打通任督二脉。然后微服务来了，ESB成了"上一代的笨重中间件"，SOA这个概念也跟着过气了。

但如果你仔细看今天的技术架构，会发现一个有意思的现象：微服务做的事，本质上还是SOA那套思想——服务化、标准化、解耦。只是换了个壳，ESB换成消息队列，SOAP换成REST。

这让我觉得，SOA不是过时了，而是它的设计原则终于被搞懂了。

SOA到底是什么？三层楼的比喻

SOA的核心只有三个字：粗粒度。

大白话就是：别让服务太碎。一个"查询用户"是细粒度，一个"处理订单"是细粒度，但"完成新员工入职"是一个粗粒度的服务，里面可能调用了几十个细粒度操作。

SOA把这个分成三层：

最底层是操作（Operation）——单个逻辑工作单元，类似编程里的方法，读写数据。

中间层是服务（Service）——一组相关操作的逻辑分组。比如"客户画像服务"包含"按电话查客户"、"按地址查客户"、"保存客户信息"三个操作。

最顶层是业务流程（Business Process）——多个服务组合起来完成一个完整业务。"新员工入职"可能调用了"创建账号"、"分配权限"、"开通门禁"三个服务。

这个分层的关键价值在于：业务和技术可以分开谈。CEO说"我要优化入职流程"，技术团队改的是最顶层的业务流程，而不是底下的每一个细粒度操作。

为什么ESB成了背锅侠

SOA在企业落地的最大障碍是ESB。

ESB（企业服务总线）本意是好的——所有服务都接在总线上，总线负责路由、协议转换、消息格式转换。服务之间不用一对一对接了，都跟总线对接就行。

问题在于，ESB本身成了中心化的单点。

当ESB挂了，所有服务全部瘫痪。当ESB性能不够，整个系统跟着卡。更糟糕的是，ESB集中了太多逻辑——路由规则、转换规则、业务规则——慢慢变成一个无人敢动的超级大国。

所以微服务来了，说"去ESB，每个服务独立，服务间用轻量协议通信"。这是对的，ESB确实太重了。

但讽刺的是，今天的微服务架构里，消息队列（Kafka/RabbitMQ）其实就是ESB的轻量化版本，只是没有中心化单点的问题而已。

SOA踩过的坑，微服务用新工具又踩了一遍。

银行系统为什么还在用SOA

如果SOA真的过时了，银行业不会还在用。

银行业的IT系统有几个特点：监管严格、不允许停机、数据一致性要求极高。所以他们反而是SOA思想最彻底的实践者——不是因为守旧，而是因为确实有用。

核心原因是解耦。

支付系统和风控系统解耦。支付的时候不需要等风控引擎响应，风控是异步的。支付事件发出去，风控系统自己订阅、自己处理。如果风控引擎挂了，支付继续跑，不会连锁崩掉。

这在架构上叫"最终一致性"，不是"即时一致性"。订单表更新了，库存系统收到事件、慢慢更新，不用同步等。用户体验稍有牺牲，但系统韧性大幅提升。

这种设计在互联网公司也常见。只是银行更早被迫想清楚这件事，因为他们的业务不能停。

SOA真正教会我们什么

回到考试大纲，SOA的核心原则是这几个词：封装、自治、无状态、松耦合、可发现、可复用。

我的排序不一样。最重要的是这两个：