实战Spring Cloud、Vue构建基于微服务的SaaS低代码开发平台2
一、低代码开发平台不是快速开发平台
1、 低代码开发平台定义
最近，阿里巴巴发布了自己的低代码开发平台“宜搭”，网址是：https://www.aliwork.com ，关于低代码开发平台，我去年年底也写过两篇文章（），对低代码开发进行了初步探讨。关于低代码开发的定义，百度百科是这么写的：低代码开发平台是无需编码或通过少量代码就可以快速生成应用程序的开发平台。它的强大之处在于，允许终端用户使用易于理解的可视化工具开发自己的应用程序，而不是传统的编写代码方式。构建业务流程、逻辑和数据模型等所需的功能，必要时还可以添加自己的代码。完成业务逻辑、功能构建后，即可一键交付应用并进行更新，自动跟踪所有更改并处理数据库脚本和部署流程，实现在 IOS，Android，Web 等多个平台上的部署。
从该定义中我们也可以看到，低代码开发有这么几个核心词汇组成：
（1）面向终端用户，即低代码开发平台的使用者是最终用户或者是实施工程师，快速开发平台的使用者还是程序员；
（2）可视化工具，即要有面向终端应用的程序界面生成器（不是快速开发平台的应用生成器），如下图所示：
图一，应用界面生成器，该图用excel4app.com生成
（3）无需编码或通过少量代码
（4）在必要的时候，有添加自己的个性化代码，完成业务逻辑的机制。
2、 快速开发平台定义
百度百科上，快速开发平台是这么定义的：快速开发平台，就是可以使得开发更为快速的开发平台。当开发平台产生之后，虽然减少了编程人员大量的编程时间，但是很多开发平台的效果并不是很理想，比如说某些开发平台比较复杂、难以掌握；有的开发平台通用性比较差；有的开发平台在时间上并没有得到改善；还有的依然还是需要写很多代码等等。这些问题的存在促使开发者不断的摸索、不断的改进，到最后越做越成熟，以致于现在市面上出现的大部分开发平台效率都非常高，他们改善了以往的产品存在的缺陷，使得开发过程比以往更简洁、编写代码更少、开发效率越来越高。
从定义中也可以看出，快速开发平台是开发更为快速的开发平台。快速开发平台强调的是开发速度快，使用者还只能是程序员，而低代码开发平台的使用者是最终用户，目标不同，所以两者的定位也差异极大。
3、 低代码开发整体架构图
低代码开发平台一般由以下几个部分组成：
（1） 互动式界面生成器，如上图一所示，最终用户通过互动式界面生成器生成自己的应用，能够完成简单的增删改查等基本操作。
（2） 界面渲染引擎，最终用户用互动式界面生成器生成界面后，一般为JSON格式，并保存到数据库或者XML文件中，然后在最终用户使用该功能时，再由JSON界面渲染引擎，把该界面实时渲染出来，无路是Vue、还是React，类似开源的JSON表单引擎有很多，阿里巴巴的宜搭，也是类似的思路。我为啥并不推荐快速开发平台呢，因为前台技术实在是变化太快了，每隔一两年，前台技术就会发生革命性变化，由传统的JSP，发展到Struts，开始引入模板和MVC的概念，再发展到HTML+JQuery，同期还有ExtJS，再发展到现在的所谓的MVVM，前端技术的每次变化，都是对以前技术的推倒重来，而快速开发平台是坐火箭+望远镜也赶不上前台技术发展的，所以快速开发平台往往只能是拿后台的用户、角色、权限、菜单来说事，而不能再像以前可以随意生成JSP页面那样，快速生成Vue、React页面了，因为Vue、React相比较起JSP，实在是太复杂了，JSP是会HTML语法就可以，而Vue、React则是一个技术栈，上下游能牵扯到十几种技术，而且这些技术之间，每个版本还需要仔细考量，最新的版本，往往还互相不兼容。
（3） 业务代码编排引擎：虽然是低代码开发平台，但是稍微复杂的一些应用，比如，进销存，还是需要大量代码介入的，但是界面已经由最终用户生成，如何把代码插入到界面当中去？实际上，所有的BPM引擎或者OA工作流引擎，都是支持代码插入的，但是现在所有的BPM引擎，包括国内知名公司的产品，都不是基于微服务架构或者Spring MVC/Spring Boot机制的，所有的代码都用自己的方式藕合在一起，BPM就是一个无法拆分的单体应用，这还不是最可怕的，最可怕的是BPM的代码插入机制，BPM允许插入的代码，数据库连接，与它的工作流引擎，是隔离开的，不在一个事务中。不在一个事务中最大的问题并不是插入数据失败后不能同增同减这么简单，这只是一个已知的用户可接受的问题，最大的问题还是这种机制会造成数据库连接池的内存泄漏或者是数据库连接池很快就用完了，造成系统每隔一段时间，系统就会变得异常缓慢。所以，如何把第三方代码无缝的插入到界面当中去，不造成内存泄漏或者数据库连接池泄漏，也是一个考验架构师的技术活；
（4） 流程引擎。关于流程引擎，现在一般都是基于Activiti 进行二次开发，不过国内的BPM流程引擎，由于跟审批绑定得太紧，所以都有挂表单的操作， BPM挂表单，是把表单、流程、存储三位一体，一个是这种方案，给以后微服务的拆分造成无法拆分的问题，自身又是一个单体应用，造成性能问题无法优化；其次，挂表单，刚才讲了，前端技术变化太快，所以表单改为Vue、React以后，也会造成原来的工作流引擎改动太大，最后就是不能改动。所以，如何用互联网的思维，改动Activiti,适应微服务拆库、拆表、前后端分离的改造，也是一个悬挂在架构师头上的一个问题。不知道阿里巴巴的宜搭是如何解决这个问题的，我看宜搭也是有自己的工作流引擎的
（5） 报表生成器：国内做报表组件的公司也非常多，一般跟BI挂上钩，显示自己高大上，就跟国内一般不提自己是OA引擎，而说自己是BPM一样（实际我看国内BPM的使用就是快速开发和解决审批流程的，与标榜的业务流程优化一毛钱关系也没有）。国际知名BI厂商如TableU、国内也有FineReport等等，快速开发平台也需要搭建自己的查询、报表生成器，不过，这个与界面渲染引擎、业务代码编排引擎比较起来，还算是比较成熟的技术。
（6） 与外界第三方系统的实时交互。使用低代码开发平台，一般不会开发ERP（当然SAP的ERP就是低代码开发平台的鼻祖和典范，但是他把实施搞的太复杂了，一点不比定制开发来的费用低）、MES等复杂应用，但是现在由于客户生存环境也是越来越复杂，一个系统往往不能独立存在，需要大量和其它第三方系统进行交互，所以，如何实时的与其它系统进行交互？这里推荐两种方式：
第一种：通过监控数据库日志，数据的任何变化，都通过数据库日志实时同步到Kafaka之类的MQ上，其它第三方应用通过订阅的方式，并通过频道隔离开，监控自己感兴趣的数据，并实时做出反应就可以了；
第二种：通过编写通用的SQL 转API，最终用户也可以通过界面拖拽方式，生成SQL，并通过引擎，把该SQL最终转换为微服务的API，供第三方调用