一、低代碼開發平臺不是快速開發平臺
1、 低代碼開發平臺定義
最近，阿里巴巴發佈了自己的低代碼開發平臺“宜搭”，網址是：https://www.aliwork.com ，關於低代碼開發平臺，我去年年底也寫過兩篇文章（https://www.toutiao.com/i6637188964732109315/），對低代碼開發進行了初步探討。關於低代碼開發的定義，百度百科是這麼寫的：低代碼開發平臺是無需編碼或通過少量代碼就可以快速生成應用程序的開發平臺。它的強大之處在於，允許終端用戶使用易於理解的可視化工具開發自己的應用程序，而不是傳統的編寫代碼方式。構建業務流程、邏輯和數據模型等所需的功能，必要時還可以添加自己的代碼。完成業務邏輯、功能構建後，即可一鍵交付應用並進行更新，自動跟蹤所有更改並處理數據庫腳本和部署流程，實現在 IOS，Android，Web 等多個平臺上的部署。
從該定義中我們也可以看到，低代碼開發有這麼幾個核心詞彙組成：
（1）面向終端用戶，即低代碼開發平臺的使用者是最終用戶或者是實施工程師，快速開發平臺的使用者還是程序員；
（2）可視化工具，即要有面向終端應用的程序界面生成器（不是快速開發平臺的應用生成器），如下圖所示：
圖一，應用界面生成器，該圖用excel4app.com生成
（圖一，該圖來自於excel4app.com）
（3）無需編碼或通過少量代碼
（4）在必要的時候，有添加自己的個性化代碼，完成業務邏輯的機制。
2、 快速開發平臺定義
百度百科上，快速開發平臺是這麼定義的：快速開發平臺，就是可以使得開發更爲快速的開發平臺。當開發平臺產生之後，雖然減少了編程人員大量的編程時間，但是很多開發平臺的效果並不是很理想，比如說某些開發平臺比較複雜、難以掌握；有的開發平臺通用性比較差；有的開發平臺在時間上並沒有得到改善；還有的依然還是需要寫很多代碼等等。這些問題的存在促使開發者不斷的摸索、不斷的改進，到最後越做越成熟，以致於現在市面上出現的大部分開發平臺效率都非常高，他們改善了以往的產品存在的缺陷，使得開發過程比以往更簡潔、編寫代碼更少、開發效率越來越高。
從定義中也可以看出，快速開發平臺是開發更爲快速的開發平臺。快速開發平臺強調的是開發速度快，使用者還只能是程序員，而低代碼開發平臺的使用者是最終用戶，目標不同，所以兩者的定位也差異極大。
3、 低代碼開發整體架構圖
低代碼開發平臺一般由以下幾個部分組成：
- 互動式界面生成器，如上圖一所示，最終用戶通過互動式界面生成器生成自己的應用，能夠完成簡單的增刪改查等基本操作。
- 界面渲染引擎，最終用戶用互動式界面生成器生成界面後，一般爲JSON格式，並保存到數據庫或者XML文件中，然後在最終用戶使用該功能時，再由JSON界面渲染引擎，把該界面實時渲染出來，無路是Vue、還是React，類似開源的JSON表單引擎有很多，阿里巴巴的宜搭，也是類似的思路。我爲啥並不推薦快速開發平臺呢，因爲前臺技術實在是變化太快了，每隔一兩年，前臺技術就會發生革命性變化，由傳統的JSP，發展到Struts，開始引入模板和MVC的概念，再發展到HTML+JQuery，同期還有ExtJS，再發展到現在的所謂的MVVM，前端技術的每次變化，都是對以前技術的推倒重來，而快速開發平臺是坐火箭+望遠鏡也趕不上前臺技術發展的，所以快速開發平臺往往只能是拿後臺的用戶、角色、權限、菜單來說事，而不能再像以前可以隨意生成JSP頁面那樣，快速生成Vue、React頁面了，因爲Vue、React相比較起JSP，實在是太複雜了，JSP是會HTML語法就可以，而Vue、React則是一個技術棧，上下游能牽扯到十幾種技術，而且這些技術之間，每個版本還需要仔細考量，最新的版本，往往還互相不兼容。
- 業務代碼編排引擎：雖然是低代碼開發平臺，但是稍微複雜的一些應用，比如，進銷存，還是需要大量代碼介入的，但是界面已經由最終用戶生成，如何把代碼插入到界面當中去？實際上，所有的BPM引擎或者OA工作流引擎，都是支持代碼插入的，但是現在所有的BPM引擎，包括國內知名公司的產品，都不是基於微服務架構或者Spring MVC/Spring Boot機制的，所有的代碼都用自己的方式藕合在一起，BPM就是一個無法拆分的單體應用，這還不是最可怕的，最可怕的是BPM的代碼插入機制，BPM允許插入的代碼，數據庫連接，與它的工作流引擎，是隔離開的，不在一個事務中。不在一個事務中最大的問題並不是插入數據失敗後不能同增同減這麼簡單，這只是一個已知的用戶可接受的問題，最大的問題還是這種機制會造成數據庫連接池的內存泄漏或者是數據庫連接池很快就用完了，造成系統每隔一段時間，系統就會變得異常緩慢。所以，如何把第三方代碼無縫的插入到界面當中去，不造成內存泄漏或者數據庫連接池泄漏，也是一個考驗架構師的技術活；
- 流程引擎。關於流程引擎，現在一般都是基於Activiti 進行二次開發，不過國內的BPM流程引擎，由於跟審批綁定得太緊，所以都有掛錶單的操作， BPM掛錶單，是把表單、流程、存儲三位一體，一個是這種方案，給以後微服務的拆分造成無法拆分的問題，自身又是一個單體應用，造成性能問題無法優化；其次，掛錶單，剛纔講了，前端技術變化太快，所以表單改爲Vue、React以後，也會造成原來的工作流引擎改動太大，最後就是不能改動。所以，如何用互聯網的思維，改動Activiti,適應微服務拆庫、拆表、前後端分離的改造，也是一個懸掛在架構師頭上的一個問題。不知道阿里巴巴的宜搭是如何解決這個問題的，我看宜搭也是有自己的工作流引擎的
- 報表生成器：國內做報表組件的公司也非常多，一般跟BI掛上鉤，顯示自己高大上，就跟國內一般不提自己是OA引擎，而說自己是BPM一樣（實際我看國內BPM的使用就是快速開發和解決審批流程的，與標榜的業務流程優化一毛錢關係也沒有）。國際知名BI廠商如TableU、國內也有FineReport等等，快速開發平臺也需要搭建自己的查詢、報表生成器，不過，這個與界面渲染引擎、業務代碼編排引擎比較起來，還算是比較成熟的技術。
- 與外界第三方系統的實時交互。使用低代碼開發平臺，一般不會開發ERP（當然SAP的ERP就是低代碼開發平臺的鼻祖和典範，但是他把實施搞的太複雜了，一點不比定製開發來的費用低）、MES等複雜應用，但是現在由於客戶生存環境也是越來越複雜，一個系統往往不能獨立存在，需要大量和其它第三方系統進行交互，所以，如何實時的與其它系統進行交互？這裏推薦兩種方式：
第一種：通過監控數據庫日誌，數據的任何變化，都通過數據庫日誌實時同步到Kafaka之類的MQ上，其它第三方應用通過訂閱的方式，並通過頻道隔離開，監控自己感興趣的數據，並實時做出反應就可以了；
第二種：通過編寫通用的SQL 轉API，最終用戶也可以通過界面拖拽方式，生成SQL，並通過引擎，把該SQL最終轉換爲微服務的API，供第三方調用