企业级低代码开发平台-架构规划和实践思考

今天再写一篇文章，谈下最近进行低代码开发平台产品架构设计和研发实践过程中的一些关键点的思考。在前面写过的关于低代码开发平台的文章中，基本已经将平台本身的核心架构和建模思路表达清楚，在这里不再重复叙述。

前两天我准备华南CIO大会关于从数字化转型到云原生的主题演讲材料，里面一篇材料涉及到低代码开发平台。

在这页PPT里面继续强调我们实际做的是面向企业的低代码开发平台而非零代码开发平台，特别是在规则引擎方面的技术没有得到实质性突破的时候，软件研发没有银弹，复杂规则仍然需要自己开发。也就是整个平台更多是参考类似Mendix的架构设计思路进行。

在云原生里面有一个核心技术实践即ServerLess无服务器架构，该架构将应用的开发分为了BaaS后端即服务和FaaS函数即服务两层，并提出一个核心思路就是在BaaS服务积累得足够好的时候，你开发应用更多仅仅是前端函数或脚本的编写，和对后端BaaS提供的API服务接口能力的组装。

这个思路本身就是低代码开发，是云原生实践下推荐的一种低代码开发的思路。

其次任何一个应用系统应该考虑解耦，微服务化，包括和底层技术平台的云化，那么低代码开发平台本身也应该是微服务架构，遵从基本的分层架构原则。低代码平台本身就应该分布式，可弹性扩展，这也是开发出高可用高性能的应用的基础。

如果一个企业只是想快速开发一个类似周报填写，考勤记录的简单应用，那么当前主流的低代码SaaS服务平台基本都能满足需求而且可以做到完全的零代码化。但是如果你是要开发一个类似企业内部的业务系统，这个系统可能上万人使用，上千的秒级并发量，即使是一个简单的OA系统也不是一般的低代码平台能搞定的事情。

所以你做一个低代码开发平台，不要将重心仅仅放在可视化表单设计，可视化流程设计，拖拽式的配置层面，这些虽然很重要，但是对于企业级的低代码平台来说不是重点，底层技术架构本身的高可靠，可扩展才是重点。

再次，企业本身又遗留IT系统，这个时候低代码开发平台如何切入？如何确保低代码开发平台开发完成的应用能够和已有的IT业务系统很好地融合和集成？

当前很多低代码开发平台都没有考虑这个问题点，更多开发的都是一个个独立的信息孤岛，而无法