简介：本文对过来十年 CBU 在研发形式和技术架构上的摸索做一个简要的回顾总结，以及对将来的瞻望。

作者：远岩，高级开发工程师。2019 年毕业退出阿里巴巴，次要负责 CBU APP 端前台场景工程体系及服务端 Serverless 化建设。

前言

CBU 作为团体内最早成立的几个 BU 之一，有着多年丰盛的业务积淀，而 CBU 的技术也随同着业务一起一直地演进和成长着。从 PC 时代的 WebX 到现在的 Serverless，CBU 的研发体系经验了屡次改革，在不同的阶段中有着不同的特点。笔者所在的团队近年来始终在负责前台场景研发体系降级相干的工作，在这期间也对过往模式的演变进行了大量的回顾和剖析，心愿可能通过本文对过来十年中 CBU 在研发形式和技术架构上的尝试和摸索做一个简要的回顾和总结，从新扫视咱们所走过的路，同时也对将来的方向做一些探讨和瞻望。

青铜时代（2010～2013）

10 年前的互联网，挪动终端还没有衰亡，绝大多数的产品都是为 PC 用户所服务的。在这种背景下，采纳 B / S 构造是一种毋庸置疑的抉择，因而当咱们回顾这个时代的技术时，最先能想到的天然是那些和 WEB、浏览器关系最亲密的关键词：比方 WebX、jQuery、Velocity 等等。

在这个阶段，业务流量并不微小，零碎的性能瓶颈根本集中在数据库的读写上，大部分的利用依然采纳单体式的架构，从前台页面到后盾逻辑都封装在同一个利用中，而在利用外部，往往是采纳 MVC 的分层思维对不同性能的模块进行划分。彼时 CBU 的前台利用架构也根本是这个思路，页面通过 Velocity 模板进行开发，后盾业务逻辑则封装成利用中单例的 Service 实现，两头通过一个相似 Controller 的粘合层进行连贯，将后端的数据字段转换成前端模版中所应用的变量：

这种模式的长处是，因为所有的模块都在同一个利用中，十分便于集中管理，当一个开发同学十分相熟整个利用构造时，他便能够十分疾速地实现一整个需要的开发。但毛病也同样显著：随着业务的倒退，前台逻辑变得越来越简单，需要必须要拆解成前后端拆散的形式，让专人做专事，而前台代码被耦合在利用中，使得前后端拆散开发变得异样艰难；除此之外，前台逻辑的变动往往是十分频繁的，如果每次批改一个页面元素都要公布整个利用，不仅研发效率会非常低下，还会影响线上业务的稳定性。

为了解决上述问题，过后 CBU 的同学们充分利用了 Java 的动静类加载机制以及 Groovy 脚本语言，以一种非凡的形式实现了前后端拆散开发和疾速迭代，这里咱们以商品详情场景为例解释一下其机制和原理。

首先，一张页面被拆分成若干个组件，每个组件都会对应一个 bundle，这个 bundle 中蕴含了前台的 vm 模板，js 代码，以及一个 Groovy 脚本。在理论研发时，须要先通过一个映射表达式申明该组件所须要生产的后盾模型或字段，而后通过 Groovy 脚本（相当于 Controller 层）将其转换为 vm 模板中的变量，接着便能够开发前台的 vm 模板和 js 逻辑。开发结束后，通过一个定制的公布零碎，便能够把对应的 bundle 公布到前台利用中，由利用外部的 JVM 动静加载 Groovy 脚本以及 vm 模板，实现需要性能的上线。下图便是一个应用这套研发体系开发需要的理论例子：

这套研发体系通过 JVM 动静加载的能力，将面向前台的 View 层和 Controller 层逻辑抽离进去，使其可能进行独立开发和动静公布，从而实现了前后台逻辑之间的解耦，晋升研发效率。只有后盾逻辑没有大的变更，很多需要都能够通过 bundle 疾速开发上线。不过在理论运行时，所有的逻辑依然是在同一个利用中执行的，这在肯定水平上会带来一些安全隐患。除此之外，这套研发体系也是十分定制化的，bundle 的公布零碎实现十分惨重，并且对应的前台利用有强绑定关系，这就意味着很难将它疾速地复制到另一个业务场景中复用（CBU 最终只有商品和店铺两个业务落地了相似的模式）。

只管存在着肯定的问题，但即使以当初的眼光来扫视，也不得不抵赖这套研发体系有着十分超前的设计思路。尤其是通过引入 bundle 这一概念，使业务迭代开发变得非常聚焦。在本文的后续章节中咱们会看到这一思路最终将随同着云原生技术反动，再一次回到咱们的视线当中。

蒸汽时代（2014～2018）

这一阶段，互联网行业的状态产生了十分微小的变动。随着智能手机的风行和遍及，挪动互联网迅速崛起，各种各样的业务都开始向挪动端发力。团体动员 ALL IN 无线的战斗，大量的业务和产品须要疾速向挪动端迁徙。同时，随着智能手机市场的一直下沉，加上其“随时随地”都能应用的个性，互联网业务此时所须要应答的流量挑战和 PC 时代将不再是同一个数量级。

在技术侧咱们也能看到与上述景象所匹配的改革。一方面，因为流量的激增和零碎复杂度的减少，传统的单体式利用无奈再撑持业务的倒退，随着 Docker 这一关键技术的呈现，服务端利用的分布式拆分和微服务化成为不可阻挡的趋势。另一方面，因为挪动端崛起，前台展现冲破了 PC 键鼠交互以及浏览器能力的限度，用户对于产品体验和交互的要求势必会变得更高，这促使研发人员进一步细分化为负责底层业务逻辑的服务端研发和负责前台展示交互的前端、客户端研发：React 的呈现敲响了传统 WEB 技术的丧钟，开发独立 APP 成为拓展业务的不二抉择，前端技术和客户端技术在这一阶段开始飞速发展。

这样的背景下，单体式利用和 MVC 架构逐步死去，前后端拆散的架构模式和 Restful API 登上历史舞台，每个细分畛域的技术栈都在飞速成长，大型软件的开发流程从此将会面对更加简单的合作和研发模式。

回到 CBU 自身，这一阶段技术上最重要的工作就是将本来 PC 上的业务疾速地迁徙到无线终端下来，因而成立了专门的无线团队，开始重点打造手机阿里 APP。整体思路十分简单明了，原有的业务体系和逻辑放弃不变，进行微服务化革新，以 RPC 模式对外提供外围业务能力；架构上增设无线服务层，面向 APP 进行业务逻辑的适配和封装，通过团体对立对外网关提供 Restful API 给客户端及前端开发人员应用。这样就能够在根本不影响已有业务体系的条件下，让 APP 上的业务疾速跑起来。无线服务端在这里所表演的角色十分相似 MVC 架构模式中的 Controller 层：通过 RPC 与底层根底业务交互，而后叠加面向无线侧的非凡业务逻辑，最终对数据结构进行肯定的解决和封装，通过团体对外的无线网关透出给前台客户端应用：

在此模式下，无线服务端和客户端研发人员扮演着非常重要的角色，他们的研发和合作模式将最终决定 APP 的迭代速度以及品质。接踵而至的新挑战督促着 CBU 的工程师们对已有的研发体系进行全面的降级，而最终他们给出了非常精彩的答案：轻服务和场景搭建两大技术应运而生，接下来咱们会看到，这两者联合所产生的微妙化学反应，将会给前台场景的研发模式带来一次重大的冲破。

轻服务平台

如上文所述，在 ALL IN 无线的时代，无线服务端的研发同学们须要在已有的根底业务接口上进行大量的革新和封装，为无线 APP 端提供服务接口。而在微服务架构下，服务端要对外透出接口，个别须要在利用内编写 RPC 服务，而后通过团体的无线网关将对应的 RPC 服务裸露成团体 APP 能够调用的 HTTP 接口：这种形式下一个服务从开发到上线往往须要数天工夫。而为了保障客户端性能的疾速迭代，防止业务受到发版节奏的影响，很多简略逻辑往往会被上行至服务端解决，这就对无线服务端的迭代速度和灵活性提出了一个十分高的要求。既有的技术生产力不能满足业务诉求，那就势必要进行翻新，于是便诞生了可能撑持疾速麻利开发的轻服务平台，代号为 MBOX。以明天的视角来看，这一平台践行的便是当下十分炽热的 Serverless 理念，并为服务端同学提供了 FaaS（Function as a Service，函数即服务）的能力。

MBOX 平台仍然采纳了动静类加载机制来实现代码的热更新，并联合字节码技术提供了一个 JVM 内的“平安容器”，把 Java 语言的动态化个性使用到了极致，其架构理念和实现原理如下图所示：

通过配套的研发平台和公布零碎，开发者能够将本人编写的一个类动静加载进线上利用的 MBOX 容器中，并创立一个单例对象；各种常见中间件如 RPC 和缓存能力，都能够通过注解进行申明注入并应用；而服务一经公布，便能够通过指定的 Gateway 拜访到。这种无需配置、开箱即用、疾速上线的轻服务迭代形式，十分实用于过后无线服务端所面对的开发场景：对现有的业务 RPC 服务进行组合编排，再加上一些面向 APP 端的简略解决逻辑，应用 MBOX 便能够在几小时内实现从开发到上线的整个流程，生产力失去了极大的晋升。

场景搭建

早在 PC 时代 CBU 就曾经建设了页面搭建相干的技术产品，而在无线端，这一命题实现起来却要简单许多。首先，客户端的页面并非像前端一样，由规范的浏览器所承载，iOS 和 Andorid 双端从底层的零碎机制到下层的组件实现都齐全不同，要想实现对立的页面搭建，势必须要抹平这层差别。其次，场景搭建并不是简略的堆砌组件，还须要思考每个组件背地的数据源：来自各种利用的服务接口必须和组件解耦，而不能在组件外部通过 Native 逻辑实现，否则将会导致组件齐全丢失复用性，并且使业务迭代更加依赖发版。

为解决上述问题，各端的工程师付出了诸多致力。首先是制订多端差别的抹温和交融计划，该计划从各端组件化渲染计划进行形象，对立了一套绝对形象、可扩大的协定，蕴含页面协定、布局协定和组件协定三大部分。页面协定指定了以后页面的根本信息、页面主体构造、埋点信息、渲染形式；布局协定指定了该布局下所有组件的布局形式，同时以布局容器可反对组件 abtest、组件分流、组件个性化等投放形式；组件协定细化到组件的根底属性、渲染形式，除此之外，还会定义组件的数据绑定行为、数据申请形式、数据取数形式，从而将组件 UI 和数据解耦，晋升组件复用性和可维护性。

Android、iOS 双端别离面向这套标准协议，对端上的多种渲染计划和 Native 能力进行封装，提供了对立的搭建容器实现，抹平了多端渲染的差别。

在此基础上，前台的开发 / 经营就能够通过搭建和配置化的形式，构建出前台页面的渲染协定（页面协定 + 布局协定 + 组件协定），该协定最终被上行至服务端的“渲染网关”节点，由其来收口所有搭建场景中协定的下发。除了协定下发之外，渲染网关还收口了所有组件的取数逻辑，通过一个通用的数据网关接口来对立前台组件的取数形式，让整个搭建体系变得更加简洁和规范。

构建残缺的场景搭建体系是一项盛大的工程，其中蕴含着有数研发人员的智慧结晶，受限于篇幅本文不再过多开展，想要理解更多的敌人能够参考咱们之前的系列文章：

• 《CBU 场景经营建设实际与摸索》
• 《CBU 端容器标准化计划》

麻利研发体系

在场景搭建体系中，渲染网关对外封装了对立的取数接口，前台的组件将会通过这个接口 间接 生产后盾的服务端数据源，也就是一套重后端的计划（次要逻辑在服务端实现），因而在理论落地当中，往往须要为每个组件独立开发一个专属的数据源，这些数据源根本是对已有的 RPC 服务进行简略调用，而后封装一些前台相干的逻辑，因而应用轻服务来解决再适合不过了。于是两者互相联合造成了一套十分麻利的研发体系：前端开发者开发 UI 组件，后盾开发者通过 MBOX 编写一个轻服务，疾速适配生成数据源，两者通过搭建进行简略的配置化绑定，一个页面就实现了，非常高效。正是这样麻利的研发体系，帮忙 CBU 疾速地开辟了无线战场。

营销会场类页面是利用这一研发体系的典型场景，咱们以某行业导购会场为例来体验其研发流程：

在这种研发体系下，前端和客户端研发人员能够专一于开发本人的组件，而服务端研发人员则能够应用轻服务的形式疾速为对应组件适配封装对应的数据源接口（或者是编写传统的 RPC 服务），得益于搭建平台对组件和数据源的规范形象，单方的研发流程能够相互解耦，让整个研发体验变得更加专一和高效。而采纳这种前后端拆散的模式之后，各端的技术能力和架构将失去更加聚焦的打磨，因而咱们在之后将看到前台组件和后盾数据源的研发模式都会呈现新的冲破。

总之，新的研发体系大大晋升了前台场景的研发效力，这离不开背地的两大关键技术冲破 —— 场景搭建体系和轻服务平台。而在此之中，又蕴含着有数工程师智慧和汗水的结晶，是他们面对未知时的勇气和保持摸索的激情成就了这些平凡的技术产品，并为 CBU 研发体系的演进之路立起了一座新的里程碑。

向开辟路线的先驱者们致敬。

摩登时代（2019～2020）

故事还在持续。最近两年，挪动互联网曾经进入下半场，随着工夫的推移，既有业务模式演变的越来越简单，同时也越来越成熟，而在此基础上，又有着诸多新的赛道被开辟，越来越多的竞争对手走上了跑道。咱们看到了航母级 APP 在一次次的打磨和历练中完工并启航远征，各种新的业务场景像停靠在甲板上的一架架舰载机，随时筹备以极快的速度腾飞。总的来说，已有业务实现了横蛮成长，逐步步入须要更多精细化打磨的阶段，而更多新兴的业务场景则须要通过借助既有的积淀，用比以前更快的速度跑起来。

而在技术侧，职能细分化使得各端的技术栈在过来几年里都失去了相当大的冲破：在前台展现方面，无论是前端还是客户端，组件化研发都曾经成为根本共识，并且技术计划也高度成熟，甚至呈现一些可能依据 UI 智能还原生成组件的技术。而在后端和运维方面，随着 Kubernetes 一统容器编排，云原生理念被迅速引爆，大量的底层运维和中间件能力被再一次下沉，以 FaaS 为代表的 Serverless 技术手段带来了生产力的极大晋升，让下层人员可能更加关注业务逻辑。对于大部分的一般业务场景，前后端技术都曾经实现了肯定水平的凋谢化：前端能够通过 Serverless 能力来疾速编写服务端接口，后端也能够通过低代码和可视化计划开发前端组件，这都象征着对应技术栈的高度成熟化。

在上一个阶段中，咱们通过搭建体系 + 轻服务的形式，打造出了一套可能麻利迭代的高效研发体系，帮忙 CBU 疾速实现了无线业务的布局，但在“横蛮成长”过后，也开始逐步暴露出一些问题，其中最为重要的是以下几点：

1. FaaS 服务带来了十分快的迭代速度，也造成了服务的疾速收缩，导致整体业务逻辑十分的扩散，同时也进一步加剧了零碎的复杂度。
2. 轻服务平台的底层架构依然是基于 JVM 实现，无奈实现精细化的资源隔离和弹性伸缩，随着应用范畴的不断扩大，性能和稳定性问题日益凸显。
3. 现有的研发体系尽管灵便度很高，然而有肯定的上手和学习老本，并且各个平台之间的割裂感非常明显，仅仅是通过一些约定连贯在一起。

针对于以上问题，咱们进行了大量的探讨和剖析（具体可见前文《CBU Serverless 研发体系 FY20 S2 建设总结》)，并贴合理论业务诉求和业界技术的倒退状况，制订出了以下的策略：

1. 依照畛域驱动设计的思路，对服务进行分层，从而无效梳理整体系统结构，同时对各类数据源进行标准化的定义和形容，制订对立标准来治理复杂度。
2. 轻服务平台底层架构进行降级，对接团体 Serverless 基建，全面拥抱云原生，开释技术红利。
3. 以搭建体系为外围，对现有的工程能力和研发平台进行系统化整合，打造一套面向前台场景的标准化解决方案，让后续相似场景的研发变得易了解、易上手、易保护。

上面笔者将别离为大家介绍每一个策略的具体实现计划。

MBOX + FunctionCompute：打造真正的云原生 FaaS 解决方案

前文提到过，CBU 在很早的时候就开始大规模利用落地轻服务平台 MBOX，通过几年的积淀，这种 FaaS 模式的服务曾经简直浸透进咱们的每一条业务线，带来了显著的研发提效，MBOX 这一技术产品也在通过屡次打磨后变得越来越成熟。

与此同时，咱们也始终在关注着业界和团体内对于 Serverless 架构的最新落地计划，冀望可能将 Runtime 层的实现从 JVM 容器降级为真正的 Serverless 容器，实现更平安的资源隔离和弹性伸缩能力。这个财年，咱们和阿里云函数计算（Function Compute，下文简称 FC）团队的同学并开展了单干，通过近一个季度的打磨和试错，实现了 MBOX 平台与 FC 函数运行时的整合，为服务端的研发同学打造出了一套将大量历史教训和最新技术计划相结合的规范 FaaS 解决方案。

在这套计划中，最大的改革来自中间件能力的下沉，得益于各种中间件能力的 sidecar 化，下层的业务利用能够变得非常轻量，从而具备了疾速部署和弹性伸缩的条件。在此基础之上，FC 团队联合团体的基建，提供了成熟的函数运行时容器，反对函数级别的资源隔离和弹性伸缩，实现真正的 Serverless 能力。最终，咱们将通过多年积淀的 MBOX 编码方式和新的中间件调用形式进行了高度整合和优化，面向研发人员提供一套十分高效的业务 FaaS 编程框架和配套的预览调试插件，真正做到开箱即用的研发体验。整体计划架构如下图所示：

和传统的利用相比，这套函数利用计划非常轻量，能够实现疾速迭代，同时还能够享受 Serverless 的红利，无需关怀资源运维。而相比于原有的 MBOX 轻服务计划，又有着更高的扩展性和安全性。

建设规范化的数据源体系

在前后端拆散的研发模式下，通常将为前台组件提供数据的服务接口统称为“数据源”，在之前的研发体系中，任何模式的服务接口都能够注册成为组件的数据源，并没有任何的标准或者规范，最终随着工夫的流逝，体系中的数据源数量飞速增长，难以保护。通过剖析后，咱们认为呈现这种景象的次要起因有以下几点：

1. 大量一次性数据源的产生。咱们能够看到，前台组件往往无奈间接生产现有服务，那么只能通过服务端生产已有服务进行二次封装的形式来提供数据源。这种数据源根本都是为组件所定制，基本没有复用性可言，但又会大量存在和收缩。
2. 数据源没有做好分层，通用的底层服务和面向组件的一次性数据源散落在一起，在这种模式下，研发人员通常不会无意识地对本人的业务服务进行收拢和积淀，往往是即用即写（甚至复制粘贴），最终整个体系下的数据源变得越来越凌乱和难以治理。
3. 超过 90% 的数据源都没有文档和阐明，对于应用方来说，往往只能通过口口相传的形式来理解本人想要的服务到底能够“找谁获取”，这种齐全依附教训的研发合作形式效率是十分低下的，沟通老本极高。
4. 数据源的研发体验非常蹩脚。要生产已有数据源，通常是编写一个 FaaS 脚本，要么通过传统利用再封装生成一个新服务再通过网关裸露。这两种形式的研发体验都泛善可陈，前者因为是泛化调用所以没法应用编码提醒，后者则须要面对引入二方库带来的抵触和迟缓的部署速度，再加上没有文档，研发同学在开发代码时的体验可想而知。

为了解决上述问题，咱们在现有的混沌场面之上建设了一套新的分层规范和标准，并提供了一系列新的工具和能力切面，逐步造成了一套全新的数据源体系，并命名为“奇点”，上面咱们来看一下奇点是如何解决以上问题，又带来了那些新的能力：

第一步，对数据源进行分层和标准化。

通过对历史教训的演绎总结，咱们将各类数据源进行了分层，并对每一层的数据源进行了标准化的形象：

值得一提的是，咱们将原来很多专门为前台组件适配数据逻辑的轻服务脚本从数据源中剔除了进来，独自形象了“字段映射”的脚本层，防止这些一次性的服务净化整个数据源体系。

咱们为开发者提供了一系列的插件，能够从服务端的代码定义中抽取出这些数据源的定义并进行标准化封装，而后注册至奇点的后盾数据库。随着底层开发同学的逐渐接入，咱们便能够缓缓建设起一个更加清晰和规范的数据源体系。

第二步，减少能力切面，让所有数据源变得可了解、可编码。

在第一步的根底上，咱们还要彻底解决数据源的应用问题，首先要让数据源变得可了解，目前奇点通过 javadoc 扫描源代码正文的形式抽取所有服务的出入参定义及阐明，并适配成规范的 swagger 开源协定，导入到 RAP 平台（由阿里开源的 API 文档平台）造成文档，在此基础上咱们还会通过特定形式采集服务的一些实在样例，这样任何人都能够疾速了解一个数据源的具体含意和应用形式，彻底改变之前口口相传的低效合作形式。

接着还要进一步简化和标准数据源的应用形式，这里先说说面向服务端侧，奇点提供了一套通用的调用桩 SDK，通过引入该 SDK，只有晓得数据源在奇点平台中的签名（即惟一标识符）就能够疾速创立一个调用桩，并能够通过该调用桩进行泛化调用，齐全不须要感知底层服务的类型，也无需引入任何其余依赖。思考到泛化调用形式在开发时无奈实现代码提醒，体验比拟蹩脚，咱们还制作了一套 IDE 中的辅助插件，这个插件通过扫描源码时所记录的出入参字段构造，能够在指定的工程中生成对应的 DTO 类定义，再加上一些序列化转换逻辑，理论开发人员便能够实现非泛化的调用，就像应用本地定义好的服务一样顺畅，而这种形式因为没有引入任何二方包，所以不会产生任何我的项目依赖抵触问题，因而研发效率不会受到任何影响。

总之，通过为所有接入的数据源提供文档、样例、调用桩和字段构造这四个通用的能力切面，奇点做到了让所有的数据源变得可了解、可编码、可观测。随着一直推广和业务场景的笼罩，这将有助于在研发人员内造成一个良性循环，从而长期维持新的体系秩序。

第三步，扭转前台组件生产数据源的形式。

始终以来咱们都通过封装服务接口的形式为前台组件提供数据源，这样会人不知; 鬼不觉中产生大量的一次性服务。这些服务通常都没有什么简单逻辑，只是生产一些现有的数据源而后做简略的字段映射。通过思考咱们最终将这类服务从奇点的数据源体系中剔除进去，独自形象为字段映射的脚本（应用 FaaS 实现）。前台组件最终将不再间接生产数据源，而是通过一份标准协议，申明其所须要的数据源和用于解决这些数据源的映射脚本，通过映射脚本来生产数据源。

这份标准协议能够通过搭建平台主动生成，通过这种形式咱们将大量的一次性逻辑独自抽离了进去，防止它们对数据源体系产生烦扰，起到架构中防腐层的作用。

总之，在建设完奇点这一套新的架构体系后，咱们终于“守得云开见月明”，打造出了一套清晰可用的数据源体系，至此咱们曾经根本解决了之前研发体系中的绝大多数问题，是时候对它们进行肯定的整合，来产出面向前台场景的规范研发解决方案了。

前台场景研发规范解决方案

能够看到，通过多年的积攒和打磨，CBU 的前台场景研发体系曾经十分成熟了，整体看来，它是由几个关联性很高的子平台所形成：组件平台（前端、客户端用于开发和注册组件的平台）、搭建平台、FaaS 平台、和数据源平台（奇点）。在过往的研发流程中，这些平台之间是通过一系列的约定进行联动的，而这些约定往往是“教训”性质的，对于没有应用教训的同学而言，了解和上手的门槛还是有一点高的，且各个平台之间存在着比拟强的割裂感，在整个研发流程中开发人员须要在多个平台之间重复操作和跳转，带来了很多不变。

在攻克了原有体系中存在的诸多问题之后，咱们决定将这套新的前台场景研发体系进行标准化，以搭建平台为核心，通过绑定关联的形式、买通其余各个子平台的性能，将研发流程集中串联在一起，把搭建平台打造成场景研发的外围“工作台”，积淀出一套规范的前台场景研发解决方案。

在这套规范的解决方案中，一个前台场景由一张搭建页面（蕴含多个组件）、一个 FaaS 函数利用（由规范的脚手架生成）和一系列的数据源组成，在初始化阶段中，能够将三者进行绑定关联造成一个残缺的场景工程。

实现初始化后即可进入理论的研发阶段，这个过程中前台研发专一于组件的实现，后盾则负责在 FaaS 利用外部援用各种奇点数据源（或新增）实现业务逻辑，再通过字段映射脚本为指定组件进行 UI 层的封装适配，单方都能够做到 Only Focus on Business 的研发体验。

研发阶段实现后，即可在搭建平台上进行配置和联调，因为各个子平台曾经实现高度串联，因而在搭建平台上能够间接实现组件、数据源和字段映射的绑定及实时预览，甚至能够通过打印数据链路来排查可能存在的问题，节俭配置和联调所用的工夫，也升高出错的老本。最初再进行测试和公布，一个前台场景便可上线。

以咱们目前曾经落地的无线商品详情页场景为例，在此规范解决方案下，研发流程如下图所示：

十分乏味的是，仔细观察这套计划的理论开发阶段，其中一个组件模块所蕴含的内容：组件 UI + 映射脚本 + 业务数据源，这一组合正是 10 年前 bundle 思维的连续。但相比于过后，新的这套计划更加标准化、更加易于应用，可能疾速地被利用于各种前台场景。另外咱们也能够看到，随着各端技术栈的成熟，繁多业务模块的研发流程又再次被高度集中化，这其中大部分的研发工作都曾经非常简化，例如组件的低代码开发、无需关怀运维的函数即服务，或者这些工作当前又将脱离具体的岗位划分，整合成一个新的“全栈”工程师角色，如此一来，单个需要研发的沟通老本将会进一步升高，研发效力或者会再次迈上一个新的台阶（当然，这只是一个 YY 性质的揣测，欢送大家拍砖交换）。

结语

至此，咱们曾经一路走过整整十年的历程，感叹过往峥嵘岁月的同时，咱们也在努力创造新的辉煌。研发体系的演进之路不会有起点，将来咱们仍将持续摸索。感激一起前行的同路人们，也欢送更多有识之士退出咱们，一起铸就下一个新的时代！

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。