低代碼開發不靠譜？ 看低代碼開發在物聯網APP開發中的應用
摘要：雲編排式物聯APP開發平臺可通過雲端可視化編排開發，邊端遠端自動化部署，雲邊協同管理運維的方式，實現物聯網APP快速開發，海量邊端應用管理。
0 引言
當前，物聯網技術正在推動人類社會從「訊息化」向「智慧化」轉變，促進訊息科技與產業發生巨大變化。 但目前的實際情況來看，物聯網的終端設備類型多、數量大，安裝運維成本高、工作量大，新業務、新功能擴展靠硬體盒子"堆砌"，不經濟，難管理，缺乏靈活擴展性，邊緣的應用靠人肉現場開發和運維，為物聯網的數位化發展形成桎梏。
物聯網服務通過各種各樣託管於物理設備，尤其是智慧感測器上的業務應用程式APP，將物聯世界和數位世界緊密結合，實現物理世界的運行狀態感知。 傳統的邊端物聯應用開發大都是基於文本語言程式設計，而邊端設備上的物聯應用開發和伺服器應用開發的環境是完全不同的，邊端設備種類複雜，計算能力差，數量多，應用部署和運維也是非常困難，需要開發人員有較高的技術水平和經驗，對硬體和軟體都要有比較深厚的理解。 隨著低代碼開發技術日趨成熟，低代碼開發平臺無需編碼或少量編碼就可以快速生成應用程式，具有可視化程式設計，簡單直觀，開發週期短，技術門檻低，易於部署和運維等特點。 非常適合海量物聯終端的APP開發與管理。 因此，華為基於自家的APPCube低代碼開發平臺運營經驗，通過對業界前沿的低代碼開發技術的研究，結合物聯網自身固有的一些特點，開發出一種雲邊協同的雲編排式APP開發平臺，在雲端以可視化的流程編排開發APP，編排好的APP由雲端下發至邊端側的智慧物聯設備進行部署和運維。 實現物聯APP"一次開發，處處可用"，跨專業數據共享和業務流程貫通。 推動物聯網數位化飛速發展。
1 相關背景技術
1.1 低代碼開發平臺發展趨勢
低代碼開發平臺（LHubSpot）是通過少量代碼就可以快速生成應用程式的開發平臺。 它提供終端使用者使用易於理解的可視化工具開發自己的應用程式，而不是傳統的編寫代碼方式。 用戶可以構建業務流程、邏輯和數據模型等所需的功能，必要時還可以添加自己的代碼。 完成業務邏輯、功能構建后，即可一鍵交付應用並進行更新，自動跟蹤所有更改並處理資料庫腳本和部署流程。 低代碼開發平臺可以為不同硬體和操作系統開發並維護相對應的運行引擎，在平臺上生成的應用程式可以運行在相應硬體的運行引擎之上，實現在主機、移動終端、物聯終端等多個平臺上的部署。
低代碼開發平臺（LHubSpot）最早可追溯到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.2.2 Outsystems
OutSystems是一個低代碼平臺，提供面向企業開發、部署和管理全渠道企業應用程式的工具套件。 基於該平台開發的應用程式在雲、本地或混合環境中運行。 使用者以國外大企業居多，外企接受度高。 可拓展性強，支援智能硬體。 多用來開發流程類應用，可以實現全棧快速開發，支援從UX到後端集成的所有內容。 大型應用程式端到端DevOps和生命週期管理。
OutSystems成立時間早，教學文檔豐富。 但是因為技術是早期技術，IDE介面古老，操作不友好。 想使用可視化元件降低代碼量，但是並沒有太好的做到可視化和coding的平衡，而是把coding的複雜程度轉移到了使用、調試元件的難度上，需要消費者進行大量額外的學習和練習。
平台對代碼要求高，工具控件不夠豐富，很多非常基礎的功能需要複雜的操作才能完成，開發時前端部分的調試非常複雜，非常耗時。 後台服務也需要大量調用介面，對外的功能拓展依賴於Integration Studio等，但是相容性不高，有時相容Mysql都會出問題。
Outsystems可能也發現了自己的一些短板，為了解決前端的問題，建設有UI庫，正在不斷完善中。 但是因為技術架構的局限性，還是無法解決很多常用但是基礎的問題，在試用中發現，例如，很簡單的彈窗提示、下拉功能表等，都需要通過寫js來實現。
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 在前端開發環境中採用回應式佈局的開發理念，用戶無論使用何種尺寸的設備瀏覽頁面，都能獲得良好的視覺效果。
1.2.4 AppCube
AppCube是我們華為雲發佈的一款雲端的低代碼開發平臺，中文名字叫應用魔方 ，顧名思義就如同魔方一樣，可以通過任意組合，排列各種模組化元素，創建功能各異的應用。 AppCube提供雲上無碼化/低碼化/支援多碼化的應用開發模式，能夠遮罩程式設計技術複雜性，提升企業開發的效率。 同時提供應用資產的開發標準和微服務框架，將企業IT化建設過程中開發的可複用元件沉澱成可複製的範本套件，加速應用的定製，並能通過開放的生態，實現套件資產的商業變現。
AppCube從能力上來說具備一個應用端到端的開發能力。 前端開發基於Vue技術棧，平臺預置豐富基礎元件，也可以支援擴展，多用於表格表單等後端管理頁面的快速開發。 開發介面上提供圖形化、無碼化在線頁面開發功能，能夠快速構建各種複雜表單表格頁面、以及其他一些靈活佈局頁面。 開發人員可以在開發介面中將元件面板上的頁面元件拖拽至頁面工作區域，並對元件的屬性、事件進行設置，再配合事件編排完成複雜的業務功能。 支持開發人員以積木組裝的方式快速構建應用頁面，提升開發效率和品質，及時回應業務需求和價值實現; 後端開發可以提供數據物件模型開發，物件可以理解為現實世界到數位世界的一個映射，開發者在平臺創建物件和物件的各種屬性欄位之後，就可以通過服務編排實現多個物件的可視化流程編排，以API的形式對外提供服務。 簡單來說可以將Script腳本、Action等封裝成對外提供的服務介面。 服務編排編輯器提供了流程引擎的前臺頁面配置工具，通過範本化、圖形化實現對業務流程的編排和執行。 幫助業務人員針對自己的獨特業務需求創建所需的解決方案，甚至不需要有任何程式設計經驗;開發者還可以利用平臺提供的集成開發能力，通過消息、API等各種服務介面將不同的應用集成到一起，或者與外部的其他業務系統集成，形成一個完整的解決方案，而完成此項任務全都是基於圖形化介面來操作，不需要編寫代碼來。
AppCube的常見應用場景有輕應用構建場景，輕應用一般為羽量級應用，不涉及複雜化的代碼，使用者零代碼（如拖曳元件，簡單配置）或者低代碼就能輕鬆完成應用的搭建。 為了降低企業使用者的應用開發成本，AppCube提供了豐富的輕應用範本，涵蓋了辦公管理、人事管理、專案管理，以及通用應用等領域多款精品範本，用戶可基於範本快速定製和擴展應用，滿足自身業務的個人化訴求;另一種是面向園區、城市、能源、教育、交通等行業的應用場景，可基於全場景的可視化開發能力、專案級協助共用能力和端到端的工程部署能力， 快速搭建行業應用和大型企業級應用，行業內的技術積累可以通過平臺沉澱下來，形成行業資產，行業內不同的使用者和廠商可通過一個資產市場來進行AppCube應用資產的共用，助力行業夥伴加速全場景行業數位化。
2 雲編排式APP開發平臺
通過前面的低代碼開發平臺的研究，我們發現目前業界商用的低代碼開發平臺大多數還是面向移動端、web網頁應用開發，快速構建場景化應用，以及面向企業內部的業務流程管理的BPM平台開發，用圖形化、可視化拖拽的模式描述業務需求，形成可視化業務邏輯設計。 目前國內還缺乏面向物聯網應用APP開發的低代碼開發平臺，而物聯網的應用APP大多數邏輯比較簡單，可重複使用代碼片段多，複雜的是邊端APP的部署與管理，因此我們基於自家的AppCube開發出了一種面向物聯網應用的雲編排式APP開發平臺，可在雲端進行可視化的APP編排式開發，並能從雲端部署APP到邊端設備的運行引擎上， 實現物聯APP一次開發，處處運行。
2.1 傳統Native Code物聯APP開發方式面臨的問題
傳統邊側軟體開發部署目前面臨諸多問題，雲編排式APP開發平臺的目標是簡化端邊側應用的開發、部署的難度。 目前邊側端側軟體開發部署具體常見問題如下：
1） 代碼開發門檻高，合適的開發人員少：由於邊側、端側設備為了完成特定業務場景，需要涉及周邊硬體的對接及處理是軟硬體結合的一個行業，不但要懂得軟體方面的程式設計，還要了解硬體包括電路、單片機、arm等相關知識。
2） 涉及平臺多，各種交叉編譯紛繁複雜：涉及的CPU架構平臺，X86、X86-64、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應用等生態資源更專業更精細分工，為生態合作發展奠定基礎。
