基于Web前端開(kāi)發(fā)在企業(yè)信息化應(yīng)用中的實(shí)踐

陳嘉霖，田力

（云南省能源投資集團(tuán)有限公司，云南 昆明 650021）

0 引言

隨著信息時(shí)代的到來(lái)，信息技術(shù)在整個(gè)數(shù)字經(jīng)濟(jì)發(fā)展中起到的作用越來(lái)越重要。近年各類(lèi)移動(dòng)應(yīng)用(APP)的創(chuàng)新升級(jí)越來(lái)越成為推動(dòng)數(shù)字經(jīng)濟(jì)發(fā)展的重要力量。國(guó)內(nèi)移動(dòng)APP種類(lèi)豐富，覆蓋生活各種場(chǎng)景，從購(gòu)物到本地生活服務(wù)，從共享單車(chē)到線上金融服務(wù)等。同時(shí)，在企業(yè)數(shù)字化轉(zhuǎn)型及產(chǎn)業(yè)數(shù)字化方面也出現(xiàn)很多移動(dòng)APP的身影，例如企業(yè)微信和釘釘?shù)?，在助力企業(yè)數(shù)字化轉(zhuǎn)型方面提供了很好的支撐。企業(yè)如何在原有信息化基礎(chǔ)上和資源范圍內(nèi)，面對(duì)企業(yè)業(yè)務(wù)的復(fù)雜多變，快速利用移動(dòng)APP相關(guān)技術(shù)架構(gòu)來(lái)支撐企業(yè)數(shù)字化轉(zhuǎn)型，成為各個(gè)企業(yè)需要面對(duì)的問(wèn)題。本文結(jié)合能投集團(tuán)信息化建設(shè)情況給出Web前端工程技術(shù)及架構(gòu)的具體實(shí)踐。

1 企業(yè)信息化策略分析

1.1 移動(dòng)APP開(kāi)發(fā)模式分析

2007年7月蘋(píng)果公司發(fā)布第一代iPhone，2008年9月谷歌公司發(fā)布第一款A(yù)ndroid手機(jī)—HTC G1，分別標(biāo)志著iOS平臺(tái)和Android平臺(tái)進(jìn)入大眾視野。隨著十年多的發(fā)展，雖然中間還有其他智能手機(jī)平臺(tái)，但最終市場(chǎng)認(rèn)可并形成穩(wěn)定生態(tài)的就只剩下iOS和Android。這意味著移動(dòng)開(kāi)發(fā)需要覆蓋兩大平臺(tái)，對(duì)應(yīng)采用java和Objective-C開(kāi)發(fā)語(yǔ)言來(lái)進(jìn)行開(kāi)發(fā)。原生開(kāi)發(fā)應(yīng)用(Native)可移植性較差，一款原生的APP需要使用兩種開(kāi)發(fā)語(yǔ)言來(lái)完成兩套同樣的邏輯和界面的開(kāi)發(fā)，對(duì)開(kāi)發(fā)團(tuán)隊(duì)提出了較高要求[1-2]。在此基礎(chǔ)上發(fā)展起來(lái)的混合應(yīng)用(Hybrid)開(kāi)發(fā)采用了結(jié)合原生應(yīng)用和Web開(kāi)發(fā)技術(shù)混合的方式，原生平臺(tái)提供一個(gè)容器架構(gòu)底層[3]，而Web H5專注于業(yè)務(wù)變化較快的部分，這種開(kāi)發(fā)方式具備原生開(kāi)發(fā)的設(shè)備控制能力又具備Web應(yīng)用開(kāi)發(fā)的快速，同時(shí)具有很好的跨平臺(tái)特性?，F(xiàn)階段隨著超級(jí)APP的出現(xiàn)，諸如支付寶、微信等，逐步出現(xiàn)了基于這些超級(jí)APP的擴(kuò)展類(lèi)小程序開(kāi)發(fā)，比如微信小程序、頭條小程序、支付寶小程序等，這些小程序能較好的實(shí)現(xiàn)快速部署及推廣，具備較好的移植性和部署能力，是業(yè)務(wù)開(kāi)展的有益補(bǔ)充[4]。

1.2 企業(yè)現(xiàn)有問(wèn)題分析

能投集團(tuán)作為云南省省屬企業(yè)，承擔(dān)著地方融資和投資平臺(tái)的責(zé)任。下屬公司業(yè)務(wù)多樣復(fù)雜，覆蓋發(fā)電、配電、化工、天然氣、鹽業(yè)、物流等行業(yè)，面臨多樣業(yè)務(wù)信息化的需要，信息化需要貼近各種不同的通用業(yè)務(wù)和專用業(yè)務(wù)情況來(lái)具體實(shí)現(xiàn)。 能投集團(tuán)企業(yè)信息化過(guò)程中已按照規(guī)劃開(kāi)發(fā)完成了數(shù)字能投APP，并實(shí)現(xiàn)了私有化部署。該APP作為企業(yè)信息化的移動(dòng)端入口，結(jié)合后端的云服務(wù)完成了集團(tuán)相關(guān)業(yè)務(wù)系統(tǒng)的集成和整合，包括集團(tuán)人力、合同、OA、審計(jì)、投資管理等業(yè)務(wù)辦公系統(tǒng)。基礎(chǔ)架構(gòu)如圖1所示。

圖1 數(shù)字能投框架

現(xiàn)階段來(lái)看，數(shù)字能投較好的支撐集團(tuán)的整體辦公。管理業(yè)務(wù)模塊按季度、按年變化都可以逐步采用原生開(kāi)發(fā)迭代的方式來(lái)滿足。但是集團(tuán)中心部室和下屬公司面臨業(yè)務(wù)復(fù)雜多變的情況，很多需求變化往往需要按月來(lái)進(jìn)行相應(yīng)并實(shí)現(xiàn)，如何快速的完成需求并支撐好企業(yè)的數(shù)字化轉(zhuǎn)型就成為亟待解決的問(wèn)題。同時(shí)，業(yè)務(wù)關(guān)聯(lián)合作公司較多，很多業(yè)務(wù)流程需要關(guān)聯(lián)合作公司共同參與，如何快速搭建跨端應(yīng)用來(lái)支撐業(yè)務(wù)也就成為企業(yè)產(chǎn)業(yè)數(shù)字化升級(jí)的關(guān)鍵。

2 企業(yè)信息化框架選擇及實(shí)踐

2.1 總體設(shè)計(jì)思路

能投集團(tuán)信息化開(kāi)發(fā)團(tuán)隊(duì)中原生開(kāi)發(fā)人員有限，主要工作精力基本都在原有數(shù)字能投的維護(hù)和迭代上。考慮團(tuán)隊(duì)的人員配置情況，為了滿足快速響應(yīng)需求并完成迭代開(kāi)發(fā)，考慮在原有架構(gòu)上采用混合開(kāi)發(fā)的Web開(kāi)發(fā)方式來(lái)完成，數(shù)字能投本身架構(gòu)上預(yù)留了Web接入的方式，一方面可以較快滿足業(yè)務(wù)需求，另一方面也可以達(dá)到在業(yè)務(wù)需求上快速試錯(cuò)的目的。同時(shí)，對(duì)于外部合作企業(yè)的業(yè)務(wù)需求，出于安全和管理考慮不建議這些合作公司直接安裝使用數(shù)字能投，而是考慮利用在超級(jí)APP中的小程序開(kāi)發(fā)來(lái)滿足同外部企業(yè)的業(yè)務(wù)開(kāi)展，可以快速滿足業(yè)務(wù)需求。

整個(gè)架構(gòu)的后端采用云服務(wù)架構(gòu)加微服務(wù)部署，微服務(wù)架構(gòu)能夠使得服務(wù)相對(duì)簡(jiǎn)單，容易開(kāi)發(fā)、理解和維護(hù)。同時(shí)，對(duì)開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)技術(shù)棧和技術(shù)細(xì)節(jié)可以不同，能較好的利用好整個(gè)團(tuán)隊(duì)的開(kāi)發(fā)能力。對(duì)應(yīng)不同的業(yè)務(wù)需求后續(xù)可以快速整合到一起，對(duì)升級(jí)和改造都有較大好處。對(duì)于前端部分，根據(jù)業(yè)務(wù)場(chǎng)景和現(xiàn)有數(shù)字能投應(yīng)用平臺(tái)功能，明確一套前端應(yīng)用開(kāi)發(fā)的基礎(chǔ)和框架，提升開(kāi)發(fā)效率。并在這個(gè)框架基礎(chǔ)上結(jié)合超級(jí)APP的開(kāi)發(fā)規(guī)范及要求等，明確通用集成整合方案，滿足前端的跨平臺(tái)開(kāi)發(fā)需求。

企業(yè)的信息化、數(shù)字化團(tuán)隊(duì)需要在已有資源基礎(chǔ)上最大化支撐企業(yè)信息化建設(shè)。此架構(gòu)對(duì)人力的需求較小，不會(huì)影響原有原生團(tuán)隊(duì)的成員以及現(xiàn)有數(shù)字能投的正常開(kāi)發(fā)迭代。當(dāng)需求確認(rèn)后能夠在框架范圍內(nèi)快速開(kāi)發(fā)應(yīng)用，能夠?qū)崿F(xiàn)多APP的快速發(fā)布。完全可以實(shí)現(xiàn)數(shù)字能投的主需求迭代和分支業(yè)務(wù)需求迭代分開(kāi)，各個(gè)需求迭代并行開(kāi)發(fā)，各個(gè)業(yè)務(wù)功能開(kāi)發(fā)完成后再集成到原有穩(wěn)定的數(shù)字能投版本中，最大化提升開(kāi)發(fā)團(tuán)隊(duì)效率。而且對(duì)于系統(tǒng)維護(hù)也非常方便，可以做到應(yīng)用熱更新及同步。同時(shí)，在后續(xù)下屬公司業(yè)務(wù)明確情況下，并需要獨(dú)立APP支撐的情況下，可以直接將前端業(yè)務(wù)拆分出來(lái)形成新的APP。

2.2 企業(yè)移動(dòng)Web前端框架選擇

通過(guò)上面總體設(shè)計(jì)思路可以看出，前端架構(gòu)需要較好的滿足單一開(kāi)發(fā)又多端部署的需求，既需要在前期能夠支持混合開(kāi)發(fā)的要求和多種小程序的開(kāi)發(fā)的要求，還可以在后期需要的時(shí)候完成APP開(kāi)發(fā)的要求。

目前主流的APP混合開(kāi)發(fā)技術(shù)主要有PhoneGap移動(dòng)開(kāi)發(fā)平臺(tái)(國(guó)外開(kāi)源移動(dòng)開(kāi)發(fā)平臺(tái)，以jQuery Mobile為主，提供較豐富原生插件)、ReactNative跨平臺(tái)類(lèi)原生開(kāi)發(fā)(Facebook開(kāi)源框架，虛擬DOM渲染，以React生態(tài)為主)和WeeX 跨平臺(tái)移動(dòng)開(kāi)發(fā)平臺(tái)(阿里巴巴高性能原生應(yīng)用的框架，渲染引擎與實(shí)現(xiàn)語(yǔ)法層分開(kāi)，支持Vue和Rax前端框架)等，相較而言ReactNative的生態(tài)最為完善，技術(shù)架構(gòu)也較為成熟，開(kāi)發(fā)跨平臺(tái)的混合應(yīng)用最為合適，但并沒(méi)有很好的支持國(guó)內(nèi)超級(jí)APP的小程序。

相對(duì)應(yīng)的，國(guó)內(nèi)一些開(kāi)源架構(gòu)較好的支撐了國(guó)內(nèi)小程序開(kāi)發(fā)，和移動(dòng)端混合開(kāi)發(fā)，能夠較好滿足需求。較為主流有京東凹凸實(shí)驗(yàn)室的2018年9月發(fā)布的開(kāi)放式跨端跨框架解決方案Taro，公開(kāi)版本1.x和2.x支持使用React等框架來(lái)開(kāi)發(fā)多端框架，而3.x版本開(kāi)始支持Vue/Nerv等框架；以及DCloud出品的使用Vue為技術(shù)棧的前端應(yīng)用框架uni-app，2018年7月開(kāi)放以來(lái)已經(jīng)迭代超過(guò)3個(gè)大的版本。兩者都能在自有框架結(jié)構(gòu)下，發(fā)布覆蓋移動(dòng)端APP和超級(jí)APP小程序端應(yīng)用，保證了一次編寫(xiě)能夠發(fā)布到多端平臺(tái)的高效能力。兩者都采用將各個(gè)底層平臺(tái)的常用接口封裝成了相對(duì)統(tǒng)一的API接口，使用統(tǒng)一的接口規(guī)范來(lái)進(jìn)行管理，同時(shí)也將常用組件進(jìn)行了封裝，保持了相對(duì)統(tǒng)一的組件規(guī)范性，最大化的提升前端開(kāi)發(fā)效能。另外，兩個(gè)平臺(tái)架構(gòu)都可以通過(guò)代碼混寫(xiě)或條件編譯的方式來(lái)使用各個(gè)不同平臺(tái)的獨(dú)立API或組件，從而可以獨(dú)立的針對(duì)單一平臺(tái)做各種定制開(kāi)發(fā)而不會(huì)影響跨平臺(tái)能力。而且兩個(gè)平臺(tái)框架都能無(wú)縫使用React和Vue社區(qū)生態(tài)圈相關(guān)開(kāi)源組件，可以說(shuō)保留了前端各種框架、工具、包的接入方式和使用可能，最大化的增加了靈活性。當(dāng)然兩者還是有一些區(qū)別，雖然Taro3.x版本開(kāi)始支持Vue框架，但生態(tài)資源和案例上看Taro更偏向React技術(shù)棧，uni-app更偏向Vue技術(shù)棧。目前看到的案例情況上，uni-app的跨端跨平臺(tái)應(yīng)用更多一些。兩個(gè)平臺(tái)都有官方出品的UI庫(kù)，UI庫(kù)的性能差別不大，多平臺(tái)端的使用上差別也較小，都支持其他UI庫(kù)的集成。Serverless開(kāi)發(fā)上來(lái)看，uni-app支持的廠家和模式更豐富，包括主流的阿里云、騰訊云等都支持。平臺(tái)的插件擴(kuò)展功能來(lái)看uni-app占優(yōu)，除了前端組價(jià)以外，對(duì)原生插件的支持也很好，對(duì)后續(xù)移動(dòng)端發(fā)布來(lái)說(shuō)提供較好的平臺(tái)支持。結(jié)合能投集團(tuán)現(xiàn)有技術(shù)棧情況和開(kāi)發(fā)團(tuán)隊(duì)情況，最終選擇了uni-app作為開(kāi)發(fā)框架。

2.3 應(yīng)用實(shí)踐

以下以能投集團(tuán)內(nèi)一個(gè)具體Web前端框架的具體應(yīng)用實(shí)踐進(jìn)行說(shuō)明。

能投集團(tuán)集控綜合樓配備有員工食堂，每天為集團(tuán)集控綜合樓內(nèi)部員工約500余人及外部合作人員100余人提供就餐服務(wù)。食堂每天提供有當(dāng)天的餐廳菜單和每天的餐廳餐食的監(jiān)測(cè)報(bào)告，但都為線下版本。具體場(chǎng)景為員工在就餐排隊(duì)過(guò)程中才能看到當(dāng)天張貼的紙質(zhì)菜單，而監(jiān)測(cè)報(bào)告也是采用張貼公告的方式對(duì)員工公開(kāi)，體驗(yàn)性相對(duì)不好。決定采用統(tǒng)一Web前端應(yīng)用程序來(lái)提供線上餐廳每日菜單查詢及每日餐食監(jiān)測(cè)報(bào)告公示功能，集團(tuán)內(nèi)部用戶可以直接通過(guò)數(shù)字能投進(jìn)行集成后查閱，而外部合作人員通過(guò)微信小程序進(jìn)行查閱。

餐廳現(xiàn)有已在使用的食堂管理系統(tǒng)，運(yùn)營(yíng)管理人員每周可以維護(hù)本周的菜單情況以及管理人員就餐情況，監(jiān)測(cè)報(bào)告沒(méi)有信息系統(tǒng)進(jìn)行維護(hù)。當(dāng)前系統(tǒng)采用前后端分離模式[5]，前端實(shí)現(xiàn)數(shù)據(jù)展示及交互功能，后端通過(guò)微服務(wù)方式為前端提供相關(guān)數(shù)據(jù)，前后端通過(guò)RESTful接口及標(biāo)準(zhǔn)進(jìn)行數(shù)據(jù)交換[6]。該架構(gòu)下開(kāi)發(fā)效率高，業(yè)務(wù)和服務(wù)共享，給整個(gè)系統(tǒng)開(kāi)發(fā)帶來(lái)了便利。模塊關(guān)系如圖2所示。

圖2 數(shù)字能投移動(dòng)應(yīng)用框架

架構(gòu)中采用微服務(wù)的方式將相關(guān)數(shù)據(jù)和資源對(duì)外提供服務(wù)，根據(jù)具體需求分析來(lái)看，對(duì)于菜單信息可以直接在原有系統(tǒng)上完成二次開(kāi)發(fā)實(shí)現(xiàn)數(shù)據(jù)查詢服務(wù)；對(duì)于用戶查詢權(quán)限通過(guò)原有系統(tǒng)上用戶中心的不同人員信息情況完成二次開(kāi)發(fā)實(shí)現(xiàn)權(quán)限服務(wù)；對(duì)于監(jiān)測(cè)報(bào)告信息通過(guò)在云存儲(chǔ)對(duì)象服務(wù)中新建腳本進(jìn)行對(duì)外提供服務(wù)，后續(xù)如果有更多后臺(tái)管理功能需要實(shí)現(xiàn)時(shí)可以將該服務(wù)抽離出來(lái)形成具體功能模塊。

前端模塊采用uni-app框架，該框架基Vue實(shí)現(xiàn)，采用MVVM架構(gòu)框架，MVVM全稱Model-View-ViewModel，由經(jīng)典的軟件架構(gòu)MVC衍生而來(lái)，模式中View不再與Model關(guān)聯(lián)，通過(guò)ViewModel的邏輯關(guān)聯(lián)保證數(shù)據(jù)更容易管理和使用，直接通過(guò)數(shù)據(jù)雙向綁定保證View和ViewModel數(shù)據(jù)一致。這樣的架構(gòu)能使數(shù)據(jù)和界面分離，達(dá)到軟件設(shè)計(jì)要求中的“高內(nèi)聚，低耦合”。結(jié)合webpack可以在uni-app框架中構(gòu)建完整的前端工程項(xiàng)目，可以按需求和項(xiàng)目大小來(lái)選擇不同的項(xiàng)目組織架構(gòu)，在本次簡(jiǎn)單項(xiàng)目上通過(guò)構(gòu)建單頁(yè)面路由模式即可滿足。而后續(xù)也可以根據(jù)項(xiàng)目情況增加專用路由模塊Vue Router及狀態(tài)管理模塊Vuex，進(jìn)而解決單頁(yè)面多路由和復(fù)雜單頁(yè)面的狀態(tài)流轉(zhuǎn)問(wèn)題[7]。集團(tuán)數(shù)字能投原有架構(gòu)中預(yù)留了接入Web應(yīng)用的功能，通過(guò)url地址后臺(tái)綁定及token驗(yàn)證機(jī)制，可以方便的把該應(yīng)用接入到數(shù)字能投APP中。對(duì)于微信小程序，需要在發(fā)布該應(yīng)用是進(jìn)行微信小程序的appid關(guān)聯(lián)綁定，并且按微信小程序登錄要求通過(guò)認(rèn)證相關(guān)API完成登錄驗(yàn)證，同時(shí)和后端微服務(wù)用戶中心完成用戶的認(rèn)證。uni-app框架抹去了各個(gè)平臺(tái)的移植工作，在前端編程完成后通過(guò)腳本和配置可以發(fā)布不同的跨平臺(tái)包，在這次應(yīng)用中只需要在發(fā)布H5包和微信小程序包之后進(jìn)行上述的配置后即可生產(chǎn)對(duì)應(yīng)的應(yīng)用程序[8-9]。可以說(shuō)是一次編寫(xiě)完成了多平臺(tái)的程序構(gòu)建，大大提升了開(kāi)發(fā)效率。數(shù)字能投端及微信端界面如圖3-4所示。

圖3 數(shù)字能投APP端應(yīng)用圖

采用統(tǒng)一框架的Web混合開(kāi)發(fā)，不影響原有開(kāi)發(fā)進(jìn)度，僅投入少量人力就快速上線了能投集團(tuán)集控綜合樓線上食堂查詢系統(tǒng)，解決了集團(tuán)內(nèi)外部就餐人員在不同APP終端中查詢食堂就餐信息的，成功將線下公告轉(zhuǎn)為線上無(wú)紙化查詢，降低了運(yùn)營(yíng)成本，提高了用戶體驗(yàn)感，進(jìn)一步完善了企業(yè)數(shù)字化轉(zhuǎn)型的場(chǎng)景應(yīng)用。

圖4 微信APP端應(yīng)用圖

3 結(jié)語(yǔ)

移動(dòng)互聯(lián)網(wǎng)的發(fā)展帶來(lái)兩大平臺(tái)的普及，而數(shù)字化進(jìn)程的不斷推進(jìn)必然帶來(lái)更多業(yè)務(wù)的線上化和云化。在這一過(guò)程中需要人工參與的業(yè)務(wù)過(guò)程必然帶來(lái)需要更多功能部署到APP端進(jìn)行體現(xiàn)，企業(yè)信息化過(guò)程中人力和資源的限制和持續(xù)增長(zhǎng)的需求必然是長(zhǎng)期存在的矛盾。通過(guò)一次編寫(xiě)來(lái)多端部署的開(kāi)發(fā)架構(gòu)能夠較好的緩解這一矛盾，而且也能更為快速的支持好業(yè)務(wù)的試錯(cuò)和發(fā)展，為企業(yè)的數(shù)字化轉(zhuǎn)型起到較好的支撐工作。