1.引言

这是一篇架构实践和启发课。如果你正在负责一个超大复杂型平台（比如电商、支付、物流）的架构师，且面临各种技术负债（比如架构复杂性、团队协同复杂性），同时业务又面临从平台服务，到场景化创新的转型。那么这篇文章也许对你有收获：

1）如何重塑一个10年之久的资金平台架构？

2）如何构建一个共享平台架构，驱动研发协作模式的转变，提升全局研发效率？

3）如何在平台之上，构建灵活的创新增长架构，降低创新的机会成本？

2.资金创新平台的源起

2.1什么是资金业务平台？

支撑各类业务场景的资金交易处理平台，比如一次转账，一次发红包行为（发、领、退）等等，看似简单的动作，背后其实非常复杂。第一，业务复杂度，除了收单交易，其它都可以归类为资金类交易，所以承载了非常复杂的业务模式。第二，从交易本身来看，负责交易要素的撮合，资金流处理，最后完成履约，是支付系统中承上启下的核心系统。

2.2平台到场景化创新转型

资金业务平台经历了多个阶段的演进：从一开始的巨石应用，到行业飞速发展过程中的服务化、平台化 。而最近的几年，是资金业务从工具型产品，到场景化服务快速转型的阶段，如何“既稳又快”地支撑创新试错，是对架构设计的巨大挑战。

3.问题和矛盾

3.1.表象矛盾

创新业务快速试错的诉求，和研发交付周期的矛盾资金创新的门槛高，研发交付周期一般1个月起步，靠盲目加人，已经解决不了整体交付效率问题，资金平台的应用架构，历史上跟着产品和业务线走，形成了三足鼎立、百家争鸣的局面（个人、商业、集团），随着规模化的创新，业务边界逐步被打破，能力重复建设、质量参差不齐。虽然团队一度大规模的扩张，但由于平台负债以及复杂性，无法激发业务层创新的动力，导致头轻脚重，迈不开步子。

3.2 问题的定义

3.2.1烟囱式的资金平台架构

边际成本高、能力重复建设资金平台的烟囱式架构，在历史时期做到了灵活发展、局部最优。但随着业务发展和融合，重复建设付出的成本，远远大于灵活度所带来的优势，比如tob的企业代付、和toc的小荷包，底层都是基于共享账户的创新，所有的账户资产模型、出入金流程，都需要建设一套，研发巨大的投入，显然不符合业务方的直觉。

3.2.2面向互联网增长的架构

支付宝擅长做支付平台，而面对偏互联网的场景构建、业务规模化增长，却缺乏相关架构经验，研发效率拖后腿，跟不上创新试错的节奏。

4.总体设计

架构愿景:过去一年，我们启动了资金创新平台项目群。定义了面向资金业务创新，当下和未来的大资金域统一平台架构目标。在全局设计方面，我们有个愿景，就是设计下一代面向创新的资金平台架构，让资金平台更加稳定，让业务创新更加聚焦创新逻辑的交付，下图是当初第一版设计的方向。

5.关键架构设计（一）重塑资金平台架构

资金平台（资金类交易处理），是所有资金类业务创新的根节点，支撑了上层所有业务毛细血管的生长。但是过往的实践中，由于其“三高”的特点（技术入门门槛高、实现复杂度高、稳定性要求高），交付周期太长，是大部分前线业务对“支付团队”的第一印象，严重制约了创新业务的拓展。基于存量架构负债的治理（多套烟囱），以及判断未来场景化创新，对资金能力交付效能的诉求，我们对资金域架构做了整体重构。整体上分为三个阶段展开：领域模型重构、平台化设计、能力产品化设计。

领域模型重构

5.1通过用例分析来归纳领域边界

领域要定义明确的边界，即找到一个合适的分界线（做什么，不做什么），来解耦领域之间的复杂关系。其中最关键的，是从一个个业务用例中，去识别“概念类” - 名词（领域）、形容词（能力）、动词（关系）。其次是归纳和聚类，按照独立性、复用的目的，拆解到不同的领域。定义服务之间的领域边界以红包业务为例进行分析（见下图）：红包，通过各种玩法，在好友之间传递红包。资金，由红包驱动的，收付款方的资金转移。通过需求格式化之后，我们很容易识别到两类独立的领域和能力，按照复用性，对资金处理的能力进行抽象和下沉，以便于其它场景进行复用。

定义服务内部的领域边界资金领域的本质，是将上游弱交易类业务场景的资金转移需求转化为资金订单，并以订单为载体围绕人、账、业务实体、业务资产作为参与者展开的商业行为支付、资产结算服务。资金业务领域建模 L0：从完整的业务视角，将外围的依赖和服务（收银、支付、收费、限权、安全等）的协调能力，抽象为可复用的领域组件，以组件维度整合订单域中理解的合约参数、来源上游的指令参数、对下游系统的调用参数，支撑各业务活动； 资金核心领域建模 L1：将之前的资金订单模型拆分为资金订单、资金流模型，显性化商业行为相关的资金订单流、与资金结算相关的资金流的区别；同时抽象参与者、业务资产模型，最后提供资金参与者扩展、业务资产扩展、资金订单流灵活编排、资金流灵活编排的能力，解决资金处理的复杂性和提升未来的扩展性。

5.2通过演绎来推理统一交易模型

交易模型是否能够跨行业复用？除了面向过去的归纳，还需要演绎的过程，即通过业务生命周期、和业务要素，站在更加业务宏观的角度去提出假设、加以推理，比如我们假设各种不同的订单交易类型，本质上是参与方、资产和支付的撮合的载体， 这个载体可以被不同的交易模式来组合。还是回到刚刚讲的红包的业务用例，红包这个业务后面代表的是一个多阶段订单流的交易模式，这个交易模式也可以复用到其他的业务场景，比如钉钉转账（需要收款方确认收款）。除此之外，我们服务的B、C类场景众多，沉淀下来有B2B（单笔、归集）,B2C（单笔、批量、多阶段）,C2C（单笔、批量、多阶段）,B2B2B等多种交易模式，可以说是支付体系最复杂的交易模式之一。老代码核心痛点之一，订单领域模型设计不合理老系统对于以上不同交易场景的领域模型设计较为死板：如批量、两阶段、单笔，在系统的代码设计中，对应的模型和代码设计都是烟囱型设计，导致无法消化业务创新对新交易模型的诉求。订单模型需要承担较多的下游协调能力，领域模型的烟囱型设计给「协调」工作带来更多的复杂性，使协调能力本身无法复用。重塑订单领域模型：抽出共性，发挥java语言多态的优势我们将领域模型共性部分，抽象为基础订单模型，在此基础上将父子单、批量订单等交易模式作为基础订单模型的派生或实现。这样就可以让下游协调的领域模型不再理解到具体的交易模型，使交易模式的变更和新增对系统的影响得到了有效控制。

2. 平台化设计 - 共享业务平台

平台化设计，目的是实现最大程度的资产复用，并且能够通过配置化灵活扩展。一般基于平台化设计的团队，能够基于接口契约，完成完整的需求交付，如电商的商品平台、履约平台；支付的收单平台、支付平台、账务平台等。那什么是“共享业务平台”？资金业务的特殊性，存在多业务单元、多技术团队、部分情况下还会出现交叉（B业务技术团队，承接了A业务团队的需求），很显然，平台自闭环的交付，极易形成交付热点。而业务技术团队贴近业务，可以更好地安排优先级。基于这方面的考虑，资金业务平台在设计之初，就提出了“共享业务平台”的概念。类似于商场综合体，平台化团队负责商场基础设施的规划和建设（比如水电煤、区域规划），而每个门店做什么生意、怎么装修、怎么营销，只要符合商场的规约，都可以由业务团队来直接主导。

5.3实现平台化的关键设计

5.3.1组件化设计

从福特汽车流水线得到的启示关于如何从零件级复用升级到模块、片段级别复用，我们有同学提出，之前了解到整车架构也有类似的复用设计，我们怀着学习的态度分享和学习了发展至今100年的整车架构演进，竟意外的得出关键的解题思路并进一步笃定我们的架构设计思路的正确性。1）抽象模块 - 从不同中，对比寻找共同之处。将所有车型可复用的最大公约数抽象为模块。2）通过模块组装，实现业务定制 - 相同模块内部的不同之处，表象为若干零件的功能不同，但是本质上是为了解决各类需求，如安全、尺寸、能源、排放等导致的多个零件的设计差异。如各个模块都要理解「安全级别」的约束，整车的每个模块在不同安全级别下有不同的模式表现。总结一下平台化造车的思想：为了满足不同个性化的需求，提升流水线生产效率，将整车架构按照一定原则分解为若干独立并且相互关联的模块，实现模块零件的最大通用化，并拥有通过调整组合不同模块，生产不同定位和级别车型的能力。如何实现组件的适配和组装我们惊讶的发现，所谓隔行如隔山的，另外一个完全不同的行业，在解决架构问题的思路上竟然如此类似，通过以上的阐述，我们经过思考可以归纳出解题思路：

• 零件抽象成模块，更高维度的抽象层次。
• 将各个模块都要理解的约束，抽象为统一接口。各个模块不相互依赖，依赖各项指标约束接口、衔接接口，即依赖倒置。

因此我们将可复用粒度从原来的原子化java方法，提升到模块级复用粒度的组件、组件模式、流程阶段、流程。

• 复用粒度既不会过大，过大的复用粒度比如业务流程，会导致无法消化更多的交易场景抽象和差异，最终导致业务流程的逐渐增多。
• 复用粒度也不会过小，过小的复用粒度比如java方法，不仅无法管理，而且复用性也不强。

5.3.2扩展性设计

组件得到抽象和复用了，但是我们还要满足不同场景下定制化的诉求，同样都是A->B的资金转移，但是在不同场景下，支付的规则是不一样的，比如退款周期、额度、支付渠道、安全风控等等。

我们再看来汽车销售厂商，在应对客户定制时的解决方案是什么，首先虽然很多整车制造厂商都是公用的生产平台，但是因为市场的不同定位要求，会将产品分类为轿车若干型号、SUV若干型号、MPV若干型号。这些不同的型号本身，就是带着不同的「产品特定约束」来在同一平台架构中做出来的不同产品。而且，我们在进入一个汽车4S店后，销售小姐姐往往会让你选择针对某一个型号的若干「套餐」，比如耀夜版、运动套餐等。我们经过以上平台架构化思维分析不难发现，这些所谓的「套餐」，其实本身就是为这些汽车型号，做一些「特定市场需求约束」，如在「运动套餐」约束下，汽车的轮毂参数会变大、座椅会加装运动护腰套件、汽车的颜色参数变成酷炫蓝等。而当你问，能否在运动套装中加装座椅加热功能，大多数的厂商，可能都是支持这些更个性化的定制的。

（业务架构分层）由此类比，我们也可以基于平台化架构，来给客户提供标准的产品、加装的套餐、个性化的定制。我们可以建设产品层，在平台层能力可扩展、可配置的基础上，选取特定的产品特征包装成标准产品。同时针对业务的定制，提供可选「业务能力」套餐，也可以基于业务申请的不同业务身份，做个性化的业务配置和业务代码扩展。业内很多平台，阿里电商的商业能力设计，在本质上也是通过分层交付、分层治理的形式，形成了不同层次的业务复用架构，这与我们的架构设计思路也不谋而合。

5.4 共享开发和共享运行时

场景扩展和平台服务隔离，实现共享研发模式 经过架构决策，我们舍弃了过去（产品层 prod）和（核心层 core）分两个应用的应用架构，合并为一个大平台型应用，向业务平台型应用架构演进。从前置产品层决策扩展，变为平台内场景化决策扩展，将场景化扩展以扩展包的形式在代码上与平台完全剥离，并提出「业务容器化交付」模式，使用serverless应用架构模型解耦场景化扩展包的研发态、部署态。这种通过Serverless ark模块包方式来解耦业务和平台的方式，非常适用于共享研发型团队因为无法通过拆分应用而必须在一个平台上做业务交付的情况，既能够做到平台和业务在代码态、运行态的完全隔离，平台侧能力纯净无污染；又能最大化平台能力的复用效率。

平台能力产品化设计

软件世界和真实世界应该是不断拟合的过程 - 通过模型重构、和平台化设计，资金能力的组装，可谓是更加灵活了，但是我们意识到，仅仅面向技术上的灵活是不够的，我们希望技术平台内部的能力，能够被充分描述和外化成产品的能力（产品流程、产品功能参数），只有这样，平台才能够持续保鲜和保持迭代。

5.5产品和技术能力拟合

我们都声称自己是做业务的，但我们的代码中完全寻觅不到这些核心业务概念，这就导致业务和技术沟通协同效率极其低下，原本需要1周的工作量，基本要1个月才能落地，而真正代码可能就是几行就搞定了，这类问题在支付业务中往往很常见。如下图所示，过去我们接需求的模式都是这种通用的流水线，能力的复用完全是靠架构师在边接需求的过程中边抽象，到底有哪些抽象的能力，PD很多时候靠的口口相传。我们经常谈领域驱动的设计——更强调业务领域架构，领域的抽象者跟业务应该是紧密连接的，而我们实际的情况可能不是这样。所以出现功能复用困难，产品传承困难，产品运营能力弱，本质原因是「产品能力」与「技术抽象」不一致出现的问题。 （产品和技术能力的描述靠经验）

5.6 产品能力显性化表达

所以，有没有一种方式，可以让产品能力与技术抽象咬合的更加紧密，甚至让产品能力变成产品经理可以写的「产品功能的无代码化（nocode）」，与研发写的java的代码可以建立某种关联？我们认为是可以的，我们只需要做到：

1）将技术的抽象代码以标准化的组件和组件扩展点做交付。

2）给PD提供产品功能工作台，允许用无代码化的方式定义产品功能。PD在工作台上新建资金产品，并且做产品功能的抽象，我们将产品功能抽象具象为让PD设计一个这个功能可表达的form表单，这个表单后续也可以作为产品的可运营阵地，我们叫运营视图。

3）将PD定义的产品功能与技术的抽象代码建立连接关系（合并、关联、级联、与或、条件等关系）

(技术规范转换成产品规范)

6.关键架构设计（二）- 如何让创新跑的更快

前一部分，我们重点讲述了资金能力的平台化、流水线生产。在这一部分重点是我们怎么提升业务端到端研发交付速度，帮助资金场景创新的规模化增长。如果说资金交易能力是核心引擎，那么资金场景化创新，就是连通各个零部件造一台完整的整车，并快速推向市场去售卖，实现增长。这里的关键是要“轻量”和“敏捷”。回到支付，通过以往多个产品落地的经验，我们也总结出了创新业务的产品生命周期，大体分为三个阶段：场景构建、运营增长、洞察迭代，如下图所示。

不难发现，场景构建，一般无外乎需要三大类能力：

1）面向场景模型的构建CRUD（新建）：比如做一个账户关系和聚合、账单的动态和评论，这些都有领域特性，且找遍了全站也找不到可复用的平台系统，这时候我们是需要交付新领域服务的CRUD能力的。

2）中台类领域服务编排（复用）：比如涉及到账户（共享账户）、资金类交易（充值、转账、提现）、社交、资产核心、收银支付、安全等领域能力，这些能力我们明显无需重复建设，我们只需要协调蚂蚁庞大的中台系统，如下图我们的链路中fundapplication依赖了众多其他域的能力，最终我们编排并开出mobilegw接口，并与前端约定好接口协议标准。

3）最后通过一个个前端的组件，构建出页面和流程。总结：资金场景创新的领域本质 = 场景领域的构建CRUD（新建） + 现有领域能力的编排和聚合

1. 轻量化搭建和增长体系

有一部分的场景构建，都是轻量化的页面和流程，举几个我们CY21年创新业务的常见案例，比如蚂蚁合花（小荷包）产品的开户拉新场景、转账生活费场景、C/B的新余额小程序阵地等。

这些偏固定阵地、营销阵地的产品研发，基本分为前端小程序交互页面（前端）+内容服务（服务端）+简单的功能交互服务（服务端），除此之外产品和运营同学可能会针对这些阵地提一些精细化运营诉求以及运营后的数据分析诉求。一站式搭建和增长平台我们在CY21年着手建设低代码搭建平台：拥有精细化运营能力、快速搭建、数据智能、多端开放等多种能力的一站式运营平台，为研发、运营提效。1）快速搭建：面向 场/阵地/产品页 提供快速低代码搭建的一站式解决方案,提升前端和后端同学的研发效率。——本质上是将模式相对固定的这块领域，将传统的手动服务化聚合模式升级为前后端一体化的模板化方式，做产品化升级。2）精细化运营：可业务自助的一站式的 基于页面/模块的 千人千面精细化运营能力，极大提升业务运营的效率。——模板化一定可以向nocode方式演进，nocode一定会带来生产关系的变化，这部分工作从技术人变成业务自助了，可以说是双赢。3）数据智能：完整的全链路数据标准 和 标准搭投数据效果产品，通过统一埋点、离在线数据洞察体系，注入运营过程中的运营策略和业务指标，满足运营同学在运营过程中的数据洞察需求，提升业务增长的转化。——统一模板化之后，数据很容易统一，也是统一化、模板化带来的业务红利。

我们用领域抽象、lowcode在运营页面构建领域，做到了前后端一体模板化提效，我们以一站式搭建为例，讲述我们是怎么通过lowcode方式带来提效的。构建层面，我们抽象出内容、策略领域模型，将我们下游依赖的能力基于不同的领域视角来做统一编排和聚合，并最终在搭投模块与前端同学合作，制定协议标准和前端组件沉淀标准：1）通过内容接口、策略接口，将蚂蚁各大内容中台、策略和实验中台的能力全部编排为一站式搭建的基础能力，并转换为可配置化交付的产品研发体系，让内容、策略相关的需求无需研发。2）搭投模块，通过将一个运营页面做整体抽象，将运营页面的结构整体拆解，并通过与前端团队合作，沉淀出若干可横向复用的前端组件和模版。将后端服务需要供给给前端的内容、数据、运营策略服务聚合为一套mgw标准接口。让页面前端构建和后端服务的研发成本降低一倍以上。

2. 轻量化应用研发模式

Serverless创新架构一站式搭建，解决的轻量化场景的构建和运营，虽然覆盖范围广，但是本身有局限性，只能是基于简单组件和成熟能力的编排和构建。复杂的场景，还是要通过标准的后端服务，来支撑场景服务能力的输出（包括场景模型的构建，和服务的编排）。在场景化创新的演进过程中，为了和资金处理解耦，我们专门建设了资金场景化应用（fundapp），研发协作上，也从一开始的几个同学，到几个业务团队，几十个研发同学，都在一个创新应用上研发，通过多个bundle区分不同业务，公共的bundle沉淀通用能力和研发工具，如下图。 这种架构设计，遇到爆发式创新，逐步沦为了巨石应用，主要面临几个问题

1）研发运维效率低：作为入口系统，网关接口无法在本地开发自测，改动任何代码必须发布到联调环境。发布一次，动辄10分钟，还要忍受环境不稳定带来的问题。

2）业务迭代抢占，协同成本高，火车式发布迭代痛点明显——一人晚点，全体延期。

3）研发时隔离效率低：随着单系统承担的业务越来越多，各种依赖的引入，系统启动一次需要15分钟。随着创新场景增多，事情会变得更加糟糕。

4）运行时不隔离：目前我们没有对不同的业务区分不同的机房，业务吃大锅饭，难以做到按产品的资源和稳定性保障。

6.1轻应用架构的选型

解决复杂问题，一般是分治的思路，但是按照什么维度来分治？不仅是业务架构，还关乎到应用架构的设计，如果极粗暴地按照场景、团队来划分微服务，显然随着未来场景的爆炸，运维成本、基础能力建设成本仍然会是一个不小的开销，创新试错还是快不起来。在做创新架构顶层设计之初，我们就希望通过一种技术，”让业务更加聚焦于创新逻辑的研发，而尽可能小地关注到基础设施的运维“。这里基础设施，不仅仅是传统的基础设施和运维（比如监控、升级、扩容等等），还包含了基础服务能力（通用业务服务、研发框架等等）。而创新逻辑的灵活开发，是指场景模型快速开发、能力编排，以及场景之间的相互隔离的要求。这其实是Serverless的初级形态，具体来说，我们想把场景的粒度从”微服务“（完整的应用）降低到更小的”模块“级别，然后动态部署到一个大的创新基座应用上。模块的特点可能是：可以独立研发、独立热发布、独立逻辑运行。但是模块之间的调用，最好可以是进程间、进程内，甚至是无需走hessian等较重的序列化模式。CY21年，蚂蚁内部有sofa-ark这样的模块化框架，提供同jvm内多个模块分离研发、部署的研发框架。同时针对这套框架的配套运维系统、产品系统也开始初见雏形，我们经过POC技术验证和架构决策后，非常笃定这个架构演进方向，决定作为种子用户加入初创团队，作为样板间业务孵化SOFAServerless。

6.2如何做隔离和复用

在SOFA Serverless的体系中，我们把各个创新业务作为独立业务模块，业务模块可以独立对外发服务。同时也可以把前面提到的通用生产力工具，全部下沉到创新基座中，业务快速研发工具和框架、业务模版脚手架模版、业务模块研发规约等。在演进过程中，当业务模块发现有一些可复用的业务能力需要沉淀时，我们也引入了公共模块（后来演进为公共场景）的划分，可以允许业务模块间互相调用，且不丧失性能。SOFA Serverless代表的不仅仅是部署运维领域的先进性，更代表的是业务架构设计领域的先进性。通过这个新的架构体系，给我们的创新提效公式有了完全落地的可能性。

7.架构设计方法

7.1 架构的宏观设计方法

架构的目的，是不断降低系统的复杂度，并且通过提前设计，来满足业务未来的适应性。解决复杂性问题是有一般性原则的（俗称套路），在软件开发领域，也沉淀了较为丰富的设计原则和设计模式，是指导我们设计出优秀架构的基础理念。

7.2架构是利弊之间的取舍

架构设计是在满足客观约束条件下的权衡和取舍，比如资源的约束、团队的技术水平、业务不同阶段对效率的要求等等。我们知道，平台化能够提高能力复用度，但是对创新的灵活性是有制约的。 比如在资金创新平台设计的过程中，我们也充分考虑了抽象粒度、分治方面的取舍：通过资金平台“大粒度”的抽象，解决了各种交易模式的复杂度、资金安全的问题。而在偏创新的轻应用部分，我们采取了“粒度更小”的工具维度的抽象，尽量减少场景对通用能力的侵入，让业务创新更加自主和灵活。而在分治层面，我们设计的serverless模块化架构，其实也是在单应用、和微服务之间取的一种平衡，兼顾了基座的复用度，和模块的灵活性。当然做取舍的前提，首先是要对于架构设计方法有充分的利弊认知，才能在客观约束下有更好的取舍，如下图所示。

总之，架构设计没有一劳永逸的银弹，在一般性方法的指导之下，抓住当下最核心的矛盾，在设计中演进、在演进中再设计。