第三届搞搭建|月飞-如何设计实现中后台搭建 - PaaS 平台

前言

Hi，你们好，今天很是高兴能有机会做为讲师，来给你们分享关于《如何设计实现中后台搭建 PaaS 平台》这个话题。今天的分享将围绕阿里淘系技术部飞冰系列产品中的中后台搭建产品 iceluna 来进行展开。

我的介绍

在正式分享以前，先自我介绍一下。我是来自阿里淘系营销中后台团队的月飞，负责中后台搭建产品 iceluna，以及《阿里集团中后台搭建协议标准规范》的推广和落地。2013 年加入阿里巴巴聚划算，负责 PC & 无线详情。2016 年加入天猫，带领营销玩法团队，负责玩法、互动类型业务。2019 年加入淘系技术部，带领营销中后台团队，负责中后台业务，专一于中后台搭建产品建设。

话题介绍

今天的话题是搭建，以面向角色的不一样大体能够分为面向运营和面向研发两类搭建产品。面向运营的搭建产品主要是以可视化配置 ( No-code ) 的方式进行完整页面搭建，如营销活动页面搭建。面向研发的搭建产品主要以低代码开发 ( Low-code ) 的方式，搭建“中后台系统”或者“无线模块”，如商家、小二后台系统的搭建，无线 Rax 模块的搭建。今天我这边的话题是中后台系统搭建，跟营销活动类页面的搭建在面向角色和搭建模式上是很是不一样的，接下来主要围绕 “ iceluna 产品 ” 和 “ PaaS 平台建设 ” 2 个维度来展开分享。

分享大纲

这是我分享的大纲，我会先对 iceluna 这个产品进行总体介绍，讲解下产品背景、定位及现状。第 2 部分会从架构设计、功能模块设计、研发流程设计三方面来介绍中后台搭建产品的设计思路，让你们对 iceluna 产品全貌有个基本认识。第 3 部分会着重从中后台搭建基础设施维度来说一下 iceluna 是如何建设搭建基础设施的。第 4 部分则会回到 PaaS 平台这个焦点，来说解 PaaS 平台须要建设的核心能力。最后会稍微作下总结和展望。

iceluna 产品介绍

产品演示

你们如今看到的是 iceluna 界面，由于目前产品还未开源，还未对外网访问，你们能够先看一下这是咱们研发中心的一个站点首页，第 2 页是站点区块中心，在这里面能够看到区块市场，区块管理等内容，由于演示页面数有限，在这里还能够看到顶部 tab 还有组件和模块等物料管理。第 3 页是应用研发中心，里面有页面，应用组件，导航，数据中心，发布等等一系列操做的界面。最后这 1 页是 iceluna 的低代码搭建编辑器，这也是 iceluna 产品最核心的一个能力，整体界面和产品形态仍是比较清爽，中间搭建的是一个商品列表页面。

产品背景

刚演示了 iceluna 几个核心页面，对整个产品有了一个基本的了解，iceluna 产品发展至今已经经历了 3 年半时间，产品一路迭代演进至今的低代码开发 PaaS 平台，背后有着一系列缘由。在了解这些缘由以前，想先跟你们普及一个概念，今天咱们一直在提的“低代码开发”。对于 iceluna 通用搭建来讲，有着本身的一点理解，它是经过可视化的方式，使具备不一样经验水平的开发人员能够经过图形化的用户界面，使用拖拽组件和模型驱动来搭建网页的开发模式。

了解完这个概念，咱们来谈下 iceluna 产品的背景：

• 中后台技术之殇：在淘系整个业务偏消费者端，中后台这一侧人力投入是偏弱的，这是目前中后台的一个困境。咱们有大量的商家或小二操做系统，前端人力至关紧缺，大量系统依赖后端/外包/ ISV 负责研发，因为前端工程环境复杂，技术迭代快，门槛高，在效率/质量/体验/可维护性等方面存在较多问题，对于如何赋能？如何改善协做模式？传统源码模式已不能知足业务发展的诉求，对于低代码开发模式的需求日趋强烈。
• 低代码开发模式的崛起：据 Forrester 市场调研结果，经过低代码开发模式可带来数倍甚至 10 倍以上研发效率的提高。这对于中后台现状面临的一个业务压力，是咱们很是迫切须要解决的一个问题，那就是如何提效的问题。它给了咱们足够大的想象空间。近年来各大互联网巨头公司都以纷纷投入到低代码或无代码平台的建设上来。在阿里的话，各大 BU 也是重兵投入到这一块的。这也就衍生出来第 3 个问题，那就是搭建泛滥后的技术收敛和统一。
• 搭建泛滥后的收敛和统一：阿里内部各 BU 针对不一样业务场景构建保守估计有数十个以上低代码搭建产品，投入成本巨大，能力完善程度相对不一。在搭建这块如何收敛和统一？完善搭建基础设施，由集团层面提供统一的搭建服务的运行和开发环境，是势在必行。我我的做为集团搭建协议的负责人，也是但愿经过 iceluna 产品去解决这一块的问题，能讲 iceluna 演进成为一个搭建 PaaS 平台，去提供搭建底层服务的能力，服务全集团的搭建产品。

产品定位

目前 iceluna 产品有着 3 层定位：

1. 中后台通用搭建产品：由淘系技术部研发，面向全体研发人员可用，打造一个中后台通用的搭建产品。因为淘系业务几乎以商家，小二运营操做系统为主，业务逻辑多，交互复杂，很难抽象固定场景的业务模版或可视化配置的解决方案。所以，须要咱们低代码开发的中后台搭建产品具有有极强的通用性和扩展性，才可以 100% 覆盖复杂交互的中后台系统页面的搭建。
2. 全链路低代码开发平台：集前端应用工程建立、开发、调试、发布，甚至到页面的托管，全链路一体化的低代码平台。屏蔽复杂的前端工程体系，全链路打通。
3. PaaS 平台：建设搭建基础设施，基于标准搭建协议生产搭建物料，为各业务场景提供搭建服务的运行和开发环境。 目前 iceluna 的 PaaS 平台主要以如下 2 种模式提供服务：
4. 平台模式：业务研发进入 iceluna 研发中心，全链路在 iceluna 平台上进行编辑器定制和运行，业务托管在 iceluna 平台上；
5. 中台模式：脱离 iceluna 研发中心，对外将 iceluna 编辑器能力和低代码能力以 npm 包形式提供出去，助力于孵化各个领域场景的独立的低代码编辑器，独立部署。

而后，咱们在目标设定上，对应有以下 3 个目标：

1. 赋能：赋能是咱们第一重要的目标，由于在目前中后台发展的业务现状下来讲，赋能偏偏是目前最能消化中后台业务压力的一个重要手段，这是咱们通过 2 - 3 年在业务上不断摸索下得出的一个结论，赋能能够经过后端、外包，改变与前端的一个生产关系，去改善和提高研发项目或者说总个研发团队的生产力，使得咱们后端外包能够跨界的工做，减小一些没必要要的依赖和成本。
2. 提效：目标仍是下降研发成本。提效一直是咱们技术永恒的话题，但就 iceluna 现状来讲，提效效果并非特别的理想，在下一页现状会聊到。
3. 搭建生态：但愿成为一个 PaaS 平台或搭建中台，去孵化领域搭建产品，造成搭建产品矩阵，在各领域上有更高研发效率。

产品现状

iceluna 是一个面向集团提供服务的通用低代码开发平台，基于产品定位和目标，iceluna 在赋能、提效、搭建生态上均取得不错成果。

• 赋能：活跃用户数 1000+ ，后端占比 44% ，前端占比 39% ，测试占比 11% ，外包占比 7% 。从占比能够看到，有超过 60% 的用户属于非前端研发人员，在使用 iceluna 进行系统页面搭建。经过数据能够看到， iceluna 在赋能上有不错的效果。
• 提效：上线应用 440+ ，页面 6000+ ，覆盖阿里多个部门中后台应用研发，经霍尔斯特德软件复杂度算法模型测算(后面章节会介绍)，人均研发效能提高 200% 左右。
• 搭建生态：提供完备的搭建基础设施服务 & PaaS 平台服务，已孵化 8+ 业务场景定制的搭建产品。

iceluna 架构设计

架构设计

上图是 iceluna 产品从 PaaS 角度看的一张架构分层图，从图上咱们能够看出，核心包含后端服务、搭建基础设施、PaaS 服务、研发中心、搭建产品 5 层。下面对每一层服务能力作介绍。

• 后端服务：基于 Node.js 的 Midway 框架实现的一个 Server 层，提供搭建平台数据接口和 Socket 服务。
• 搭建基础设施层：目标提供搭建编辑器的开发环境。核心包含中后台搭建描述协议、低代码编辑器、插件生态、物料生态 4 个模块能力建设；
• PaaS 服务层：提供搭建编辑器的运行环境，使其能具有有完备的搭建配套服务能力。
• 研发中心层：业务研发的主阵地，提供云端一体化的研发流程。包含站点中心，应用中心，物料中心，数据中心 4 个功能模块。
• 搭建产品：最上一层是搭建产品层，是 iceluna 做为 PaaS 平台或中台，目标孵化的各个垂直领域的搭建产品。

功能模块设计

接下来从功能模块设计角度来进一步了解 iceluna 的功能全貌，仍是基于刚 PaaS 角度的架构设计核心 3 个分层来拆解里面的核心模块。

搭建基础设施这层的话，就包括基础能力的建设，包含搭建协议，视觉规范，工程脚手架等源码级别的一些基础能力。其次是咱们搭建编辑器内核，包含了骨架、主题包、插件、用于配置可视化属性面板的控件，另外就是我画布和渲染引擎 2 个核心模块，另外还有国际化能力模块。在插件生态模块上，目前总体搭建编辑器上全部的功能模块均是以插件的形式存在。好比在顶部咱们会有模型驱动、图像识别、数据驱动、逻辑编排、流程编排等插件，这样一些插件是目前咱们重点推广或重点研发的插件，做为研发模式升级提高效率的核心主抓手。其次是编辑器上常规一些的大纲树、属性/事件/样式/数据等插件，在现阶段主要以可视化加强来达到提效目的。在物料生态方面，咱们但愿构造一个完备的物料生态，经过低代码方式开发搭建组件、搭建区块、搭建模版、组件实例，并进行物料的发布和共享。对于  PaaS 和研发中心模块就再也不一一作详细介绍。

研发流程设计

这一页重点介绍 iceluna 研发中心的研发流程设计，主要分 2 个权限角色：

1. 站定管理员：通常由专业业务前端负责，建立站点审核经过后，能够完成站点基本信息、编辑器默认配置、应用默认配置、物料默认配置等信息。该配置讲决定了在该站点下建立的应用主题、搭建编辑形态、以及物料供选池子等。
2. 应用管理员：选择进入某个站点后，能够在该站点下建立应用、建立多分支、进入搭建编辑器搭建页面或组件，在线实时调试，一键发布部署等操做。

中后台搭建基础设施建设

了解了 iceluna 从各个维度的设计，相信对 iceluna 的产品设计有了一个更全面的认识；那么接下来，咱们从实现层面，看看 iceluna 建设了哪些基础设施能力，来保障搭建平台的技术先进性。

从这一页内容是咱们整个低代码搭建基础设施的一个内容全图，从左侧咱们能够看到一个物料研发的流程，由专业前端同窗研发源码的物料，并沉淀到物料中心，这样一个源码的物料，经过咱们一个解析模块，能够生成一份搭建组件描述文件，有了这份描述文件，就能够入驻到咱们的低代码搭建编辑器里面来，低代码搭建编辑器会识别这个组件，生成这个组件的属性配置面板，并具有有良好的搭建编辑体验。其次，编辑器能够将已入驻的源码组件，以发布的方式上行到物料中心，沉淀成为一个搭建组件。多个搭建产品矩阵，基于相同协议标准，与物料中心的上下行，使物料得以流通和复用，从而造成物料生态。从最右侧能够看到，先后端、外包、测试都是经过搭建方式来使用低代码编辑器，低代码编辑器成为了最核心的一块能力。如何保障低代码编辑器的技术先进性，整体建设的思路，从如下 5 个方向阐述：

1. 首先要定义一个搭建描述协议的标准规范，全部搭建产品遵循这套搭建规范，这样可使物料得以流通。
2. 咱们要构造一个搭建编辑器开发生态，iceluna 做为 PaaS 平台或中台提供出来的一个能力，去低成本的孵化各场景下的低代码编辑器；
3. 就是咱们提供出来的低代码编辑器，在面向不一样端的一个诉求，咱们会包含 React，Rax，小程序等技术栈的搭建，须要编辑器能支持多技术栈，适配多端。
4. 相比其余低代码编辑器，它如何保持技术先进性，有哪些核心能力建设。
5. 是咱们要打造的插件生态 和 物料生态。

搭建描述协议标准规范

如何指定搭建描述协议的标准规范？从如下 4 个方面阐述个人一些思考：

1. 版本化、语义化、渐进性描述：版本控制，语义清晰，简明易懂，可读性强；搭建的本质是经过源码组件进行嵌套组合，从小往大、依次组合生成组件、区块、页面，最终经过云端构建生成 应用 的过程。所以在搭建基础协议中，咱们须要知道如何去渐进性的描述组件、区块、页面、应用这 4 个实体概念。
2. 不引入新概念，可与标准源码互转：不引入新的语法概念，代码部分纯 JS 语法，下降上手门槛；明确每个属性与源码对应的转换关系，可生成跟手写无差别的高质量标准源代码；
3. 可扩展，可流通性，面向多端：支持第三方 npm 包的引入，加强协议描述能力的扩展性，以应对不一样应用复杂多变的需求，如 Lodash ，Moment.js 等第三方工具库；产物能在不一样搭建产品中流通，不涉及任何私域数据存储，统一标准，构建搭建物料生态。不能仅面向 React，还有小程序等多端；
4. 支持国际化

低代码编辑器开发生态

iceluna 做为一个 PaaS 平台或搭建中台，咱们但愿把搭建编辑器底层全部的能力都能原子化的开放出去，因此咱们在建设搭建编辑器的时候考虑到了如下几个问题：

1. 分层架构：整个框架分为四层能力的建设，最里层为搭建编辑器的内核（主要有消息通信、状态的管理及配制的解析、骨架的加载、插件的机制的加载等能力）；其次为渲染模块，也就是渲染模块的部分，它的输入就是符合搭建描述协议的 Schema，经过这个模块能够把整个页面渲染出来；再往上为编排模块，主要负责画布区域的物料拖拽、下钻编辑、点击，快捷键，多设计模式等操做，提供了灵活的拓展能力；最上层为整个编辑器的框架，包括骨架、主题以及编辑器里面全部的面板都是以功能插件的形式集成进去的。
2. 模块化解耦：这里的框架分层，每一层均为独立 npm 包，提供原子化服务的能力去开放。好比咱们能够以总体低代码编辑器总体开放给须要的场景，也能够只以编排引擎或渲染引擎的方式去开放，如物料中心搭建物料的预览。
3. 扩展能力及开发生态：除了提供现有的能力以外还提供完整的骨架，插件及控件的开发脚手架及命令行工具来保证整个低代码搭建编辑开发机制是完备完善的，同时整个骨架、插件也是能够在咱们整个平台进行配制或定制。

低代码编辑器多端适配

目前搭建编辑器面向的领域不只仅是中后台 React 的体系，还包含有 Vue ，小程序、Rax 的体系，这样的一些体系由于底层的技术栈不一样，对于组件的解析和渲染存在较大差别，不能经过纯粹的 React 渲染模块来把总个页面渲染出来。全部呢，咱们怎样去适配多端，须要针对不一样的技术栈，来实现对应的渲染引擎，经过很薄的一层适配层来使得咱们的搭建编辑器支持各个技术栈的渲染，从而达到多端适配的目的。好比，阿里表格数据报表的搭建， imgcook 消费者端搭建，淘宝小程序搭建等。

低代码编辑器核心能力

第 4 块内容，就是咱们如何保障搭建编辑器技术先进性的一些核心能力。

1. 开箱即用： 提供全链路一体化的搭建服务，不须要到线下去 2 次开发。其次支持定制搭建编辑器和定制业务主题风格。同时在咱们平台上支持多人协做、多分支并行开发，能够应对大型复杂工程。好比淘系营销系统，同时会有数十我的并行开发同一个应用，每每会创建数个分支并行开发需求。因此呢，像这样一些大型复杂系统，中后台搭建系统不具有有多人协做和多分支并行开发的能力，那基本上在咱们的业务场景上是没法落地的。因此这 2 块能力建设很是关键和重要。
2. 安全沙箱隔离：咱们对业内比较多的搭建产品作市场调研，发现较多搭建编辑器是没有作好沙箱隔离的。 iceluna 发展 3 年，反复从作隔离到不隔离几个阶段的不断迭代，最终完全解决掉全部问题，彻底实现沙箱隔离，从而保障搭建页面与编辑器自己彻底隔离，互不干扰，并支持独立主题设定。
3. 实时调试能力：咱们的画布是一个真实的 Runtime ，它不是一个模拟器或不完整的渲染，业内不少低代码编辑器在搭建状态就是一个纯 UI 的渲染，经过低代码方式配置了交互数据或事件，它没法实时实时生效，须要经过预览或发布等链路才能调试 。而中后台场景业务逻辑很是重，每每须要高频的实时调试，这也是跟其余搭建产品不一样，是结合业务场景建设的一个重要能力。

低代码编辑器物料生态

咱们提供的通用搭建平台，对于不一样的业务场景，对于物料的诉求是不同的。今天，咱们的搭建平台服务于 400 多个前端应用，要服务集团 20+ 部门，或者更大的一个组织体系，若是只提供一套物料库，那搭建平台的可用性会所以而大打折扣。咱们须要针对不一样 BU 不一样业务场景，可以具有有快速接入不一样物料的能力，第 1 点咱们要能快速生产物料，第 2 点能快速接入已有的物料，第 3 点就是可以让这个物料流通起来，可以变成一个生态的机制，就如 Iconfont 图标生态同样。因此 iceluna 也在致力于怎样去打造一个低代码搭建物料的一个生态。咱们在这块作的核心工做，主要以下：

• 统一搭建物料描述协议：统一标准，规范生产，提高搭建物料的可复用性。
• 实现物料低成本接入：支持 React 组件 npm 包低成本的接入，不须要对组件进行 2 次包装或开发，经过简单配置一个表单，就能够将组件接入进来，而且保障组件在源码里面完整的全部属性，在属性配置面板能够具有完整的可视化配置能力，不管你的属性是什么类型，数组类型也好，对象类型也好，ReactNode 类型也好，都具有有完整的可视化机制，来保障良好的编辑体验。
• 搭建物料流通：建设搭建物料市场，造成相似 Iconfont 的生态机制。

咱们回到左侧图上来看，咱们的低代码编辑器，它不只仅是能够接入组件，最重要的能力就是经过低代码的方式来生产组件，为何？低代码编辑器面对更广的用户，好比后端和外包同窗，他们不掌握不少的源码知识，也不掌握源码的工程体系环境，可是他们一样会有作组件的诉求。其次，搭建编辑器自己就是一个提效的开发模式，不管是前端仍是后端，研发页面仍是组件，低代码开发一样带来开发侧的效率提高。在 iceluna 上，咱们也提供了物料专属的搭建编辑器，能够在咱们的平台上经过搭建的方式搭建物料，而且把这个物料上行到咱们的物料中心，最后造成物料流通的机制。

提供搭建服务的 PaaS 平台建设

这一章节，回到咱们主题的核心重点— PaaS 平台能力建设上来。对于在听的同窗来讲，可能对于 PaaS 平台的定位也不是特别清楚。PaaS：平台即服务 ( Platform-as-a-Service )，iceluna 的 PaaS 定位是把搭建编辑器的运行和开发环境做为一种服务，提供给不一样业务场景下的搭建产品。

前面咱们讲到了搭建基础设施是提供搭建编辑器的开发环境，那上层咱们还须要一个更加完善的平台侧服务能力，来提供搭建编辑器具有完整良好的运行环境，使得咱们具有有一体化研发的能力，在整个能力的基础之上去孵化垂直领域的搭建产品。

咱们将从下面 6 个维度来介绍 Paas 服务的能力：研发中心编辑器定制、云端构建 & 发布 & 存储、多人协做、多分支开发、代码回滚、效能衡量。

搭建编辑器定制服务

在咱们的站点中心提供了一个可视的方式来进行一个编辑器的配制，经过云端构建就能够构建出不一样搭建编辑器，好比右边的 Iceluna 搭建编辑器及下面的 imgcook 编辑器，就是在研发中心建立了 2 个不一样的站点，分别构建出来的编辑器。刚咱们看到了编辑器的一份配置，那么编辑器具体能够配置哪些内容呢？

• 布局定制：编辑器面向的领域不一样，场景不一样，作消费的页面和中后台页面，它对于面板画布的大小及可利用区域都是不一样的，全部咱们对于整个搭建编辑器面板布局是有不一样的诉求。而咱们能够经过这个的一个布局定制来快速构建出不一样的布局出来，再配制不一样的插件能够造成一个全新的搭建编辑器。

**

• 主题定制：搭建编辑器能够嵌入不一样的场景，好比在淘系里面咱们可嵌入 WebIDE 跟源码进行一个互转能力的打通，你能够同时切换到源码的开发，也能够同时切换到可视化的开发，在 WebIDE 的下面，它整个视觉风格就是个深色系，因此咱们在平台上面也提供了主题包配制的一个能力，而后再适配不一样主题风格搭配来定制编辑器。

• 插件定制：咱们提供了一个完备的插件化机制，整个搭建编辑器上的全部面板都是以插件化的形式来承载的，目前 iceluna 编辑器上总共有 26 个插件（图右可视），同时在插件生态池子里面，咱们日后会沉淀愈来愈多的公共插件，而且这个插件都是能够被嵌入到搭建编辑器里面的。  若是这个插件池子里面没有你想要的插件，咱们也提供了插件开发脚手架，给你来实现与编辑器功能解耦，可插拔，可定制的一个独立的插件。

云端构建/发布/ DB 存储服务

云端构建服务是 iceluna 低代码开发平台核心链路之一，目前云端构建的能力主要是把咱们在应用搭建过程当中搭建出来的页面，而后组件产生出来的 Schema ，存在数据库里面以后的碎片化数据，经过云端构建的方式，去发布成应用或组件或者编辑器资源包，同时构建出来的这些应用、组件它们的源代码，咱们也推送到 GitLab 做为存储，也会发到 CDN ，申请 CDN 资源最终推送到线上去。目前云端构建主要支持应用（平常/线上发布）、组件（Low code/ Procode发布)、编辑器（画布/框架的构建）3 大功能 6 种形态构建能力。

云端构建架构图分为数据层，运行层，通讯层，应用层4层，如图左所示。它的核心能力主要包含以下：

1. 编辑器去中心化：在咱们的平台，站点下建立的每个应用均对应一个本身的编辑器资源包，这样的话，咱们能够给每个应用去定制本身的主题和组件的扩展，并带有版本化控制的能力。
2. 一键发布部署：进行权限管控；对组件的依赖进行动态分析；在分支发布过程当中会须要合并主干，若是产生冲突的话，在线解决冲突；Webpack 构建和 CDN 发布。
3. 多系统打通：GitLab 存储以及经过 GitLab 来作代码回滚的机制，其次经过 Tair 作构建过程的并发锁，最后，经过 ODPS 作构建日志的分析。

多人协做服务

在 PaaS 平台，多人协做是一个不可缺乏的一个能力，它的主要原理是经过 WebSocket 的链接加上一个文件锁的机制，文件锁目前在平台上包含页面锁、组件锁、应用级别公共文件锁这三个维度的锁。大致思路主要是利用WebSocket 的保活的机制，与 Tair 保持一个心跳保活的消息通讯。在 Tair 侧则是存储一个主动失效的分布式乐观锁，而后去存储这个锁的信息，大概 10 秒钟以内没有新的心跳过来，这个锁就会失效。因此说一旦客户端或 Server 端的 client 断了以后，那这个文件锁就会被自动释放这样一个机制来作的多人协做服务。咱们也对业界多人协做的方案作了一些调研，好比钉钉文档、Google Docs 等都利用了业界比较先进的 OT 技术，实现相对复杂，功能也更强大。对于低代码搭建编辑器场景来讲，编辑锁的能力已经够用了。左侧 iceluna 编辑器上红线框出来的点，都是有锁的功能。

多分支并行服务

多分支并行的能力最重要解决的一个问题是冲突解决，对于源码来讲，冲突解决是已经存在的一个能力，但对于低代码云端工程体系来讲倒是一个很是难解决的问题。截止目前为止 iceluna 冲突解决的代码仍然是搭建描述协议 Schema 的代码，比对时相对比较困难，这是问题之一。其次，总个冲突解决的流程，多分支并行，包括代码回滚到数据库 DB ，这一块总个机制的构建也是相对比较复杂的。整体的流程如上图所示。

代码回滚服务

代码回滚服务主要利用的就是基线同步的机制，这个机制保障咱们能够指定任意 commit hash 进行编辑器应用代码回滚。由于咱们在低代码平台的每一次发布，都会将代码同步到 Git ，因此任何一次发布的代码均可以回滚到咱们的低代码编辑器。这里最大的难点就是 “ 数据库的碎片化信息 ” 与 “ Git 仓库上源码工程文件 ” 能具有有一一转换的关系。

搭建效能衡量体系

最后一页内容提到了低代码搭建平台的效能衡量体系，其实它跟技术不太相关，但为何要讲效能衡量这个体系呢？咱们在作搭建平台 3 年，还有其余兄弟团队的搭建平台都面临一个问题，就是都说搭建能提效，但没有一个很精确衡量提效多少的方法或策略，因此咱们花了很长时间去研究，怎样有一个策略来衡量搭建是否是真的提效了。具体的实现方式，衡量标准是咱们借助业界霍尔斯特德软件复杂度测量算法模型，这个算法模型能够将搭建页面时产出的 Schema 做为一个输入，它经过 Schema 里面的如表达式个数，代码长度等数十个算子，能够计算出 Schema 的复杂度以及预计开发时长。

固然，这个预计开发时长须要反复去调参，比较符合真实状况后会获得一个相对准确的数字。另外呢，低代码搭建相对于源码开发，有一个好处就是用户都是在咱们的平台上进行操做，平台侧能够经过埋点，操做日志等手段记录每个研发人员在某个页面上的操做记录，在 2 次操做间隔时长在 10 分钟以内的算有效开发时间段，有效时间段的总和就是实际开发时长。经过计算公式 研发效能 = 预计开发时长/实际开发时长 就能够知道该用户开发效能是提高仍是下降。在 iceluna 平台上数据中心会有专门一个效能中心，来反馈总个平台的整体人均研发效能、我的研发效能等数据。因此说这一点很是有价值，因此分享给你们。

总结&展望

• 前路总结：中后台通用搭建产品建设成本超高，能很好的解决赋能&协做的问题，但研发提效未达数倍甚至 10 倍的预期，须要往模型驱动、智能搭建等 Nocode 新研发模式升级，或建设领域搭建产品矩阵来达成数倍提效的目标。
• 展望将来：致力于将 iceluna 打造为中后台领域的 hpaPaaS 平台（超高生产力平台）。若是志同道合，期待的你的加入！

团队风采&招聘

最后，就是咱们团队的一个招聘，若是有意向的话，请扫码加一下个人微信！

投递简历方式

• 邮件：jianhui.fjh@alibaba-inc.com
• 钉钉：月飞
• 微信：

团队产品连接：

• 飞冰：ice.alibaba-inc.com/
• 淘系前端博客：fed.taobao.org/
• 淘系前端知乎专栏：zhuanlan.zhihu.com/tmallf2e

欢迎加入咱们的团队！！