从架构实践出发，深入剖析美团低代码平台 -WOLF

作者 | 闫园园

采访嘉宾 | 美团技术专家李勇

前段时间，有关低代码的争论一度刷爆了互联网圈。虽然笔者认为这种争论可谓是“百家争鸣”，对于低代码本身的发展是大有裨益的，但在此过程中，笔者也注意到大家的关注点似乎有些偏颇。毕竟，低代码在国外已经发展多年，功能非常完善，也形成了相当的市场规模；而其在国内也是愈演愈热，更多企业加入到抢夺“低代码”市场份额的拉锯战中，可以说低代码的“大火”不是凭空出现的，正是市场的选择。所以在笔者看来，大家应该将更多的关注点放在低代码技术本身而并非其概念。

低代码平台是工具的合集，这些工具可以通过建模和图形界面来进行应用程序的可视化开发。低代码使开发人员可以跳过手工编码，从而大大缩短了应用程序的开发时间。所以对于更多的企业来说，选择低代码无疑是大势所趋，那么在此过程中低代码究竟适用于哪些场景？低代码平台又怎样与公司业务相契合？在搭建过程中到底如何平衡易用性和灵活性这一难题呢？

为了给大家详细解读这些问题，我们特别采访了 ArchSummit 全球架构师峰会的讲师——美团技术专家李勇，他将结合美团低代码的实践 WOLF 平台跟我们聊聊这些话题，此外他也会在ArchSummit全球架构师峰会中带来主题为《美团低代码方案的探索与实践》的演讲，感兴趣的同学们也可多多关注。

深入浅出低代码

InfoQ：从目前来看，低代码被越来越多的人讨论，请聊聊您是怎么理解低代码的？

低代码的概念出来已经很久了，但是最近才持续的火热起来，一个很大的原因是国内互联网的火热，包括传统企业的互联网+的转型。而应用主要包括 C 端活动营销、B 端 CRM 应用、内部各种管理平台、数据分析等，这些应用需求量庞大，从功能上讲类似但又有定制化的需求，用传统方式的开发成本较高且门槛较高，所以催生了各种各样的低代码平台。

一般低代码平台都有两个作用：一个是提效，提效这个比较好理解，就是利用更少的代码完成相同的功能；而另一个是赋能，能够让其他角色参与到非自己工作属性的工作中，不仅能够减少沟通成本，还能够避免由于某一种角色的缺失或者人员不足导致项目无法展开的问题。

除低代码外，另外一个概念是无代码，低代码跟无代码往往在一起用来讨论和比较，但是一般没有比较清晰的区分。

我认为一个比较简单的区分是看用户角色是谁，如果用户角色是具有开发技能的，那毫无疑问是低代码，因为低代码往往需要更强的扩展性和灵活性；而无代码产品的用户角色一般是非开发人员，想要在通用性的前提下做无代码产品是非常困难的，所以现在无代码发展得比较好的是一些细分市场，类似易企秀、婚礼纪等一些比较具有代表性的无代码工具。

InfoQ：结合美团来说，低代码在哪些场景里适用呢？

目前就我了解到的美团内部的低代码场景主要有三个：一是营销活动场景，二是数据分析场景，三是中后台场景。

这其实与业界使用的三个场景也有一些类似，关于这三个场景为什么更加适合低代码，主要是因为这三个场景较为同质化，另外需求量也很大，所以更加适合。

拥抱低代码，美团 WOLF 平台实践篇

InfoQ：如果与公司业务或通用业务模型不够契合，低代码平台就会成为“花架子”。那么，WOLF 平台是如何围绕美团业务进行设计的？

我的思路是先对单个场景做深，然后再逐步扩大场景，像 WOLF 平台最开始针对的是我们团队自己的业务，我们团队的业务以 CRM 为主，所以我们以中后台为出发点，对当前业务进行提炼。

第一步：完成业务场景的组件化提炼。针对各个业务场景完成组件化的提炼，这里的组件并不是纯粹意义的业务组件，而是带有业务属性的通用组件，类似增删改查这种业务组件。

第二步：定义一种 DSL，来描述组件之间的关系。将 DSL 用解释器实现，通过定义通用的组件通信方式、事件机制等等，利用 DSL 来描述一张页面，减少组件之间粘合的代码。

第三步：由于需要将这些组件和能力开放给其他角色和部门，所以我们开始做包括可视化等低代码开发平台，逐步扩大生态。

总结一下思路，先针对自己业务封装满足自己业务的东西，然后再逐步扩大影响力，这样能够逐步看到成果，也能够增强团队内部人员的信心。

InfoQ：WOLF 平台是如何与美团其他系统平台联系整合的，能为我们举一个例子说明吗？

这里有两点：

第一，集团提供的公共能力，类似错误监控、权限系统、用户登录等。这些公共能力是集团所有部门通用的，一方面我们会复用这些能力，另一方面我们需要把这些能力进行整合，因为这些平台是分散的，而我们是提供一个通用的解决方案，所以需要把这些能力进行比较好的整合，比如我们会去跟这些平台聊合作，通过 OpenAPI 的形式，提供整合能力。这样既减少用户到各个平台去申请各种 APP 的时间，也能够在一个统一的地方进行管理，减少切换成本。

第二，与业务系统的整合。比如已经有一个老系统了，如何平滑过渡到新的方案进行开发，我们给出的方案是提供类似自定义模板、自定义域名、微前端、自定义菜单、npm 包等多种方式让用户根据自己系统的情况进行选择，跟原有系统进行比较友好的结合。

InfoQ：纯代码 ProCode 与低代码 Low Code 如何实现互转，是个讨论热度很高的难题。WOLF 平台是如何解决的呢？

首先来讲 ProCode 转化成 LowCode，从需求上来说，传统意义的 ProCode 一般是很少有需求需要转化成 LowCode 的，而且从技术上来说也是非常复杂的。而我们换了种角度去考虑：

ProCode 开发的组件如何在 LowCode 中复用，这其实是相对比较容易也有比较多的需求的。如果从组件的维度来说，只要你是一个对上下文没有依赖的组件，我们是可以通过 CLI 直接发布到平台进行复用的。

另外来说说 LowCode 到 ProCode 的转化。一般的思路是将 LowCode 编译成 ProCode，这其实是比较容易且大部分都是这么做的，但是这会带来一个副作用，如刚刚所说，这种转化后的 ProCode 很难再转化成 LowCode 了，虽然有些团队号称自己的 LowCode 是图灵完备的，但是如果是一个图灵完备的语言，倒不如直接使用 JS 来的直接。

所以我们的思路还是在配置化的基础上进行更灵活的扩展，比如支持本地开发、支持 JS、支持组件开发、全局状态等等，基本上能够满足大部分需求了，而最后实在无法满足才编译成传统意义的 ProCode 进行开发。

之所以会用这种方式是因为我们对一个页面的复杂度是有预期的，虽然一个页面会迭代，但是不会迭代到用低代码完全无法满足的地步，如果随便一次迭代就将 LowCode 转化成 ProCode 进行二次开发，那么这个页面享受到的开发提效只能是一次性的。

InfoQ：搭建低代码平台，对于 UI 的精确渲染还是有一定的必要的，那么 WOLF 平台采用了什么策略来做到精确渲染呢？

精确渲染在中后台的场景其实占比是相对比较低的，大部分是同质化较为严重的，所以我们的重点应该放在跟 UE 和产品同学针对场景和规范的制定上。

第一，常见场景的固定。跟 UE 和 PM 进行合作沟通，针对某些场景进行设计固定，PM 和 UE 同学不能再随便设计，减少 PM、UE、FE 三方的人力消耗；

第二，在组件之间的场景是有必要具备一定的灵活性的。比如组件之间的间距有大中小，字体有大中小等等，所以针对一些尺寸、间距、颜色等，我们是允许在规范内进行调整的；

第三，对于实在需要精细粒度的调整，我们也支持直接写 CSS 来进行更精确的调整。

InfoQ：对于低代码平台很难同时满足易用性和灵活性这一点，您和团队是怎么平衡的呢？

这确实是一个矛盾体，因为越灵活就意味着越复杂，而我们主要从两方面出发：

第一，我们在语法层面引入了预处理的机制，将语法进行了优化。因为机器语言跟人的语言是不一致的，机器更看重的是规则，而人看重的是更少的配置；

第二，我们针对不同的角色提供不同的解决方案。比如后端就直接使用可视化的方式，而针对前端来说，提供本地化开发的方案，因为不同的角色，不同的场景和角色对于平台的诉求是不一样的。

InfoQ：您觉得低代码开发平台有哪些安全隐患？针对这些隐患，WOLF 平台做了哪些事情呢？

安全隐患主要有两类：

第一类是针对开发用户的。由于低代码本身也是代码，代码本身是存在不确定性的，如果用户写的代码有死循环的话，容易造成机器宕机；

第二类是针对实际的使用用户的，这类的安全隐患除了传统的安全漏洞外，还有就是试用用户容易伪装成开发者对集团内部服务造成攻击。

下面我来说说针对以上两类安全隐患我们的措施：

针对第一类安全隐患，我们会给用户一个沙箱环境去执行用户的代码，而避免开发用户对平台造成攻击；

针对第二类安全隐患，在传统的安全漏洞方面，我们接入了集团公共的安全伞服务，能够检测包括 XSS、SQL 注入等各种常见的安全攻击；而针对使用用户伪装开发者的问题，我们将平台分成了开发端和预览端，开发端是给开发者使用的，预览端是给实际使用用户使用的，这两个端是物理隔离的，同时也是内外网隔离的，可以避免使用用户潜入到开发端进行危险操作；

另外，无论是针对开发用户还是实际使用用户，我们都对其操作的过程进行记录备份，能够进行攻击的溯源，这样完成安全的兜底。

站在风口的低代码，机遇与挑战共存

InfoQ：对于大家来说，低代码已经不是个新概念了，目前来看您认为低代码还存在哪些技术难点？

从我的经验来讲，技术难点倒并不是最主要的难点，因为一般有了想法和方案，技术是最容易实现的。

我个人认为低代码最主要的难点还是产品跟技术的鸿沟。因为低代码产品是一个重技术侧的产品，一般公司都是技术侧发起，而没有产品经理，这里面就存在一定的问题：

一般懂产品的人技术不太好，懂技术的人产品不太好，技术人更容易陷入技术的思维中去，觉得我可以给用户提供什么功能，但是很少去思考用户到底需要什么功能，所以导致很多低代码平台技术很厉害，但是并没有什么人用。

所以我觉得最大的难点还是产品思维，如何让技术人员有产品思维，这是所有技术产品目前遇到的最大的问题。

InfoQ：对于目前国内低代码的发展现状，您认为低代码的机遇和挑战各是什么呢？未来前景如何？

低代码的机遇是有目共睹的，由于互联网进入到下半场，更多企业的互联网化在线化，一方面招聘专业的 IT 人才成本较高，另一方面对于同质化较为严重的项目对于 IT 人才来说也是一种资源浪费，而低代码可以降低开发门槛，能够让更多的、没那么高水平开发技能的人参与到开发中来。

而说到挑战我觉得还是缺乏统一的标准。各个大厂有自己的解决方案，所以对于小公司来说，根本就不知道选择哪一种方案。类似小程序一样，各个公司都有小程序解决方案，导致开发者需要学习各种各样的开发模式，也不能开发一套在各种地方使用。而作为对比，浏览器就是最好的低代码例子，我们提供一种规范，各个厂商去按照这个规范实现自己的浏览器，这对开发者是无感知的。

总的来说，因为低代码面向的是开发者，所以我认为怎么站在开发者的角度去思考问题才是最大的挑战。

采访嘉宾：李勇，美团技术专家，曾在百度任职，负责贴吧智能版、PC 版的研发工作；目前在美团成都研发中心任职，主要负责基础框架和研发工具的开发，主导开发低代码平台 WOLF。对前端组件化、低代码领域有一定的研究和积累。

李勇老师将在ArchSummit 全球架构师峰会中结合自己的经验和大家分享美团低代码平台的底层设计与实现经验，希望能让对低代码感兴趣的同学有所收获，点击查看更多专题详情。