金融高性能交易类的产品，在架构演进中，基本都会遇到一个共性问题：高性能目标下的可扩展性（Scalable）方案。本文结合实践讨论这个问题的目标设定：是把互联网的通用可扩展架构当作默认答案，还是立足金融业务特征，设计自己的高性能Scalable架构。文章选择后者，并把"以合解分"展开为七个技术原则，让它从架构思想落成工程方法。
这套策略，先凝成八句策诀：
业务为纲驱分片，产品指标时间裁；
存算分离解联合，计算下推决明细；
增量续算承前果，分母冗存免输传；
新构智能RUST，"以合解分"极速存。
一、共性问题：高性能目标下的可扩展性
单体系统的性能总有用尽的一天：业务量上来之后，要么纵向换更大的机器，要么横向把系统摊开。纵向很快会碰到天花板，于是横向扩展------Scalable------成为架构演进绕不开的话题。这在金融高性能交易类产品中具有共性：无论是资管的投资交易、风控、合规、决策，还是其他高性能交易产品，走到一定阶段都要回答"接下来怎么扩展"。
二、常见的目标设定：把互联网架构能力当作默认答案
相当多的情况下，会把互联网架构能力当作理想目标，追求通用的、产品级的，甚至动态的、在线的可扩展能力，计划引入对用户透明的水平分片、在线重分布、灰度扩缩容。这套目标默认了一个前提：可扩展需求是普遍的、持续增长的，值得为"通用"和"在线"付出架构复杂度的代价。互联网业务确实如此------用户量与数据量持续增长，可扩展本身就是产品能力的一部分。但金融交易类产品是不是也这样？先看实践中的事实。
三、实践中的事实：真正有通用Scalable需求的客户并不多
但在实践中，对资管这类交易系统，情况并不完全如此。按需部署多套单体系统确实存在可维护性与跨系统计算两方面的问题------多份配置、多次升级、数据分散，跨系统的汇总与穿透都要专门开发------然而真正有通用Scalable需求的客户并不多，甚至只是零星的。一家机构的业务量，绝大多数落在一两个核心产品条线上；需要摊开到几十个分片才能扛住流量的场景，在资管交易域并不常见。
这种情况下，架构演进的目标就值得讨论：是完全追求互联网架构能力，还是设计金融特色的高性能Scalable架构？目标设定直接决定架构复杂度、研发投入与最终性能，也决定后续每一个技术选择的方向。
四、互联网的解法："以分解合"
互联网架构解决通用高性能Scalable的设计思想是"以分解合"：面向用户、产品、运维都完全透明的水平分片扩展------数据按统一规则（哈希、范围）均匀切分，动态扩缩容、在线重分布，配合分布计算的执行计划与算法优化、网络与IO优化。任何一块数据在任何分片上都可承载，扩容就是加节点、搬数据，缩容反之，一切对上层透明（见图1）。这套架构可以参考，但不一定是金融交易类产品的通用目标------它的通用性，是用Map/Reduce式的两阶段计算、复杂的执行计划优化与可观的工程复杂度换来的。
图1 "以分解合"：互联网通用水平分片架构（对用户、产品、运维完全透明的动态在线扩展）
五、金融的解法："以合解分"
金融交易类产品，也可以考虑"以合解分"的架构策略，即对Scalable要求高的客户，以产品或者业务分片，而不是通用水平分片。分片单位不是抽象的数据块，而是业务上天然存在的边界：一个产品、一条业务线、一个组合。跨产品/业务的联合计算，则由专门的联合节点承担。
对资产交易这类产品，形态是"联合节点 + Hub"：Hub 位于所有分片节点之前，交易请求由它统一路由到分节点，各分节点只处理自己分片内的交易；联合节点承担横跨分片的产品/规则联合计算------跨分片的汇总、穿透、归因，在这里统一完成 Reduce。
对CMC这类合规产品，则不需要 Hub：联合节点与各分片节点并列，合规检查请求广播到相关的分片与联合节点，各自检查、结果汇聚。
无论哪种形态，联合节点的角色一致：它是存算分离架构中的计算层，而不是单纯的转发者。其设计思想有四条：
**一是存算分离。**分片节点本质上被当作存储节点，联合节点专职计算------这是存算分离在金融交易域的有限实现：不做通用化，只做业务需要的部分。
**二是计算下推。**尽最大可能"计算动、数据不动"：能下推到分片的计算（片内汇总、指标分子分母的组成元素）一律下推，各分片并行算完，只把轻量的中间结果回传联合节点。
**三是公共数据冗存。**位于"分母"上的数据、跨片公共的数据、非线性计算所需的数据，在必要时做跨分片的多副本冗余存储，以一致性协议保持同步------以冗余换性能，消除实时搬迁与跨片等待。
**四是增量计算。**无论分片还是联合节点，对明细流水都尽量增量计算：新数据只带来增量项，旧结果直接复用，而不是指标与规则每次从明细全量重算。
无论哪一种，分片对应用都是透明的，无需用户选择分片------客户看到的仍是一个完整的产品，而不是若干互不相干的实例。一套相对通用的策略，就此替代了部署多套单体的旧办法：重复运维没有了，跨产品/业务的计算也不必再专门打通（见图2）。
图2 "以合解分"：产品/业务分片 + 联合节点（橙色为算、绿色为存；a 资产交易类：联合节点 + Hub；b CMC 类：并列广播）
六、 " 以合解分 " 的落地：七个技术原则
分片只是起点。第五章的四条思想------存算分离、计算下推、公共冗存、增量计算------需要落成可执行的工程规则：联合节点怎么摆、跨片怎么算、明细怎么搬、指标怎么续、分母怎么存、新节点怎么建。把它们总结、抽象，再加上支撑落地的工程前提，就是七个环环相扣的技术原则。
**第一个原则：业务驱动分片。**金融的Scalable，分片的依据应该是业务本身，而不是数据的哈希值------本质是按业务特征做垂直切分，而不是经典分布式技术的水平分片（Sharding）。业务驱动的分片，边界与业务结构重合，一个分片内部的交易与计算天然封闭，绝大多数指标在片内即可闭环完成，既不需要跨片协调，也不需要复杂的路由规则。这是"以合解分"全部设计的出发点。
**第二个原则：切分维度可选产品、指标、时间。**业务驱动分片并不是只有一种切法，可以根据业务特点灵活选择：以产品切分，一条产品线一个分片；以指标或规则切分，不同的合规指标、风控规则各归其片；以时间切分，不同时段的交易数据各成一块。三种维度可以单独用，也可以组合用。维度选得准，片内计算的封闭性就越好，跨片联合的负担就越轻。
**第三个原则：联合存算分离。**分片之后最棘手的问题，是不同分片之间的联合计算------典型如跨产品的合规指标：所有产品的合计持仓不得超过某只股票总股本的10%，天然横跨所有分片。解法正是第五章的存算分离：各分片节点充当存储，跨片联合计算由独立的联合节点统一承担。存储归分片，计算归联合节点，各司其职，跨片计算便有了着落。
**第四个原则：明细计算下推。**联合存算分离的性能上限，取决于传输什么。若把各分片的数据明细原样传到联合节点，网络与计算开销会随数据量线性放大，高性能可扩展便落了空。因此要尽可能下推：各分片先并行汇总片内明细，再把轻得多的中间结果传给联合节点------让计算去找数据，而不是让数据来找计算。这与"以分解合"的两阶段计算形似而神不同：这里的分与合由业务预先定死、静态可预期，无需通用执行计划优化器在运行期临场决策，性能差距正源于此。
**第五个原则：TN增量计算。**交易指令逐笔到来，若每笔新数据都触发从明细开始的完整重算，再强的硬件也扛不住。应在上一个时点TN结果的基础上做增量：新数据只带来增量A'与B'，跨表联合增量可按(A+A')(B+B')=AB+AB'+A'B+A'B'展开------旧结果AB直接复用，只补算AB'、A'B与A'B'三个增量项。全量变增量，计算量从存量规模降到流量规模，这是高性能的另一个来源。
**第六个原则：分母公用冗存。**许多指标的分子各不相同，分母却是共用的------占比类指标的总股本、总资产就是典型；跨片公共数据、非线性计算所需的数据，同理对待。对这类数据，可以在每个分片节点上多副本冗余存储，依托一致性架构保持同步。如此，实时计算时分子在片内、分母也在片内，数据无需实时搬迁，跨片等待被彻底消除。以冗余换性能，在存储成本远低于计算与网络成本的今天，是一笔划算的买卖。
**第七个原则：新构智能友好。**联合节点往往是新构建的，这恰好是技术选型的窗口。第一阶段可以沿用原架构微调，以加快上线速度；但长远考虑，应该选用对AI大模型友好的语言来开发------例如以Rust替代C++。Rust在保证乃至超越C++效能的前提下，内存安全与类型约束更强，AI代码生成的可靠性显著更高。当AI编程从辅助走向主力，语言的选择就不再只是工程师的偏好，而是人与智能体协作效率的先决条件。
七、 " 以合解分 " 的取舍：性能占优，复杂度可控
客观地说，"以合解分"在不同用户那里不能完全做到通用，需要前期一定的工程配置------分片边界要结合客户的业务结构来定；也不容易实现动态扩缩容、在线重分布这类高级能力------分片边界一变，工程上就要重新配置。
但权衡下来：一是动态扩缩容、在线重分布这类需求，金融实践中本就稀少；二是客户数量不多，前期配置是一次性成本；三是它避开了通用分片Map/Reduce的性能损耗与执行计划优化的复杂度；四是七个原则处处做"减法"------业务定边界、下推省传输、增量省算力、冗存省搬迁。对高性能交易系统来说，这些"减法"恰恰最值钱：同样的硬件，路径更短、开销更少，性能一定占优。
八、结语
金融产品架构演进中，"以分解合"与"以合解分"没有高下之分，只有场景之别：通用需求密集、数据持续增长的产品，借鉴前者；需求零星、以确定业务边界为主的高性能交易产品，后者往往更划算。"以合解分"并非互联网架构的简化版------它以业务分片为纲、联合计算为骨、下推与增量为翼、冗存为盾、智能友好语言为远谋，自成一整套工程方法论。互联网的Scalable以数据为中心、以通用为名；金融的Scalable以业务为中心、以高性能为实。按产品与业务的实际情况选择，不必一概而论。