去券商面试说"我建议把集中交易拆成微服务"，大概率会收获礼貌的微笑。这篇解释这个微笑：不是技术审美问题，是一组硬约束下微服务方案确实解不动。
先澄清：集中交易不是"没架构"
恒生、金证那代集中交易系统，形态是 C/S 两层加数据库的巨型单体：营业部客户端、交易中间件进程组、Oracle 核心库。拆开看每一层都有明确的工程设计，单体的是部署形态——全公司一套应用、一个版本、一个库。真正的架构重心在那个核心库上：所有账户状态落在余额表里，行锁就是并发控制机制，一次委托校验是几条 SQL 或一次存储过程调用，天然原子。
所以要讨论的不是"微服务 vs 没有架构"，而是"这套状态集中、调用进程内的设计，能不能换成服务自治、数据分库的样子"。
为什么换不动：三道墙
第一道墙：一致性。 委托校验要同时看可用资金、可用持仓、黑名单、限仓名单。单体内这是一次查询或一段存储过程，毫秒级、单事务。拆成"资金服务"和"持仓服务"两个自治服务、两个库之后，"冻结资金 + 冻结持仓"变成跨服务的分布式事务，三个标准方案全都卡壳：
- 2PC：协调者阻塞，锁持有时间跨多次网络往返，毫秒预算直接爆；
- TCC：Try 阶段要预留资源，但委托在 Try 时根本不知道会不会成交——预留是撮合结果驱动的，语义对不上；
- Saga：用补偿事务回滚，可成交是不可逆的，金融场景里没有"补偿撤销成交"，只有反向交易。
第二道墙：延迟。 服务间一次 RPC 0.5~2ms，一次委托校验前后调五六个服务，还没进撮合预算就用完了。单体里这些是进程内函数调用，纳秒到微秒级。低延迟手段那篇（《低延迟手段：内核旁路、RDMA、FPGA》）讲的军备竞赛，前提就是别在链路上堆网络跳数。
第三道墙：发布与审计。 核心系统要求全链路同版本运行，监管审计要求"任一时刻的系统状态可完整回溯"。微服务的独立发布意味着前后台版本矩阵，回溯一个历史时点是笛卡尔积式的组合爆炸——合规上是灾难，运维上是每晚数一遍"今天到底多少版本在生产"。
微服务不是不存在：它在离钱远的地方
券商系统里微服务早已大规模落地，只是位置很明确：营销、资讯、APP 后端、客服、积分商城。这些系统的共同画像：
- 一致性要求弱：资讯晚一分钟没人投诉；
- 延迟容忍高：秒级响应完全够用；
- 和核心通过明确契约解耦：文件、MQ，最终一致。
判断一个系统该不该微服务，一句话：离钱近的保持单体，离钱远的随便拆。更精确的说法是按一致性边界切：一个业务闭环内强一致，闭环之间文件或 MQ 最终一致。账户、委托、清算各自是一个闭环，但它们共享同一套账务库和同一个日终批量窗口，所以物理上仍然是一个系统。
真正的演进方向：单体应用 + 分布式数据库
新一代核心建设的共识路线，不是把应用拆碎，而是把水平扩展的难题下沉给数据库：应用保持单体架构不变，存储从 Oracle RAC 换成 OceanBase、TDSQL 这类原生分布式数据库。对应用来说它面对的还是一个逻辑库，行锁、事务、SQL 语义基本不变；扩展性和同城多活由数据库层解决。应用层的微服务化收益（独立伸缩、独立发布）在核心系统里本来就被前面三道墙抵消了，下沉给数据库之后连最后一个理由也没有了。
微服务在券商的失败案例和互联网的成功案例，讲的其实是同一个道理：架构风格没有先进性，只有适配性。一致性边界画在哪，系统的形态就被决定在哪。