低代碼開發不靠譜？看低代碼開發在物聯網APP開發中的應用

摘要：雲編排式物聯APP開發平臺可經過雲端可視化編排開發，邊端遠程自動化部署，雲邊協同管理運維的方式，實現物聯網APP快速開發，海量邊端應用管理。

0 引言

當前，物聯網技術正在推進人類社會從「信息化」向「智能化」轉變，促進信息科技與產業發生巨大變化。但目前的實際狀況來看，物聯網的終端設備類型多、數量大，安裝運維成本高、工做量大，新業務、新功能擴展靠硬件盒子「堆砌」，不經濟，難管理，缺少靈活擴展性，邊緣的應用靠人肉現場開發和運維，爲物聯網的數字化發展造成桎梏。

物聯網服務經過各類各樣託管於物理設備，尤爲是智能傳感器上的業務應用程序APP，將物聯世界和數字世界緊密結合，實現物理世界的運行狀態感知。傳統的邊端物聯應用開發大都是基於文本語言編程，而邊端設備上的物聯應用開發和服務器應用開發的環境是徹底不一樣的，邊端設備種類複雜，計算能力差，數量多，應用部署和運維也是很是困難，須要開發人員有較高的技術水平和經驗，對硬件和軟件都要有比較深厚的理解。隨着低代碼開發技術日趨成熟，低代碼開發平臺無需編碼或少許編碼就能夠快速生成應用程序，具備可視化編程，簡單直觀，開發週期短，技術門檻低，易於部署和運維等特色。很是適合海量物聯終端的APP開發與管理。所以，華爲基於自家的APPCube低代碼開發平臺運營經驗，經過對業界前沿的低代碼開發技術的研究，結合物聯網自身固有的一些特色，開發出一種雲邊協同的雲編排式APP開發平臺，在雲端以可視化的流程編排開發APP，編排好的APP由雲端下發至邊端側的智能物聯設備進行部署和運維。實現物聯APP「一次開發，到處可用」，跨專業數據共享和業務流程貫通。推進物聯網數字化飛速發展。

1 相關背景技術

1.1 低代碼開發平臺發展趨勢

低代碼開發平臺（LCDP）是經過少許代碼就能夠快速生成應用程序的開發平臺。它提供終端用戶使用易於理解的可視化工具開發本身的應用程序，而不是傳統的編寫代碼方式。用戶能夠構建業務流程、邏輯和數據模型等所需的功能，必要時還能夠添加本身的代碼。完成業務邏輯、功能構建後，便可一鍵交付應用並進行更新，自動跟蹤全部更改並處理數據庫腳本和部署流程。低代碼開發平臺能夠爲不一樣硬件和操做系統開發並維護相對應的運行引擎，在平臺上生成的應用程序能夠運行在相應硬件的運行引擎之上，實如今主機、移動終端、物聯終端等多個平臺上的部署。

低代碼開發平臺(LCDP)最先可追溯到20世紀90年代至21世紀初的編程語言和工具，與先前的開發環境相似，早期低代碼開發平臺基於模型驅動，後期逐漸演進爲數據驅動，並建立了自動代碼生成和可視化編程的原理。

低代碼開發平臺一個顯著的特色是，使具備不一樣經驗⽔平的開發⼈員能夠經過圖形化的用戶界面，使用拖拽組件和模型驅動的邏輯來建立網頁和物聯終端應用程序。業務人員和IT部門的開發人員能夠共同建立、迭代、發佈，相比傳統開發模式能夠節省很多時間。對於大型企業來說，低代碼開發平臺還能夠下降IT團隊培訓、技術部署的初始成本。國外比較有名的低代碼開發平臺有：Kony、Mendix、Outsystems。國內比較成熟的低代碼開發平臺有iVX、AppCube等。

國內低代碼平臺尚處於早期，但市場需求將出現暴增。隨着國內政務和大企業紛紛選擇雲化轉型，基於雲化的低代碼開發平臺將成爲熱點。低代碼開發平臺和數據以及業務系統的集成能力變得愈來愈重要，客戶化開發會幫助行業軟件實現個性化需求的定製，軟件廠商與低代碼開發平臺合做能夠快速完成個性化需求的交付。低代碼開發下降了軟件開發的專業門檻，使得業務人員能夠根據本身的業務需求快速開發應用，人員數字化水平將大大提高。低代碼與物聯網的擴展鏈接成爲趨勢。快速鏈接硬件設備能夠幫助實現工業互聯網落地。

1.2 低代碼開發平臺的研究

1.2.1 Mendix

Mendix是專攻企業應用場景的低代碼開發平臺，通常是面向有開發團隊的中大型企業，提供模型驅動IDE和微流，使用拖放式組件和模型驅動邏輯來建立 Web 和移動應用，使業務人員能夠經過可視化組件參與到開發過程當中，與程序員在Mendix platform上合做開發本企業的應用。

Mendix提供的Mendix Studio 是基於 Web 的低代碼開發環境，專爲業務用戶打造。使用直觀的「所見即所得」頁面編輯器搭配 Atlas UI，設計並構建強大的應用。業務和 IT 部門的開發人員能夠在平臺中協同，建立、迭代和發佈應用，而所需時間只是傳統方法的一小部分。這種低代碼應用開發方法可針對不一樣用例開發各類類型的應用，包括將原有應用升級爲支持 IoT 的智能應用。它也提供一些企業解決方案、模板，開發平臺上也支持自定義UI和組件。擁有Atlas UI Framework開發框架，根據應用和業務類型，會推薦相關的模板和組件，達到快速開發的目的。內置DevOps功能，能夠持續交付，也可使用Mendix platform API集成其餘DevOps工具。

圖1：Mendix開發界面

1.2.2 Outsystems

OutSystems是一個低代碼平臺，提供面向企業開發、部署和管理全渠道企業應用程序的工具套件。基於該平臺開發的應用程序在雲、本地或混合環境中運行。用戶以國外大企業居多，外企接受度高。可拓展性強，支持智能硬件。多用來開發流程類應用，能夠實現全棧快速開發，支持從UX到後端集成的全部內容。大型應用程序端到端DevOps和生命週期管理。

OutSystems成立時間早，教學文檔豐富。可是由於技術是早期技術，IDE界面古老，操做不友好。想使用可視化組件下降代碼量，可是並無太好的作到可視化和coding的平衡，而是把coding的複雜程度轉移到了使用、調試組件的難度上，須要使用者進行大量額外的學習和練習。

平臺對代碼要求高，工具控件不夠豐富，不少很是基礎的功能須要複雜的操做才能完成，開發時前端部分的調試很是複雜，很是耗時。後臺服務也須要大量調用接口，對外的功能拓展依賴於Integration Studio等，可是兼容性不高，有時兼容Mysql都會出問題。

Outsystems可能也發現了本身的一些短板，爲了解決前端的問題，建設有UI庫，正在不斷完善中。可是由於技術架構的侷限性，仍是沒法解決不少經常使用可是基礎的問題，在試用中發現，例如，很簡單的彈窗提示、下拉菜單等，都須要經過寫js來實現。

圖2：Outsystems的用戶界面

1.2.3 iVX

iVX 是國內的可視化編程工具表明，是目前國內比較流行的 「0」代碼開發平臺，經過 iVX平臺的組件拖拽和事件配置便可快速完成各類應用開發，生成先後臺中間代碼，並可自動經過 VX 編譯系統，將中間代碼編譯成前端各系統目標應用(代碼)和後臺 Go 微服務代碼。iVX 大量使用到如下應用開發場景: WebApp開發，例如:公司內部OA/CRM/ERP/SAP等公司內部管理系統; WebSite開發，現有超過10萬+網站經過iVX平臺開發，包括前端展現和後臺數據功能; 小程序開發, 例如微信小程序自定義開發，非模板方式，更靈活自由；以及各類軟件相關係統和解決方案開發。

iVX 開發無需安裝開發包， 無需導入 SDK，便可徹底應對小程序、Web 應用、建站等複雜應用的開發，並可一站式完成後臺雲端部署，實現彈性虛機、數據庫、計算、網絡帶寬的彈性伸縮。

iVX 將常見應用場景劃分爲小程序、PC 應用與網站、展現類營銷、互動類營銷等四大場景，針對每一個場景提供更具針對性的開發模組。用戶能夠根據本身的需求，隨心選取合適的開發場景。系統將調取最合適的 開發環境，自動優化系統組件，爲用戶提供更爲便捷、溫馨的使用體驗。爲更好地適應多終端化的 Web 應用開發模式，iVX 採用了目前業內最 爲通行的 「先後端分離」 (Browser/Server)開發架構。該架構採用徹底獨立的先後端架構，兩者可以各司其職，後端主要負責提供服務和數據，前端則更專一於經過終端與用戶進行交互，從而下降服務器的壓力，將異常處理變得更爲友好，在開發難易度、數據安全性、產品效能等方面都有極大提高，更容易適應 大型應用、複雜應用的開發需求。iVX 在編譯器中提供了「前臺」、「後臺」兩個系統組件，將後端數據邏輯和前端交互系統徹底分開，支持前端架構的獨立搭建和後臺數據邏輯的獨立編寫，用戶無需編制先後端數據交互架構，只需藉助於系統組件便可實現先後端分離架構的部署。另外，後臺採用「服務調用」模式，不會直接暴露數據庫接口，更好保證後臺數據訪問安全性。VX採用了數據驅動的編輯邏輯。容許用戶經過創建數據模型，將後端數據或其餘數據賦予變量或數組，經過數據變量綁定的方式將 DOM 元素的屬性與數據結構作關聯，經過事件觸發數據變化，從而引起前端 DOM 元素的屬性變化。數據驅動的編輯邏輯容許用戶僅經過控制數據模型就能夠動態控制前端顯示效果，無需逐一修改前端組件，從而大幅提高效能，具備良好的可重用性，同時也大大減小「事件」編輯數量，提高開發效率。iVX 在前端開發環境中採用響應式佈局的開發理念，用戶不管使用何種尺寸的設備瀏覽頁面，都能得到良好的視覺效果。

圖3：iVX開發平臺用戶界面

1.2.4 AppCube

AppCube是咱們華爲雲發佈的一款雲端的低代碼開發平臺，中文名字叫應用魔方 ，顧名思義就如同魔方同樣，能夠經過任意組合，排列各類模塊化元素，建立功能各異的應用。AppCube提供雲上無碼化/低碼化/支持多碼化的應用開發模式，可以屏蔽編程技術複雜性，提高企業開發的效率。同時提供應用資產的開發標準和微服務框架，將企業IT化建設過程當中開發的可複用組件沉澱成可複製的模板套件，加速應用的定製，並能經過開放的生態，實現套件資產的商業變現。

AppCube從能力上來講具有一個應用端到端的開發能力。前端開發基於Vue技術棧，平臺預置豐富基礎組件，也能夠支持擴展，多用於表格表單等後端管理頁面的快速開發。開發界面上提供圖形化、無碼化在線頁面開發功能，可以快速構建各類複雜表單表格頁面、以及其餘一些靈活佈局頁面。開發人員能夠在開發界面中將組件面板上的頁面組件拖拽至頁面工做區域，並對組件的屬性、事件進行設置，再配合事件編排完成複雜的業務功能。支持開發人員以積木組裝的方式快速構建應用頁面，提高開發效率和質量，及時響應業務需求和價值實現； 後端開發能夠提供數據對象模型開發，對象能夠理解爲現實世界到數字世界的一個映射，開發者在平臺建立對象和對象的各類屬性字段以後，就能夠經過服務編排實現多個對象的可視化流程編排，以API的形式對外提供服務。簡單來講能夠將Script腳本、Action等封裝成對外提供的服務接口。服務編排編輯器提供了流程引擎的前臺頁面配置工具，經過模板化、圖形化實現對業務流程的編排和執行。幫助業務人員針對本身的獨特業務需求建立所需的解決方案，甚至不須要有任何編程經驗；開發者還能夠利用平臺提供的集成開發能力，經過消息、API等各類服務接口將不一樣的應用集成到一塊兒，或者與外部的其餘業務系統集成，造成一個完整的解決方案，而完成此項任務全都是基於圖形化界面來操做，不須要編寫代碼來。

AppCube的常見應用場景有輕應用構建場景，輕應用通常爲輕量級應用，不涉及複雜化的代碼，用戶零代碼（如拖曳組件，簡單配置）或者低代碼就能輕鬆完成應用的搭建。爲了下降企業用戶的應用開發成本，AppCube提供了豐富的輕應用模板，涵蓋了辦公管理、人事管理、項目管理，以及通用應用等領域多款精品模板，用戶可基於模板快速定製和擴展應用，知足自身業務的個性化訴求；另外一種是面向園區、城市、能源、教育、交通等行業的應用場景，可基於全場景的可視化開發能力、項目級協助共享能力和端到端的工程部署能力，快速搭建行業應用和大型企業級應用，行業內的技術積累能夠經過平臺沉澱下來，造成行業資產，行業內不一樣的用戶和廠商可經過一個資產市場來進行AppCube應用資產的共享，助力行業夥伴加速全場景行業數字化。

圖4：AppCube的用戶操做界面

2 雲編排式APP開發平臺

經過前面的低代碼開發平臺的研究，咱們發現目前業界商用的低代碼開發平臺大多數仍是面向移動端、web網頁應用開發，快速構建場景化應用，以及面向企業內部的業務流程管理的BPM平臺開發，用圖形化、可視化拖拽的模式描述業務需求，造成可視化業務邏輯設計。目前國內還缺少面向物聯網應用APP開發的低代碼開發平臺，而物聯網的應用APP大多數邏輯比較簡單，可重複使用代碼片斷多，複雜的是邊端APP的部署與管理，所以咱們基於自家的AppCube開發出了一種面向物聯網應用的雲編排式APP開發平臺，可在雲端進行可視化的APP編排式開發，並能從雲端部署APP到邊端設備的運行引擎上，實現物聯APP一次開發，到處運行。

2.1 傳統Native Code物聯APP開發方式面臨的問題

傳統邊側軟件開發部署目前面臨諸多問題，雲編排式APP開發平臺的目標是簡化端邊側應用的開發、部署的難度。目前邊側端側軟件開發部署具體常見問題以下：

1） 代碼開發門檻高，合適的開發人員少：因爲邊側、端側設備爲了完成特定業務場景，須要涉及周邊硬件的對接及處理是軟硬件結合的一個行業，不但要懂得軟件方面的編程，還要了解硬件包括電路、單片機、arm等相關知識。

2） 涉及平臺多，各類交叉編譯紛繁複雜：涉及的CPU 架構平臺，X8六、X86-6四、ARM 各類型號；涉及的指令集包括CISC、RISC、RISC-Five；涉及的操做系統更是繁多，例如windows 族、Linux 族等等。平臺、指令集、操做系統的多樣性不可避免的致使了複雜且易出錯的交叉編譯過程。

3） 須要現場逐臺設備部署應用：邊側、端側設備每每數量較多，開發完成的應用須要逐一現場手動安裝部署，耗時耗力。

4） 開發溝通成本高：一個完整的涉及端、邊的系統，既有端、邊側的邏輯，也有與雲端邏輯，缺乏統一的開發工具。

5） 採用硬編碼方式，開發效率低：目前大多數的邊、端側的應用採用C、C++硬編碼的方式開發，在部分資源較充裕的邊側設備或採用其它高級語言。

6） 功能模塊沒有快速複用機制：邊側設備上應用的開發每每是代碼級的複用，沒有功能模塊封裝規範、沒有模塊組合編排的工具，致使沒法方便快捷的複用既有代碼資產，形成了開發人力的浪費和長的開發週期。

7） 應用部署後即固化，沒法便捷的修改：傳統邊側、端側設備應用部署完畢後，任何功能上的修改都須要走完整的版本開發流程，沒有方便的邊雲協同的開發、部署機制。

2.2 雲編排式APP開發平臺概念

雲編排式APP開發平臺是專門針對物聯場景應用APP開發的低代碼開發平臺，提供邊側軟件可編程部署方案，以及邊、端、雲一體化協同編排方案，雲端編排的模型、流程、業務規則、頁面下發至邊側運行，邊側經過一個APP運行引擎來解釋執行雲端開發的APP流程，完成一個APP的業務功能。

雲編排式APP開發平臺系統提供了開放的流式編排開發框架，實現了業務的可視化編排式開發，經過新增編排節點的方式持續擴展可編排使用的能力，節點定義了標準規範並可由第三方開發，系統提供了基於服務化接口元數據的自動化節點生成工具、在線的半自動化開發工具。系統也提供了可編排節點、領域模型模板的管理組件，提供管理髮布流程、節點以及領域模型模板的倉庫，便於租戶內、租戶間的共享。

雲端編排的模型、流程、業務規則、頁面均以元數據的方式表述，由邊側、端側的引擎執行，執行引擎可運行於雲端高性能服務器、邊側資源受限服務器、端側單片機、嵌入式系統等。

雲/邊側部署系統分兩部分組成，二者之間能夠經過公網鏈接。

第一部分是位於雲端的開發平臺，開發者能夠在之上進行模型、流程、規則的編排，一切都是可視化的托拉拽方式開發，一些通用的邏輯功能能夠沉澱成平臺的可複用組件，好比處理網絡通訊的MQTT協議、485協議等等。邊、端側設備的提供商可在該環境上傳所提供設備的交叉編譯工具鏈，供平臺交叉編譯出對應設備的運行引擎下載使用。

第二部分是位於邊端的運行引擎，運行引擎能夠運行在雲端的服務器、邊側設備、端側單片機中，負責解釋執行雲端平臺下發的編排完成的流程元數據，流程執行過程可與外部系統或其它引擎中的流程交互，完成一個具體APP的業務功能。一個運行引擎能夠同時運行多個流程，也就是多個APP應用。雲端平臺能夠對引擎和其中的APP進行安裝、卸載、升級、配置更新等運維管理。

敲黑板，畫重點，這個運行引擎是這個該系統設計中的精華。咱們爲不一樣的硬件平臺適配運行引擎。而咱們編排好的APP是運行在引擎中，至關於微信小程序同樣，無論是什麼手機，只要裝了微信，就能下載安裝微信小程序。對於咱們的系統來講，無論是什麼硬件，只要裝了雲編排引擎，就能安裝雲編排的APP。從而實現了軟硬件解耦。物聯網的程序猿不再用爲了避免同的硬件交叉編譯流血流淚了。

2.3 雲編排式APP開發方式

雲編排APP開發方案提供邊、雲一體化協同編排方案，雲端編排的模型、流程、業務規則、頁面下發至邊側、端側運行。

雲編排APP雲端開發工具，經過鏈接線將各類功能模塊做爲黑盒鏈接在一塊兒，框架只起到消息數據的調度、轉換做用。這些「黑盒」是構建App的積木塊，它們之間傳遞的統一結構化的報文就是積木塊的插接口，經過最大化的直接複用或擴展複用「黑盒」節點構建應用，而非爲不一樣的APP從新構建新的「黑盒」節點。基於定製具備標準化的插接口的黑盒節點能夠無限擴展軟件系統功能。

這些「黑盒」節點經過標準規範描述，由第三方開發並知足規範的節點可在雲端開發工具中編排，並可在引擎中運行。同時雲編排系統提供基於服務化接口元數據的自動化節點生成工具、在線的半自動化開發工具。系統也提供可編排節點、領域模型模板的管理組件，提供管理髮布流程、節點以及領域模型模板的倉庫，便於租戶內、租戶間的共享。

雲端編排的模型、流程、業務規則、頁面均以元數據的方式表述，由端側、邊側的引擎執行，執行引擎可運行於雲端高性能服務器、邊側資源受限服務器、等。

雲端aPaaS環境提供拖拽式開發、測試、APP發佈審批功能。驗證審批後的APP可注入到各類設備部署的引擎中，並可對其進行運行狀態監控。高性能異步驅動運行引擎可對注入的APP元數據進行解析執行，完成目標業務邏輯。

在雲端能夠查看、暫停、重啓、更新業務APP。APP具備防篡改能力，保證APP的啓動安全、運行安全、升級安全。引擎和雲端系統經過雙向TLS證書認證，保證設計態環境和運行態引擎間的通信安全。APP運行時按照租戶進行隔離，保障同一引擎不一樣租戶APP相互影響、干擾。

2.4 傳統物聯APP開發模式與雲編排差別性對比

1） 不一樣點

1. 傳統開發模式須要熟悉硬件接口及其編程、配置方式，而邊雲協同方式下的開發只須要可視化選擇相應的硬件封裝節點及節點的外部通信接口。
2. 傳統開發模式須要瞭解在某個OS下外部接口協議的驅動及驅動使用方式。而邊雲協同方式下的開發只須要拖拽相應節點並完成配置便可。
3. 傳統開發模式須要開發者自行搭建開發環境，完成開發環境的配置，通常比較繁瑣。而邊雲協同方式下的開發，只須要登陸系統，點擊建立工程，系統後臺便可自動完成開發、測試環境的構建。
4. 傳統開發模式經過hard coding 的方式手工完成代碼的編寫，自動、或手動完成完整覆蓋的代碼測試用例驗證。而邊雲協同方式下的開發方式，基於大顆粒的功能模塊的複用，只須要拖拽節點完成邏輯的編排，大幅度提高了開發效率，可複用模塊（節點）在發佈時已經經過了嚴格的驗證測試，測試過程僅需關注編排流程自己。
5. 傳統開發模式須要針對不一樣的硬件、操做系統作交叉編譯，以實現一份代碼運行在不一樣的軟、硬件平臺上。而邊雲協同方式下的開發的是元數據和腳本，經過執行元數據和腳本的引擎屏蔽了軟、硬件平臺的差別性，避免了APP的交叉編譯。
6. 傳統開發模式開發完成的APP須要打包，導入到硬件環境中，執行參數配置完成安裝。而邊雲協同方式下的開發僅須要選中目標引擎，點擊下發APP便可完成安裝。

2） 相同點

1. 兩種方式開發出來的APP功能都是同樣的，都能實現物聯網應用業務的邏輯處理，性能上也都相近，知足物聯網業務的性能要求。
2. 雲編排APP開發平臺的運行引擎只是做爲普通APP部署，不改變原有邊側APP部署形態，對原有硬件系統沒有特殊要求。

3 結語

雲編排式APP開發做爲面向將來物聯網短平快業務場景的低代碼開發趨勢的表明性技術，爲物聯網應用APP的敏捷開發提供了一條便捷的途經。本文經過研究雲編排式APP開發平臺的基本理論和技術實現，展現了雲編排式APP開發在物聯APP應用開發的廣闊前景。

經過對雲編排式APP開發的實踐分析，咱們可以看到它能爲咱們帶來多種效益的提高。從管理效益上來講，它提高了物聯APP管理便捷性，加強管理體驗，甲方不用再依賴各個設備廠商和軟件廠商來幫他開發物聯，業務人員本身均可以上手，由於這太太太方便了。使能業務部門聚焦應用，技術開發歸口管理，應用開發安全可靠。採用統一平臺管控，簡化APP應用管理複雜性。APP應用開發過程統一可控，組件高複用提高可靠，下降多頭私有開發、代碼質量良莠不齊帶來的安全風險。

從經濟效益上來講，雲編排式APP開發下降了物聯APP應用開發門檻，從專業級代碼開發向普通業務人員可視化業務編排，從以月/周爲單位的開發週期縮短至以天爲單位，提高業務響應速度，及時保障業務發展。軟硬件解耦，組件一次開發，屢次使用，APP跨硬件平臺部署，提高開發資源利用率，優化建設成本。提高APP運維效率和成功率，下降運維專業化技術門檻。

從社會效益上來講，雲編排式APP開發提高了物聯APP應用生態夥伴總體技術水平，優化生態夥伴的分工協做關係，實現設備、業務組件、APP應用等生態資源更專業更精細分工，爲生態合做發展奠基基礎。

點擊關注，第一時間瞭解華爲雲新鮮技術~