从DDD到PaaS化再到一站式部署——通天塔后端通用版发展之路

通用版的背景和目标

通天塔是一个面向京东运营和商家的活动搭建平台，提供了丰富和强大的模板，平台用户可基于模板自由搭建活动页面。通天塔支持无线和PC页面的搭建，提供的3种搭建方式：模块搭建、自定义开发（H5）、RN开发，站内活动支持原生，搭建一次可以同步到各端（app、pc、一 店、WQ、小程序等）。除了搭建页面，通天塔还支持以下功能：看数据、分享、首焦 名、复制、转移、AB测试等。

随着京东和通天塔业务的发展，我们需要支持的站点越来越多，包括主站、国际站（泰国站、印尼站）、商业化站点（商羚、北汽、数智农批、宜宾站）等等，

面临的挑战也越来越多：

• 通天塔需要支持的每个站点相互独立，意味着每个站点都有一套对应的代码和中间件资源等，硬件成本高，维护成本高。主站和其他站点代码不能复用，部分业务功能迁移困难

• 每个站点都有其个性化需求，对开发资源的要求越来越高，复杂度随站点数量增加呈线性增长

• 由于初期代码架构设计不合理，导致系统功能大而全，加入新功能所引入的复杂性不断提升

• 站点扩展性差，每次新增站点都要从头开始开发，上线时间较长

通天塔后端团队经过数年的逐步探索，摸索出了一条可扩展、高可用、可维护、部署灵活、多租户支持的通用版架构之路。

通用版改造历程

01

DDD（领域驱动设计）

首先，我们尝试解决代码架构设计不合理，代码复用、迁移困难的问题。矛盾的根源在于通天塔后端一直采用传统的SOA架构，它存在这些问题：

• 臃肿的service层

• 分层后文件的随意组装方式

• 技术导向分层，导致业务分离，不能快速定位。

分布式微服务的出现有利于解决这一难题，但微服务也不是适合所有的系统，而且也会有许多问题：微服务的粒度应该多大呀务到底应该如何拆分和设计呢务的边界应该在哪里p>

很久以来都没有一套系统的理论和方法可以指导微服务的拆分。综合来看，微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。

而DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

领域驱动设计是一种以业务为导向的软件设计方法和思路。我们在开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，而领域驱动设计的核心就在于建立正确的领域驱动模型。从过程上来说，我们从以前的业务模型和技术模型分开的设计流程转变为统一的领域模型设计流程，这就是业务研发模式的转变。

以babel-extension为例：DDD的实现过程如下

第一步，定义业务边界。基于对通天塔业务的理解，我们将原先较混乱的业务子域划分模型转换为基于DDD的限界上下文划分模型。

第二步，选定系统架构。这里我们选择菱形对称架构。

菱形对称架构（Diamond Symmetry Architecture）模式脱胎于六边形架构与分层架构，它以领域为核心对限界上下文的关注点进行划分，建立了由内部领域模型与外部 关组成的内外分层架构，以菱形的对称结构清晰展现了限界上下文的内部结构，指导着限界上下文的协作关系。

引入菱形对称架构有助于促进团队对限界上下文与上下文映射的一致理解，并促成团队形成统一的代码模型。

第三步，基于菱形对称架构建模落地。以下是代码结构展示

优势：

1、结构更清晰

代码结构清晰，能分别体现来自不同方向的请求。形成的对称结构更加清晰地体现了业务逻辑、技术功能与外部环境之间的边界。

2、能更好地响应变化

更加清晰地展现上下文映射模式之间的差异，凸显了防腐层与开放主机服务的重要性，能更好地响应限界上下文协作关系的变化。

02

PaaS化改造

接下来，我们需要解决站点个性化需求多，扩展性差的问题。对于某些各站点有差异，变动频繁但本身逻辑不复杂的功能，按以往的方式我们需要：

• 新增站点时需要在代码中加入站点判断和新逻辑，导致代码臃肿

• 修改某个站点的功能时需要修改代码重新部署发布，效率低下

• 所有第三方需求最终都由通天塔团队进行开发，工作量巨大

Paas化改造能很好地帮助我们应对这一场景。京东中台使用平台化的技术思维和技术手段梳理，识别，沉淀，复用企业的业务核心能力。中台搭建清晰易懂的业务领域服务模型，前台可高效率集成这些模型来满足业务场景，同时通过中台提供的扩展点进行个性化的能力扩展，灵活定制业务。

第一步，明确业务身份。

业务分为水平业务与垂直业务。

同时，通过业务身份矩阵可以明确自己的业务身份。我们的业务身份是营销域/通提投/通天塔。

第二步，需求结构化，扩展点展现与需求绑定。

第三步，扩展点的开发与上线。

提交需求（价值预估）——排期开发（价值PK）——上线运营（价值验证）——需求调整（价值调整）。

由于各站点的定制化需求较多，而Paas支持由通天塔定义扩展点，第三方实现，因此可以解放我们的研发能力，邀请第三方完善扩展点，共建领域能力。

03

通用版本建设

为了解决通天塔多站点存在差异、每个站点都需要维护一套对应的代码的问题，我们建设了通用版本的代码，将核心且共有的功能抽取出来，再将每个站点独有的功能分成子包，按需引用，通过maven来治理。同时，利用SPI+配置文件相结合的方案，抽离了中间件与代码的耦合，保证了通用版本不依赖某一特定中间件即可运行，提高了系统的可移植性。

针对一些特定的业务场景，通天塔后端选择了最优的架构来进一步提升效率、节约资源。比如在商羚、数智农批两个商业化项目的设计上，由于不像国际站一样有天然的环境隔离，也不像北汽站一样必须独立部署，通用版在设计上选择了“上游独立部署、通投同时支持”的策略，用一套通天塔应用在不独立部署的情况下，同时支持多个业务。

对于不同的站点，通用版采用逻辑上的隔离（账 租户、项目租户隔离）而非物理上的隔离（重新申请资源部署），灵活应对了新业务，避免了资源浪费，大大提升了上线速度。

04

iPaaS和开放共建能力

最后，为了彻底解决独立新站点构建完整运营体系效率低、交付慢的问题，我们对通提投的技术和业务能力进行全面地抽象、提炼和标准化，推出了一套可极速构建完整运营体系的一站式解决方案——iPaaS（京东零售前台研发标准）。

iPaaS基于前台研发构建完整营销运营体系为视角抽象和设计出整个iPaaS体系，包含5大能力：

1，设计前端协同：通过整合和拉通从夸克、Relay设计平台到大前端平台，建立高效的设计前端一体化协作流程和机制

2，大前端标准化：提供一站式的前端产品构建云平台，赋能前端开发者实现从设计、编码、调试、上线、升级和运营的全生命周期的产品支撑

3，模板共享体系：通过大前端技术开放体系赋能开发者和ISV，不断开发跨业务、跨App复用的模板和组件，并持续沉淀到模板共享体系，越来越多的优质模板赋予业务更强的运营能力，开发者的技术和成果实现最大化价值共享和变现，形成开发者不断被激励、模板越来越多、业务的运营能力越来越强的良性生态圈。

4，能力聚合服务体系：通过平台级的营销运营能力和标准化的中后台管理系统解决方案，帮助业务快速构建运营体系，结合Low Code技术开放体系（低代码能力接入和编排、FaaS能力加工、PaaS能力共建）赋能开发者快速满足业务的定制化场景和需求。

5， 立体智能质量体系：把立体智能质量监控能力植入到每一个iPaaS能力和环节中，形成iPaaS能力和监控高度融合的一体化体系，为iPaaS完整体系的高质量、稳定和安全运行保驾护航。

IPaaS体系接入通用版后，不仅可以帮助新站点极速构建完整营销运营体系，而且将极大帮助通天塔应对海量定制需求，这里通过几个例子说明。

例如，大前端共建平台，即ihub.jd.com，基于iPaaS标准建设，面向开发者提供包含h5、iOS、安卓等端的跨端楼层开发管理能力。即当系统现有模板无法满足诉求时，业务或开发者可通过ihub平台开发并管理代码楼层模板，开发出来的楼层可以被采销、运营、商家等使用。

例如，能力聚合服务体系通过lambda函数平台对能力进行扩展，承接上层无状态业务逻辑，比如入参封装、字段过滤、图片加工处理类需求，无需应用发布，加速并简化开发，实现需求快速交付。

05

中间件解耦

不过，即使有了以上条件，新站点还需要具备京东云技术基础设施，也就是京东IaaS和PaaS。未来，技术商业化将成为京东增长的新曲线，将会催生越来越多的商业化赛道和项目，通用版体系解耦京东TPaaS势在必行。所以未来通用版的方向是进行彻底的解耦JD TPaaS改造，通过标准技术API+技术适配层来隔离&适配底层技术。

为了满足以上需求，通用版使用SPI+配置文件相结合的方案，用SPI的特性实现灵活扩展，用读配置文件的方式实现灵活切换实现，同时具体落地方面主要为增加适配层以及额外的实现，对原有的实现逻辑改动相对较小，安全性较高。

基础设施适配主要改造位置和整体架构的关系：

SPI+配置实现基础设施解耦架构图：

06

项目部署一站式解决方案

以往每个新站点都需要一套对应的中间件资源和镜像版本，需要开发者手动去走流程申请，然后将资源地址（如redis url、mysql用户名、密码等）填充到代码的配置文件中，进行调试和修改。由于通用版应用数量较多、涉及的中间件数量也较多，这对开发者造成了一定的困扰，使得开发者要将很多精力投入到这种重复的工作中去，而且熟悉资源的申请、配置文件的修改调试也需要一定的上手成本。综上所述，一套项目部署一站式解决方案——京东零售云交付平台，应运而生。

部署流程：

发布方案：

通用版在接入京东零售云交付平台后，研发人员可以在线申请应用资源依赖，

维护不同客户的应用、镜像版本。每当需要扩展新站点的时候，只需选择对应新站点的环境即可发布。真正做到一次配置，处处部署。

最终的通用版部署流程：

07

成果

京东通提投团队经过对通用版的一系列探索、改造历程，目前已取得一定的成果，主要体现在已建立的独立站点上。从泰国站、印尼站开始，经历了产品规划、方案设计、中间件申请、代码编写、联调提测等等过程，新的独立站点上线时间达到4个月左右。随着我们逐步摸索通用版改造方案，到最新的数智农批站点，仅需1.5个月即可完成上线，累积速度提升达到了70%以上，这其中省掉了很多重复工作的时间，让开发人员将精力集中到了站点新业务逻辑上面。

未来的方向

云原生

系统有了通用版能力后，我们发现在响应新的站点和商业化项目过程中最大的工作量和难题是如何快速移植、部署整体平台体系到客户环境，可能是公有云、私有云，甚至混合云，这就需要我们依据云原生技术设计出一套可以快速部署完整通用版到不同客户云环境的能力，且体系可以做到稳定和一致性的方式运行。以下是我们初步设计的方案：

应用通过接入云原生服务可以天然获得可观测性、高可用、容错性、自愈等能力，从而构建韧性应用。同时云原生的架构原则也同样在我们开发者在开发和设计软件架构时起到非常好的指导作用，包括服务化、弹性、可观察性、韧性、自动化、零信任等原则，帮助我们更好的建设系统的高可用基础能力。

总结了很多有关于java面试的资料，希望能够帮助正在学习java的小伙伴。由于资料过多不便发表文章，创作不易，望小伙伴们能够给我一些动力继续创建更好的java类学习资料文章，
请多多支持和关注小作，别忘了点赞+评论+转发。右上角私信我回复【03】即可领取免费学习资料谢谢啦！

 

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8967 人正在系统学习中