前两篇分别给AI原生与可扩展收了口。这一篇对比两代金融（资管）核心产品的技术架构，回答一个悬而未答的问题：高内聚的交易内核，是早先简洁的单核好，还是如今拆成的多核好？
先对结论做以摘要，再做阐述：
双环双核两入口，“交核”存算各扩展；
“智核”AI Inside，新构智能Rust。
一、承前总结
前两篇的架构目标，可概括为一句：“双环双核两入口，金融极速可扩展，智能AI Inside，新构组件Rust”，内涵已在前两篇说明，这里不再赘述，只作简单解释：
双环，内环是高内聚的交易内核——交易、合规、可用；外环是解耦的外围——清算、运营、报表、管理、前端。内环求稳求快，外环求变求活，节奏不同，不能互相绑架。
双核，内环以确定性代码为核心大脑，外环逐步走向以AI核心大脑。
两入口，指UI交互。嵌入原应用的入口与新的对话入口按场景并存：贴近实时交易的走嵌入，开放式中后台走对话。
AI Inside，是智能的实现路径：把AI原生增量嵌进原有应用，而不是推倒重建。
Rust，是选型：新建高性能组件，尽量选AI编码友好的Rust。
如上是对前两篇文章至今的架构总结，回答了内环核心中单业务域（交易、合规或可用）的高性能扩展性方案，但还遗留了一个最关键的问题：高内聚的交易内核，到底要高内聚到什么程度：是过去的一体单核好，还是现在的分拆多核好？这个遗留问题不回答，核心产品的架构演进目标问题就始终没有得到完整问答。
二、新问题：一体单核，还是多个核？
内聚的反面是耦合，但内聚不等于集中。一个核与多个核是两种架构承诺：前者承诺简单与一致，后者承诺隔离与独立演进。二十年里，两种承诺都兑现过，也都付过代价。
所以不能靠偏好回答，只能回到历史。
三、历史：从一体单核到多核拆分的争议
优秀的老核心系统，是极精简的一体单核架构。数据一致、计算统一、清晰简洁——今天听来平淡，当年却是硬指标：一笔业务从受理、记账到清算全在一个进程里完成，事务边界就是业务边界。没有跨系统同步，没有复杂的分布式事务，也没有“这份数据以谁为准”的争论。这是单核最值钱的地方，也最容易被后来者低估。
后来，清算、运营、运维、管理、前端等外围先被解耦，核心交易的单核也拆成交易、合规、可用三核，理由同样充分。三类负载形态本就不同：有的写多读少，有的读多写少，有的批量吞吐优先。挤在一个核里，清算的高峰会顶高交易的时延，一条合规规则上线要连带交易发版，一次慢查询能让整个核心停摆。拆，其实是业务规模和预期逼出来的必然。
代价随之而来。同一份持仓在三个核里各存一份；一致性只能靠业务代码多核间同步维持，同步就有延迟、有失败，就得写补偿；跨核事务把原本一个本地事务能解决的问题，变成需要精心设计的分布式状态机；原本单核下一个本地事务、一把锁就能解决的“查与写”，现在因为校验（如查合规、可用）和写入（如交易落单）跨越了节点，直接退化成有并发漏洞的“先查后写”，即使在实践中采用了类似乐观事务的并发共享表方案来解决悲观锁带来的性能损耗，但依然带来了业务维护多套数据一致性与较大的复杂性。更要紧的是，每个核各自仍有扩展性问题——第二篇的“以合解分”只做了局部解决，多核并存的整体复杂度并未减少。
因此直到今天，对目前经拆分的多核架构都有争议：搞这么复杂，对吗？值得吗？
四、拆与不拆都不是答案
看到拆分带来的问题，不少人很容易怀念当年单核的好。但人们时间久了时常会忘记旧痛：一旦把交易、清算、合规甚至查询压回一个核，当年发生过的互相拖累立刻返回——大额清算拖住交易线程，复杂查询打满内存，一次合规规则上线让整个核重启……,看来拆的大方向依然成立。
拆有问题，不拆也有问题，怎么办？可能症结并不在“拆”，而在于怎么拆。
五、症结：存算耦合，只能各拆各的
把现有架构拆开的每个核打开看，结构一模一样：数据与计算紧耦合在同一节点，计算进程管着自己那份数据，Shared Nothing，读写都在本地内存完成。
优点很明确：省掉数据从存储向计算搬迁的网络开销。这既是极速的主要来源，也是当年拆分时可用的主要技术手段。
但带来的问题同样明显。第一，多核之间的实时一致性只能靠应用层保证，同步、补偿、对账全写在业务代码里。第二，扩展只能各拆各的：交易核要扩，连存带算复制一份；合规核要扩，再复制一份。分片在域内有效，三个域各分各的，拼到一起，跨域联合计算与一致性又成新问题（系统的上篇文章正是针对此）。第三，存与算捆在一起扩，不管也说不清瓶颈在数据还是在计算——多买的机器，加的是算力还是容量？有时只能过度配置。
六、解法：存算分离；算扩算的，数扩数的；数据共享Shared Everything
本文结出金融内核进一步的演进目标：既不该回到单体，也不该长期坚持存算耦合的多核分拆。解决方案是把交易、合规、可用乃至未来新增的极速业务，“存”与“算”分开——即把第二篇在一个业务域内的存算分离策略，放大到整个内核。
一句话：存算分离；算扩算的，数扩数的；数据共享Shared Everything。计算按业务独自分片；数据也可以分片，但对所有计算节点透明共享。
这样便解开了两组矛盾。拆，是为了计算隔离：交易、合规、可用互不拖累、互不裹挟，各自扩缩、发版、压测。合，是为了数据一致：同一份持仓、同一个头寸、同一套口径在内核里只有一个来源，这份数据的一致性不再由业务代码维持，而由共享数据设施保证。老派单核最值钱的性质——单一数据视图——保住了；现状多核最有价值的性质——负载隔离与独立扩展——也保住了。
换一种说法：一致性下沉到数据层，负载隔离上移到计算层。
七、目标架构：计算节点群 + 分布式内存数据设施
从老派旧核心，到现状核心，再到理想演进架构的三阶段演进对照可见图3：a 是传统核心，b 是现状核心，c 是本文主张的目标形态。下面分从数据、计算两端来看：
数据侧：交易、合规、可用乃至其它业务的数据，由一套分布式内存数据设施统一承载。多副本一致性、分区、故障切换是它自带的能力。数据怎么扩、分区怎么划，在业务分区策略的约束下交给数据设施。（很多情况下，图b拆分成多核后的内存数据设施，充其量只是有集群能力，并不是真正的分布式）
计算侧：交易、合规、可用的计算节点各自按需扩展。所有数据节点对所有计算节点，就是一个共享存储——逻辑上只有一个节点。存算各扩各的，互不牵制。
图3 交易核心的三阶段演进：a 传统核心，前端、计算、数据三层堆叠，算存同机同库；b 现状核心，交易、合规、可用三个算存一体节点构成内核，清算与前端、运营、报表、运维、管理一起组成外环；c 理想演进内核，外环不变，内核是计算按业务分群、数据合为一个设施的存算分离结构
于是算与存的扩展可以并不对称：计算节点几十个、数据节点只有几个，或者反过来；交易的计算节点多、合规的少。这更贴近业务的真实需求——交易对算力，可用对时效，合规对规则的扩展要求与比例本就不一定相同。而存算耦合则做不到，只能上下等比复制。
至于计算节点与数据节点之间的“网络”开销，仍用计算下推把计算推到数据侧来解决：能下推到数据侧完成的过滤、聚合、连接，就不把明细拉上来；计算跟着数据走，明细不出数据设施，只回传轻量结果。这也是内存设施与磁盘共享存储的关键差别——内存级时延加下推，“共享”才不会退化成“绕远路”。
而上一篇讨论过的公共数据冗余，这里不必再操心：数据集群对所有计算节点就是一个节点，公共数据本就共享，多副本与一致性由设施自身保证。交给专业的数据设施提供者，总比交给每个业务产品的开发者可靠。
八、目标架构四个躲不开的追问
其一，交易、合规、可用之间的事务一致性怎么保证？分两层。一次提交内，归数据设施。 交易落单、可用扣减与合规留痕同处一个边界，设施保证“要么都成、要么都不落”。业务代码只声明边界、处理重试，不用再搞双写、判半成功或写回滚——三份独立数据最疼的就是这里。一笔业务走几道流程，就复用几次这样的事务，无需各写补偿。这还能顺带消灭“先查后写”的并发窗口：校验与写入同处一个事务，校验即写入的前置条件。（注：设施管不到的外部系统除外，只能靠对账兜底。）
提交之外，留在计算侧。 能不能放行是合规节点的判断；是否报盘、成交后怎么簿记、失败怎么退回是交易侧的状态机。这些设施给不了，跨日跨批更兜不住，只能靠幂等加少量补偿。
一句话：设施保证“要么都成、要么都不成”，保证不了“该不该放行”；数据一致性下沉设施，业务一致性留在计算，补偿从“补数据”退化为“补状态”。 前提是设施必须强一致，不能是最终一致的缓存拼盘，否则方向不成立。
其二，存算分离会不会把本地内存访问变成网络访问？会，但影响可控：计算节点与数据分区做亲和调度，尽量同机、同机架；计算下推把跨网络往返压到最少；内存级时延把单次往返压到微秒级。而且 图b 现状架构的本地内存也不是白给的：跨核的同步、补偿所付的时延与失败，未必比这微秒级的往返小。当然极少数对每一跳都敏感的路径仍需就近部署——这是工程配置问题，不是方向问题。
其三，“存”要合到什么程度？答案是合到一个事务边界内。对一次提交要写两处的业务，放进同一套数据设施；而跨边界的业务则允许最终一致。边界划清，“合”才不会重新退化成单体。清算就在边界之外：它是吞吐型业务，本质上算不上内核的一部分，作为内核数据的可用方放在外环——读同一套口径，允许最终一致，靠对账兜底。
其四，数据设施自己会不会成为瓶颈或单点？可能会——简单把多业务数据往一处扔不做规划就有可能。所以共享数据设施必须能分区、多副本、在线扩容，也可以按业务域部署多套。因此这里的“合”是逻辑上的合，不是物理上的一台机器，是优秀的分布式内存数据设施。
九、与“以合解分”的关系：同一思想的两个尺度
前面第二篇文章提到的“以合解分”，是在一个业务域内做存算分离：分片节点当存储，联合节点当计算。本篇把尺度放大到整个内核：分片节点群变成数据节点群，联合节点变成计算节点群。同一条思想，换了个尺度。
对比前文中提到的单业务扩展的七个原则大部分依然有效：业务驱动分片变成计算分片与数据设施 “分区策略”。明细计算下推、TN增量计算、分母公用冗存，被共享数据设施吸收，不再由业务代码实现。有一个变化：联合节点消失了。跨产品、跨业务的联合计算不再需要专门节点，因为任一计算节点都能读到全部分区；算力不够，多加几个计算节点就是。因此前文第二篇里“联合”节点是个架构上的特殊角色，这里退化成普通的并行计算。特殊角色的消失，往往是架构成熟的标志。
十、结语：三角难题的拆解
至此就有了本文开头对两篇文章的总结调整：
双环双核两入口，交核存算各扩展；
智核AI Inside，新构智能Rust。
从“金融极速可扩展”到“交核存算各扩展”，改的不是修辞，是组织方式：前者是笼统的目标，后者说清了业务内核的计算与存储，各按各的节奏扩展。
回到标题的三个词。极速、一致、高可扩展，在存算耦合的架构里是个三角难题：要极速就得本地，要一致就得集中，要扩展就得复制，三者互相拉扯，每次都得牺牲一个什么。而存算分离策略下的新架构把这个三角拆开了：极速交给计算下推与内存时延，一致交给数据设施的多副本协议，扩展交给算与存的独立Scalable特性。三件事各归各的机制，不再互相牺牲。
这也是本系列文章一以贯之的原则：金融架构的演进，不该把互联网的通用答案当默认答案，也不该把某一代的局部最优当终局。该拆的拆——按业务拆计算；该合的合——把数据合成逻辑共享的一体。拆得清楚，合得干净，极速、一致与高可扩展才可能同时成立。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/m0_53773302/article/details/169250937
