随着全球化业务的发展，如何将国内成熟的电商能力出海，并满足海外多个市场的差异化诉求，成为了电商平台寻求业务增量的长期目标。随着覆盖市场的增多，作为基础的交易链路，在出海过程中面临着跟国内天差地别的核心挑战，如何应对这些全新的挑战并设计满足全球化特性的交易链路架构成为了我们的主要命题。

整个演讲会从 Voyager 进行首次电商能力出海为起点，介绍当需要在海外从 0 到 1 搭建一整套交易链路时，我们是如何进行技术方案和技术架构设计的。之后随着海外业务的不断发展，在面临来自全球多中心、多竞对激烈竞争、新市场扩张等挑战时，我们是如何通过去中心化能力交付架构升级以满足全球多中心独立发展诉求、如何通过交易链路最小集来满足海外新市场低成本快速扩展和合规拆分，以及如何通过允许平台多基线的开放研发体系，支持海外多区域、多时区研发自闭环快速迭代。

本次分享主要涉及阿里巴巴海外业务板块，分享从国内到国际、整条基础交易链路的架构演进，聚焦在整个全球化板块。在面临全球多组织、多区域，多时区，以及全球各种合规挑战时，阿里巴巴海外业务架构如何一步步演进，以适应整个的海外市场。

交易链路的业务特点和架构演进出发点

我们先分析交易链路的特点，这里分为国内和国际两个视角。其实里面细节很多，这里只抓几个关键点来说。

首先是国内视角下整个交易链路的特点。从 2012 年到 2017 年、再到 2020 年左右，国内采取的策略都是“手淘超级大航母”的策略。这种策略下的交易链路需要为手淘这个中心化的流量场提供统一的购物车、统一的下单，以完成所有商品的购买。同时随着市场和业务的发展，整个淘宝的商品种类也变得越来越多，而不同的商品种类对于交易链路的个性化定制诉求也非常强烈。在这个阶段，整个架构的策略用一句话总结就是，解决手淘单中心流量场下的国内单市场多行业隔离的问题。

讲完了国内，让我们转到国际视角。国际的整个演进阶段跟国内相比不太一样。我们大概划分成了四个阶段，从 Voyager 到 Yatra 到 Sirius 再到 Polaris，它们分别代表了每个阶段交易链路的特性。我们整个的架构也是基于这四个阶段不断演进。在阿里内部每次起动公司级的大型战役时，我们都会起一个对应的代号，这些名字就是战役的代号。

在 Voyager 阶段，阿里巴巴在 2017 年完成了 Lazada 电商平台的收购，收购了这个电商平台后，集团要求我们完成阿里整个技术栈的出海。Lazada 是一家服务于东南亚市场的本对本电商平台，它的核心是用一个电商品牌支持东南亚、新加坡、马来西亚、印度尼西亚 6 个国家的市场，在 6 个国家的市场间还要支持国家特性隔离，包含币种、时区、语言等对应的国家逻辑。在这个阶段，核心的架构策略就是解决 Lazada 这个单一站点下的多个不同国家之间的市场隔离问题。

下一个阶段是 Yatra 阶段，这个阶段我们又收购了一家电商 Daraz。Daraz 是一家服务于南亚的电商平台，包括巴基斯坦，缅甸，尼泊尔等 5 个国家。但是 Daraz 和 Lazada 毕竟是两个单独的公司主体，他们在运营策略、大促策略上面是完全不一样的。在这个阶段，我们整个的架构策略是要解决多站点互相隔离的问题。

接下来是 Sirius 阶段。到了这个阶段，我们整个业务策略跟过去的两个阶段比有个本质的区别：不再局限于本对本的单一模式进行发力，而是在新的跨境模式下持续发力并投入更多的资源。比如，我们投了非常多的资源进行 AliExpress（速卖通）跨境能力的建设。除了加大在速卖通这种老牌跨境站点的投入外，我们也在建设 F1 站点，对标 SHEIN 做快时尚。我们不仅聚焦内部的 AE 全品类跨境平台，也对精细化的跨境品类进行发力。这个阶段对整个交易链路的要求是，不仅要具备本对本的能力，同时也要具备跨境的能力。而在具备这种多模式的能力要求下，我们也看到不同的站点所需要的模式是不一样的，所以在这个阶段，我们整个架构演进的策略是解决多模式灵活扩张的问题。

最后到了 Polaris 阶段。在经过前三个阶段后，我们不管是收购也好，自己内部新建品牌也好，还是通过建立二方合资公司也好，都使我们的电商占比非常高，覆盖了全球的各个区域。但覆盖的每一个区域、每一个电商品牌背后都是由独立的业务运作组织，这必然面临更多的市场竟对。在这个阶段，对于整个交易链路的架构要求是为每个独立的业务运作组织匹配研发节奏，即无论 Lazada、AE 还是 Daraz，保障各组织之间互相的研发节奏相互并行，并能根据不同的站点业务策略做快速的响应。这个阶段要解决的核心问题是多站点自主闭环，让整个研发结构解耦。

架构演进主线

单市场交易链路典型架构实现

这里先分享一些国内市场的架构实现。我们内部有很多框架实现细节，这里就不展开了。我想给大家介绍的一点是，到现在为止，我们国内每年支持双十一整体大流量的国内交易平台的挑战。在这个阶段要解决的核心问题是，国内单市场下的多行业隔离。

我们面临两个挑战。第一个是要为手淘中心化的流量入口提供统一的购物车和统一的下单，并且要保证这个中心化流量入口的全局稳定性。第二个挑战是支持行业的差异，因为话费充值、游戏充值、生鲜业务下单以及购物车是不一样的。

面对上述两个挑战，我们面临的是要在全局稳定性和可扩展性之间做取舍。所谓“没有完美的架构，只有适合的架构”，我们需要尽量控制逻辑改动，以保证手淘这个超级 App 的基础链路的下单稳定性，从而做到手淘整条链路的高可用。在这个背景下，整套架构采取的策略是稳定为主、扩展为辅。我们将整个架构实现分为了业务层、应用层和平台层三层。

从下往上讲，首先在平台层，为了保障稳定性，我们把核心流程、核心逻辑进行了收敛。在平台层的核心逻辑之上，提供一些局部的、面向行业维度的扩展点，允许行业自行定制。在最上面的业务层，我们为不同的行业分配不同的行业插件。这个行业插件主要有两部分组成：第一部分是业务身份，就是每个行业配一个全局独立的 Stream 字符串标识的业务身份；第二部分是把行业特殊的定制逻辑放到对应的行业插件内。

完成了平台跟业务分层之后，在应用层我们采取的方案是中心化应用方案。在中心化应用方案发布过程中，我们采用平台集成业务的方式，提供统一的发布通道，在这个过程中加载业务层的各种平台插件，统一形成一个平台中心化应用。当真正的用户请求到来的时候，通过应用层的一套统一调度框架完成调度。

请求调度框架的细节相对比较复杂，我从模块的角度讲讲它做的几件事情。第一件事情是身份识别，当请求到来之后，需要通过请求识别对应的业务身份是什么，这是第一步必须要做的事情。完成了业务身份识别之后，第二步要通过这个业务身份找到对应的平台流程，之后才能进入整个平台的逻辑处理过程。在平台逻辑的处理过程中，会找到对应的域服务，每个域服务会提供对应的 Ext 扩展点。第一步身份识别产生的业务身份走到扩展点后，通过回调定制找到那个行业对应的定制逻辑。我们把这套架构叫做中心化平台集成业务的架构。这套架构很好地保障了整个交易链路稳定性的同时，还提供了局部扩展的能力。

海外 V1.0：多市场交易链路多租户架构实现

海外 V1.0 的架构策略是解决单站点的多市场隔离问题。我们面临两个挑战。第一个挑战是要设计一套架构，满足 Lazada 一个站点支持 6 个国家的特性。第二个挑战是，因为 Lazada 是收购的来，我们需要在最短时间内用最低成本完成它的遗留系统的逻辑切换。Lazada 有 6 个国家，我们源于这套遗留系统为每个国家搭建了一套独立的系统。

为了应对上述两个挑战，在做整个架构决策的时候，我们面临的是在维护成本和隔离性之间的取舍问题。如果要隔离性最高，那就跟过去的架构一样，每个国家一套下单、一套购物车，这个隔离性是最强的，但这套架构方案带来的问题就是任意改动都需要改 6 次、发 6 次，维护成本非常高。我们最终目的是让 Lazada 未来的迭代效率更高、降低它的维护成本，以应对东南亚日益激烈的竞争。此时整个的架构策略是强维护、弱隔离，追求更低的维护成本。低维护成本意味着要牺牲一些隔离性。如图下侧所示，我们没有再去采用每个国家一套系统的物理隔离方案，而是为每个国家单独搭建一个租户插件，通过这个插件实现内部逻辑隔离的架构。

这里我详细展开一下。首先在平台层，我们这里叫做 V1.0 阶段。在平台层需要做的工作是把国内的交易链路能力搬到海外。为了减少维护成本，我们做了些减法。我们并没有把国内成本、预售的多阶段交易等复杂功能都搬到海外，而是只选取了最基础的担保交易能力，把它从国内的能力里面抽取出来，将它作为基础搭建了一整套海外的交易平台。

我们在应用层的部署方式上也做了一个反潮流的架构。国内整条基础交易链路涉及应用大概有两千多个，为了维护成本更低，我们不可能把这两千个应用都输出到海外。举个例子，大概有 200 人承担这个项目，如果两千个应用出海，意味着每个人平均维护 10 个应用，未来改动成本、维护成本是非常高的。我们在这里做了合并部署，把原来两千多个应用通过合并部署的方式控制在了 15 个以内。这意味着，整个电商站点基础交易链路用 15 个应用完成从 0 到 1 的搭建，这是为了降低整个维护成本而做的取舍架构设计。在隔离性上，我们在业务层为不同国家分配了对应的租户身份，租户身份背后是单独的租户插件，不同国家可以使用租户插件定制语言、币种、时区等与国家相关的信息。

在业务层完成了整个租户逻辑隔离之后，数据层上我们并没有采取这个逻辑隔离的方案。因为未来数据合规会越来越严，所以我们为每个国家单独分配了数据库。这样，如果未来某个国家面临合规诉求或者合规挑战的时候，不会影响 Lazada 整个电商站点。当请求来了之后，会识别用户的请求底是哪个租户，根据租户路由到对应的租户插件做逻辑处理，再路由到对应的数据层的数据库，进行对应的数据写入。以上的这整套架构是在 1.0 阶段完成 Lazada 电商站点搭建过程我们所做的事情，即单站点多市场隔离。

海外 V2.0：交易链路从平台中心化到去中心化

我们接下来进入到海外的 V2.0 阶段。在这个阶段，我们工作的核心是把交易链路架构从平台中心化进行去中心化的转变。

接下来详细为什么要做去中心化。在这个阶段，我们不再只是服务 Lazada 这一家电商站点，我们又收购了 Daraz，同时我们也知道未来要服务的站点会变得越来越多，所以我们需要解决多站点互相隔离问题，需要找到满足海外强隔离诉求的整套架构。为了设计这套架构，我觉得还是需要回到业务特性来分析。在这个阶段，业务坐标系跟国内相比已经发生了非常大的转变。我们不再是国内单市场、多行业组成的二维坐标系，而是已经演进到由多市场、多行业、多站点组成的三维坐标系。这个三维坐标系的每一个平面代表需要支持的一个单独站点，背后是一个单独的电商品牌、单独的业务组织，还有更关键一点：单独的流量，这是业务上的差异。

这个阶段在系统架构上的差异是，这里不再是像国内一样一个手淘超级方案共享中心化流量的方式，而是变成了每个单独的站点都有其独特的流量中心。如果仍然采用平台中心化的方式就意味着，在面临全球多站点、多时区的时候，我们每天都需要安排很多同学值班，去帮助每个站点完成对应站点的发布。我们知道电商每年最烦人的、流量最大就是大促。随着站点、时区增多，这个中心化的方式就会导致 4 个站点一年有 4 个月左右的时间都要封网。所谓封网就是，这个时候不能修改代码，不能发布。如果站点多到 8 个，那一年 12 个月都要封网，陷入无休止的互相排队。同时背后还有一个问题就是，如果仍然采用国内这种中心化应用的架构方案，如果 Lazada 站点出了重大故障，一定会影响 Daraz 其他所有的站点，所以我们必须去做平台去中心化的架构升级。这里的核心目标是要完成从平台集成业务到业务集成平台的一个转变。我们要从过去单中心、单通道串行交付的方式，变成业务集成平台、多应用并行迭代的方式。要完成这个核心目标，关键的手段是为不同站点分配独特的全局唯一站点身份，然后再通过这个站点身份完成研发态、编译态、运行态、请求态这四态的去中心化改造，从而实现整条链路的去中心化。

如上图右侧的架构设计图所示。在研发态，我们为每一个三维坐标系的平面分配了独立的研发空间，我们把它叫做站点包。在编译态，由于在研发态已经有独立的站点包了，那我们就能在编译态为每个独立站点包分配独立的交付通道。通过这个独立的交付通道，我们可以根据站点身份动态匹配，站点身份决定对应的交付通道应该去拉取哪个站点包、平台，然后拉取整个站点包的逻辑和平台逻辑，组装成每个站点都不同的站点镜像。这里整体的实现是基于云原生的技术，利用 Kubernetes 相关编排能力去做的。当站点镜像生成之后，我们会把它放到独立的站点应用，这个独立站点应用的实现基于自身的产品化能力。我们会对研发态生成的每个不同站点包自动构建出站点应用、做了一些产品化升级，我们把多租户逻辑隔离的能力、基础运维监控相关的能力都内置在了这个站点应用中。在请求态，我们在统一接入层也做了一轮大升级。我们会根据请求识别关联站点的身份是什么。在统一接入层，通过识别站点身份完成一次请求的路由，最终通过站点身份再找到对应的站点应用。综上所述，我们完成了整个架构的去中心化升级，也做到了不同站点有各自独立的研发空间、独立的交付通道和独立的运行容器。

海外 V3.0：交易链路从能力最大集到最小集

在海外 V2.0 阶段，我们完成了去中心化，接下来给大家介绍一下海外 V3.0。3.0 阶段的核心是从一个平台的最大集到最小集的转变。在这个阶段，我们要解决的是多模式灵活扩张的问题。站点越来越多，但每个站点背后的模式都不一样。站点越多，模式差异越大，我们需要找到一套满足海外低成本扩张的架构。

上图用了一套坐标系表示海外数字商业板块的业务迭代的策略，即一套纵横迭代的策略。在纵轴上，我们既需要支持 Lazada 代表的本对本电商相关存量站点的能力迭代，也需要支持 AliExpress 代表的跨境电商站点对应的能力迭代。在横轴，我们要去开更多的站点、用不同的模式覆盖不同的站点。在这个纵横迭代的策略下，如果还是采用平台最大集的架构方式就会面临以下问题。

第一个问题在纵轴上，即本对本和跨境能力互相干扰。举个实际例子，Lazada 是做本地化电商的，做本地化电商有一些特殊类目。比如在 Lazada 我们有一个比较有名的生鲜电商 Red Mart，类似于国内的天猫超市，需要进场电商相关能力。但问题是，跨境是不能做生鲜的，因为冷链、供应链等都不能保证时效。我们通过业务调研发现，跨境平台的消费者对生鲜没有一点兴趣，而跨境交易链路的特点是需要非常复杂的多币种处理能力。这个币种不是传统意义上的从 A 到 B 汇率转换。多币种是一个卖家可以在 AliExpress 上把商品卖给全球消费者。比如，卖家发布了一个 10 美元的商品，无论全球哪个地区的消费者购买后，我们都要保证，卖的是 10 美元，结算的也是 10 美元。如果消费者是俄罗斯用户，用卢布购买，通过实时汇率结算无法保障卖家收到 10 美元。为了达到这个目的，我们和巴克莱银行签订一些保护协议。

在本对本方面，我们显然不需要上述相关能力，因为买家和卖家都是用本币进行支付和结算的。如果把多币种能力也集成到这个平台就会出大问题，因为多币种肯定有一些汇率保价相关的逻辑，稍有不慎把汇率改错了，比如改成 0.1，那本对本错误的依赖了这段逻辑之后，就意味着会有大量的平台亏损。所以说在纵向迭代上，不同能力的互相干扰已经严重阻碍了存量站点的发展了。

第二个问题在横向扩张上，如果用平台最大集这种方式也会有很多问题。首先随着能力越来越多、系统越来越复杂，如果用它直接覆盖新的市场，那么人事成本和资源成本非常大。我们当时评估，人事成本接近上万、资源成本上亿。一个新的电商品牌可能一年都达不到一亿的规模，如果光做建站就花一亿，那肯定是不能接受的。其次，我们在做全球多站点部署时，遇到越来越多的合规和当地市场的不确定性。举个例子，我们在做俄罗斯市场时，俄罗斯市场要求必须本地公司提供支付服务，那就意味着交易链路需要具备局部可被替换能力。再比如，在做海外扩张的过程中，我们会通过合资手段生成很多 GV 公司，在签定协议的过程中，他会要求物流由他们这边公司统一提供，这个时候交易链路的物流或者履约相关的能力必须要具备局部替换的能力。如果我们用最大集去做横向扩张就无法做到灵活可被替换。

综上所述，纵横策略交易链路的架构演进要求降低扩张的整体成本，我们需要设计一个“最小集架构”，核心目标是希望能完成整个架构从最大集能力必选到最小集能力可选的转变。本地也好，跨境也好，不是一个拆不开的、紧密耦合的架构，而是把本地和跨境相关能力做更好的分类，该给本地的给本地、该给跨境的给跨境，通过这种方式来降低整个系统复杂度，降低迭代、扩张成本。

要达到这个目标，核心手段是之一需要做到领域可选。在横向扩张过程中，交易链路的领域可以被当地公司或者当地的一些技术栈替换。第二个手段是能力可选。我们把电商按照 0 到 1、1 到 N 的生命周期进行了划分，把本地和跨境都需要的基础能力放到 0 到 1 的电商生命周期阶段，我们会单独搭建一个空间，而将本地和跨境的那些特有能力放到电商 1 到 N 空间，为 1 到 N 的空间构建单独的研发空间。通过 0 到的 1 空间和 1 到 N 到空间的组合，实现本地只关注本地的能力、跨境只关注跨境的能力。

如上图右侧所示，在领域协议层，我们需要做到领域可选。这里的核心做法非常简单，我们把 0 到 1 阶段所必要的 API 梳理出来，把定义和实现分离，把单独的定义抽取出来，封闭成一份完整的领域协议，通过这种方式，在支付、履约、营销等被其他技术站点替换之后，确保整个交易链路的信息流互通互联的稳定性不受影响。

在领域层，我们核心工作是“瘦身”。平台层只保留了 0 到 1 所必须的业务模式的实现，以及业务模式实现背后所需要的领域能力，也就是领域的最小集。为了保证领域最小集不会随着时间而逐渐腐化，我们建立了一套保鲜机制，采用了自动化流量回归的方式。我们会去所有的站点采集消费者消费的流量，采集完成之后会生成流量库，在流量库的中完成一轮清洗之后，形成 0 到 1 所必须的用户消费者的请求流量，再把这个请求流量通过自动化回放的方式，回放到领域最小集。用通过率和行业覆盖率来保证最小集的整个能力保鲜。

在 1 到 N 的衍生级，我们把本对本和跨境这两大能力进行了分类。举个例子，我们把生鲜预约购相关的能力划分到了本对本、把多币种保价能力划分到了跨境，从而做到本对本和跨境之间的相互隔离，以及本对本和跨境的模块化交付。通过 0 到 1 的最小集加 1 到 N 的衍生级的模块化交付，和在中间提供的的框架嫁接，最终实现了最小集可以和衍生级的按需集成、按需输出，也就是说本对本站点只需输出本对本相关的能力、跨境站点只需输出跨境相关的能力，从而把成本降到最低。

海外 V4.0：交易链路从平台单基线到多基线

最后是海外 V4.0 阶段的介绍。这个阶段要解决的核心问题是解决多站点自主闭环。随着站点变得越来越多，海外市场的竞争越来越激烈，我们的架构需要满足整个海外高效率迭代。任何架构设计都离不开对应的业务设计。对比海外，国内的业务运作机制是采取行业小分队的运作模式。因为国内经过这么多年发展之后，电商平台已经相对比较成熟，已经适应了整个国内市场，所以规则相对比较稳定。国内要的是基于成熟电商平台下的行业局部调整，所以需要有垂直维度的行业小分队。比如现在大淘系的业务运作机制，是由各种行业组织来运作。通过这种垂直行业小分队的方式，采用集中的拓展能力为每个不同的行业提供行业纬度的定制能力，以支持行业调整。

接下来转向海外，经过这几年迭代后我们发现，不能拿着成熟的运作机制出海，原因是跟国内相比，海外还处在相对比较初始阶段。我们服务的国家很多，背后的服务市场也很多，需要通过调整平台规则去适应。海外市场整个电商平台相对不成熟，需要采用集团军运作机制。它不再是垂直维度的行业运作，而是一个个站点水平维度的。Lazada 有个 Regional 系统（Regional 组织），需要调整平台规则以适应东南亚市场。Daraz 也有对应的 Regional 组织要做规则调整以适应南亚市场。在站点集团军运作的方式下，如果我们仍然采用过去行业小分队运作的行业扩展点方式，一定会遇到跑不快的问题，会有大量的平台规则调整带来的平台中心化排期问题。平台排期巨大的协同成本一定会影响业务发展。

为了解决上述问题，也为了跟海外业务运作机制相匹配，我们设计了一套多基线的架构设施，核心目标是完成从垂直维度的单一扩展方式到既支持垂直维度的单一行业扩展，也支持水平站点维度的分层扩展方式。为了达到这个目标，我们的核心手段就是开源。开源允许我们通过一个主站，拉对应分支。但跟传统的开源不同，我们开源的是一个基础链路或者偏商业基础链路的软件，这个软件需要提供完善的开闭准则，保证平台不会因为不同站点的业务分支影响整个平台的互通互联，以及频繁出现重大故障。

这套架构设计把平台分成了“教堂 + 集市”两层。教堂就是主干，我们把 V3.0 阶段的最小阶段能力放到教堂内部，把它当做可被拉取分支的主干，让教堂的迭代成本和复杂度最低。同时我们制定了一份 ClosedTemplate 的黑名单，把影响互通互联的跨域通信的资源库、领域模型、数据模型，以及影响可用性、止损能力和逻辑进行封闭，放到这个黑名单内。在教堂之上是整个开放框架。这个开放框架核心作用有两点，第一是通过 License 的授权保证集市层不会泛滥，第二是提供一个能力替换引擎。能力替换引擎可以根据教堂的黑名单在运行过程中识别出哪些是不可变部分、哪些是可变部分，如果发现集市层将不可变部分进行了修改就会启动拦截，如果发现集市层将可变部分进行了修改就会做优先级替换。

在集市层，我们提供了一个集市样板工程，允许不同的站点基于这个样板工程拉取对应的平台分支。在这个平台分支内基于黑名单形成一份开放协议，完成站点级别的定制。举个例子，Lazada 电商平台有自己的包裹分组，因为 Lazada 本身是本对本物流电商平台，它是按包裹维度进行购物车和下单分组。Lazada 也偏自营，需要整个平台在指定单的维度按照件数进行拆单，Lazada 整个平台所有行业都应该适配这套规则。同时 AE 也实现了按照不同商家报价币种进行购物车分组和价格美化的能力。通过这种方式在逻辑上实现了每个站点可以有自己的平台分支。最后在物理态，每个集市分支会基于 V2.0 阶段提供的去中心化交付机制，完成每个站点的集市分支和每个站点身份绑定，从而实现 Lazada 的集市分支可以单独交付其站点应用。

得失总结 & 未来思考

最后做一个完整的得失总结。通过几次系统演进，我们现在整个架构基本分成了三层：第一层是达成强隔离诉求的站点应用层，第二层是达到高效率诉求的开放生态层，第三层是达到低成本目标的基础能力层。这三层架构让我们得到的收获有如下三点：

通过站点应用层完成了“平台集成业务”到“业务集成平台”的转变，让多站点 100% 全并行，24 小时想发就发；

通过开放生态层完成了从单一扩展能力到分层扩展能力的转变，让研发时长缩短了 50%，自助率做到了 90%；

通过基础能力层完成了平台最大集能力必选到最小集能力可选的转变，让平台简化了 60%，让建站成本降低 95%，且具备局部灵活替换能力。

有得必有失，这套架构的问题有如下两点：

线性增加的维护成本：拥有了更大自由度的同时，也要求业务维护平台分支，多站点的维护成本会线性增加。

业务难以一体化合力：整套架构侧重在保障各站点之间互相独立发展，在业务互通上的思考和建设不够，业务站点之间难以形成合力与竞对竞争。

回到业务战略，拆解到整个交易链路的技术战略，我把它总结为两点。第一，为了实现业务战略，我们需要做到闭环更轻量，让这些不同站点的维护成本越来越低，不要再呈线性增长趋势。存量维护成本降低之后，我们就有更多的资源能释放出来，去服务更多的增量市场。第二，让业务合力更简单，让业务之间顺畅流通，让存量市场的各种资源更好整合，最终用一体化合力的方式输出到新的市场。

围绕这两个技术战略，我们将规划分为两点。第一个是希望通过标准化方式让闭环更轻量。在这里我们更多面向架构治理相关的集市这一层，我们希望不同的站点不再需要去维护一个完整的集市分支，只需要去关注局部需求。要达成这个效果，就需要把集市这层做更强的标准化治理，使其具备更细力度的模块交付能力，让业务开发不再面向完整集市在大平台上做研发，而是面向局部的场景做研发。同时也不需要每次改动都把整个站点应用全量交付，而是基于标准场景做模块交付。我们希望降低门槛、让迭代效率更高，从而达到闭环更轻量。

第二个是通过数据基础建设让合力更简单。我们希望建立整条交易链路的一个“统一”的数据中心，通过这个数据中心让不同站点之间信息流通。针对交易链路，主要是定单、履约单对帐、单据信息，避免流通的一致性、跨站点之间信息流通的零合规风险。接下来我们会尝试通过这个统一的中心化数据建设，让整个全球化板块之间的不同站点、不同商品、以及背后订单等的信息流更加顺畅。