SOA 没死,只是改了名

上周闺蜜小美给我发来一张她公司的架构图,问了个特别朴素的问题:你帮我看看,我们这套算什么架构?

我看了十秒,回她两个字:SOA。

她愣住了。这个词她听过,但印象里它和 ESB、SOAP 埋在同一层土里,属于十年前的技术杂志。一套 2026 年还在生产上跑的系统,怎么会是一个「过时」的架构?

这个问题值得单独写一篇。因为按我这二十年看过的企业系统,答案适用于其中一大半:你们公司现在跑的,很可能也是 SOA,只是没人这么叫它了。

先看图

细节我重新画过,业务也换掉了,你可以把它想象成一家连锁餐饮品牌的数字化体系:

【此处插入配图:连锁餐饮四层架构示意图】

从上往下四层:

最上面是终端,四个入口对着四类人。顾客用的点餐小程序、门店用的收银出餐端、骑手用的配送 App、加盟商用的管理端。

第二层管进门,小程序开放网关、第三方服务配置(支付、地图这些)、统一认证(就是图里的 SSO:登录一次,四个端都认你)。

第三层是正事所在,三个大家伙并排站着。门店运营中台(里面装着营销活动、菜单商品、规则引擎、会员数据),旁边是供应链系统,再旁边是财务系统。

最底下是数据平台和基础设施:数据库 MySQL、缓存 Redis、消息队列 MQ、搜索引擎 ES,这些老朋友。

如果你只能带走这张图的一个细节,带走第三层角落里那行小字:对等系统 · 集成协同(非上下级)。

就这一行字,暴露了整套系统的血统。

为什么这是 SOA

SOA,Service-Oriented Architecture,面向服务的架构。教科书定义拗口,人话版本就三句:

把公司按业务能力切成几个大系统。每个系统管自己的事、守自己的数据。系统之间靠接口和消息说话,谁也不是谁的爹。

拿这三句对一遍上面的图。

按业务能力切分:中台管门店运营和营销,供应链管食材从采购到配送,财务管钱。切分依据是业务的天然边界,跟用什么技术栈没关系。

各守各的数据:供应链的库存数据、财务的对账数据、中台的会员数据,各在各的库里。中台想知道今天鸡腿还剩多少,不能伸手进人家数据库查,得调接口。接口的学名叫 API,说白了就是每个系统对外开的服务窗口:你在窗口排队问,我在窗口答,后厨不许进。

对等协作:那行小字写得明明白白,「非上下级」。财务不是中台的子模块,中台也不归供应链管,三个系统平起平坐,用 API 和 MQ 互通有无。

三条全中。这就是 SOA,而且是教科书都未必讲得这么典型的活样本。

那为什么大家觉得 SOA 死了

因为死掉的是它的装备,不是它的思想。

十几年前企业上 SOA,标配是一根 ESB(企业服务总线):全公司系统之间说的每一句话,都必须经过这根总管道,由它转发、翻译、排队。系统间对话用的协议叫 SOAP,一种把每句话都裹上三层信封的老式文体;信封材料是 XML,就是用尖括号标签把数据一层层包起来的那种文档;接口长什么样,还得用 WSDL 再写一份同样是 XML 的说明书。于是一个字段改动,三份文件跟着改。再配上某大厂的 SOA 全家桶,一年授权费按百万计。

这套装备笨重、昂贵、供应商绑定,后来确实死了。死得不冤。

但你看上面这张图,没有 ESB。系统之间就是点对点的 API 直连,加上 MQ 帮忙传话。MQ 是消息队列,你就当它是各系统共用的传达室:发消息的把信放下就走,收消息的有空过来取,谁也不用干等谁。为什么不上总线?系统一共三四个,拉根总线纯属给自己修高架桥,过的车还没桥墩多。

我把这种形态叫「民间 SOA」:思想是 SOA 的思想,装备是够用就好的装备。它没死,它遍地都是,只是不再自称 SOA。

单体、SOA、微服务,三个词各管一段

真正有意思的地方在这里。我问小美,你们那个中台内部是什么形态?

她说,单体,集群部署,代码做了分层和模块化。

所以你看,这家公司同时活在三个词里:

中台内部,是模块化单体。一个应用复制多份一起跑,前面站个 Nginx 当迎宾,把涌进来的请求往各份实例上摊匀,这个动作叫负载均衡。

公司层面,是 SOA。几个大系统按业务能力划分,对等集成。

微服务?一个都没有。

这三个词经常被当成进化链,好像单体是原始人,SOA 是古代人,微服务才是现代人。实际上它们管的是不同粒度的问题。单体和微服务说的是「一个系统内部怎么组织」,SOA 说的是「多个系统之间怎么协作」。微服务的本质,是把 SOA 的思想从公司级下沉到了系统内部,切得更细、部署更独立、数据库也一拆到底。

所以「你们公司是不是微服务架构」这个问题,经常问错了层。正确的问法是两个:你们公司层面几个系统、怎么协作?你负责的系统内部,拆没拆、拆到多细?

什么时候该待在哪个位置

小美的团队不到十个人。我给她的判断是:中台内部不拆微服务,是对的,不是落后。

拆微服务的代价是实打实的:分布式事务、链路追踪、独立部署的运维成本,每一样都要人力去喂。不到十个人的团队拆出二十个服务,等于每人背两三个服务的运维,业务还写不写了?

什么时候拆?判据一句话:哪个模块的变更频率或者资源需求,明显偏离了其他模块,就先把哪个独立出去。比如饭点的秒杀发券,流量是别的模块的几十倍,它就该第一个搬出去单过。图里那个虚线框的「发券服务」,就是已经单过的样子。

架构没有先进和落后,只有匹配和不匹配。这句话谁都会说,但落到具体判断上,就是上面这种一句话判据。

所以,SOA 过时了吗

词过时了,思想一直在续命,而且每隔几年换一个马甲。

微服务,是 SOA 在单个系统内部的续集。中台,是 SOA 思想的中国变体,把「按业务能力沉淀服务」推到了组织层面。这两年流行的 API-first(先把接口契约定好,再动手写实现)、平台工程(把公司的基础能力做成内部产品,各团队自助取用),骨子里还是那句话:把能力包成服务,给需要的人调用。

最新的一轮马甲你可能也见过了。给大模型接工具的 MCP 协议,干的事情是把企业能力包成标准接口,开放给一个新的调用方。这个调用方不是浏览器,不是小程序,是 AI。你可以把 MCP 理解成 AI 界的 USB 接口:工具做成标准插头,哪个模型来了都能插上就用。历史不重复,但是押韵。

回到开头。小美后来把这套讲法用在了一次述职里:公司层面 SOA,几个系统对等集成,没上 ESB 是因为系统少;我的中台是模块化单体加集群;微服务没拆,团队规模摆着,但什么时候该拆、先拆哪个,判据我有。

能把自己系统在谱系上的位置讲清楚的人,不管在会议室还是面试桌上,都比满嘴新名词的人稀缺得多。过时的词有个隐藏用途:它专门用来鉴别不过时的人。

附:本文黑话小抄(收藏用)