從銀行的全渠道建設(shè)說(shuō)起
全渠道建設(shè)被視為是商業(yè)銀行落實(shí)“以客戶(hù)為中心”的制勝關(guān)鍵戰(zhàn)略之一。近些年來(lái)，銀行的全渠道建設(shè)不斷擴(kuò)大并深化，從技術(shù)角度看，分為以下四個(gè)層面：第一個(gè)是在各類(lèi)用戶(hù)觸點(diǎn)的交互端層面，加強(qiáng)技術(shù)棧統(tǒng)一的建設(shè)，例如智慧網(wǎng)點(diǎn);第二個(gè)是在聚合各渠道的中樞層面，加強(qiáng)公共復(fù)用的能力與中心的建設(shè)，例如渠道中臺(tái);第三個(gè)是在整合前后端的整體系統(tǒng)層面，實(shí)現(xiàn)靈活優(yōu)化的跨端協(xié)同的場(chǎng)景創(chuàng)新的建設(shè)，例如云柜;第四個(gè)是在貫穿系統(tǒng)全生命周期的數(shù)字化轉(zhuǎn)型層面，形成領(lǐng)域構(gòu)建治理方法論以及使其得以落地的數(shù)字化平臺(tái)的建設(shè)，例如渠道旅程場(chǎng)景需求梳理方法論及其落地平臺(tái)。
在這些層面中，第一個(gè)層面，也就是在交互端加強(qiáng)技術(shù)棧統(tǒng)一的建設(shè)層面，往往是全渠道建設(shè)的首要切入層面，其建設(shè)的深度廣度，決定了其他三個(gè)層面建設(shè)的基本格局。
當(dāng)下，“大前端”概念被許多銀行提出。有的銀行，基于可信設(shè)備的角度，規(guī)劃將柜面、自助、網(wǎng)點(diǎn)PAD、內(nèi)部管理端、坐席、行員手機(jī)APP等渠道進(jìn)行統(tǒng)一建設(shè);也有的銀行，基于對(duì)客服務(wù)的角度，規(guī)劃將柜面、自助、網(wǎng)點(diǎn)PAD、網(wǎng)銀、手機(jī)銀行等渠道進(jìn)行統(tǒng)一建設(shè)。這些動(dòng)態(tài)，標(biāo)志著全渠道建設(shè)的第一層面，在過(guò)去基于網(wǎng)點(diǎn)場(chǎng)景的多渠道統(tǒng)一建設(shè)的基礎(chǔ)上，進(jìn)一步橫向擴(kuò)大，勢(shì)必在縱的方向引發(fā)為保障這一進(jìn)程順利發(fā)展而提供必要支撐的技術(shù)，迎接新一輪挑戰(zhàn)。
交互端技術(shù)關(guān)切點(diǎn)的不斷深入
如今各渠道的交互端技術(shù)已然是H5體系占據(jù)絕對(duì)主流，所采用的基礎(chǔ)前端框架大多是React和Vue，相關(guān)的技術(shù)建設(shè)在一開(kāi)始大多是面向行業(yè)特點(diǎn)場(chǎng)景應(yīng)用的組件庫(kù)與基礎(chǔ)SDK包的提取封裝完善，這是一項(xiàng)長(zhǎng)期任務(wù)。
雖然React和Vue仍然在持續(xù)發(fā)展，但SolidJS與Svelte已經(jīng)連續(xù)兩年占據(jù)StateOfJS滿(mǎn)意度(Would Use Again)排名前兩位，Svelte更是連續(xù)四年成為最想學(xué)習(xí)的前端框架排名首位。在渠道應(yīng)用場(chǎng)景越來(lái)越追求流暢體驗(yàn)的需求推動(dòng)下，像Svelte和SolidJS這種通過(guò)編譯形成更輕更快精準(zhǔn)刷新機(jī)制從而得以?huà)仐壉恐豓DOM的框架，將有可能成為取代React和Vue等基于VDOM技術(shù)框架的備選，值得嘗試探索。
同時(shí)，我們需要審視現(xiàn)有建成的組件庫(kù)進(jìn)行思考。現(xiàn)有組件庫(kù)本身的技術(shù)架構(gòu)是否做了標(biāo)準(zhǔn)與特色、交互與功能的分層?現(xiàn)有組件庫(kù)在面對(duì)基礎(chǔ)技術(shù)更新?lián)Q代時(shí)，可以多大程度快速繼承資產(chǎn)而避免繁冗的重復(fù)建設(shè)?是否需要引入Design System以及Component Story Format此類(lèi)的標(biāo)準(zhǔn)規(guī)范確保開(kāi)發(fā)用戶(hù)體驗(yàn)與操作用戶(hù)體驗(yàn)得以在不同組件框架間取得一致?
即使上述問(wèn)題得到輕松解答和有效應(yīng)對(duì)，在“大前端”趨勢(shì)推動(dòng)之下，讓更多團(tuán)隊(duì)加入共同建設(shè)并形成完全復(fù)刻的技術(shù)棧是難以實(shí)現(xiàn)且弊大于利的。因此，多種技術(shù)體系共存的統(tǒng)一層面，需要重新定位并將關(guān)切點(diǎn)向底層轉(zhuǎn)移，從完全統(tǒng)一變?yōu)橄鄬?duì)統(tǒng)一，從單一壟斷變?yōu)閲@主流的多樣共存。相應(yīng)的，我們看到，越來(lái)越多的銀行已經(jīng)或正在引入微前端框架，將中臺(tái)領(lǐng)域微服務(wù)架構(gòu)治理的諸多理念付諸于前端領(lǐng)域。“大前端”的“大”恰恰需要從“微前端”的“微”做起。
在引入微前端框架以后，許多曾經(jīng)高度依賴(lài)或綁定基座的渠道特色技術(shù)架構(gòu)，由于在緊貼瀏覽引擎這一層之上將極有可能統(tǒng)一插入微前端框架，勢(shì)必將引起過(guò)去通過(guò)Js-Bridge溝通UI層與原生層而實(shí)現(xiàn)的諸多機(jī)制不得不進(jìn)行新的一輪重構(gòu)改造。
借此之勢(shì)，基座方案何去何從的問(wèn)題也再度被擺了出來(lái)。
基座變革呼之欲出
基座在交互端技術(shù)棧中，作為包含有瀏覽引擎的系統(tǒng)級(jí)應(yīng)用程序，一般是瀏覽器程序或者是內(nèi)嵌chromium/webview瀏覽內(nèi)核并采用CEF、Electron或者Tauri等技術(shù)的基礎(chǔ)程序。
雖然交互端UI技術(shù)已幾乎統(tǒng)一為H5技術(shù)，但基座的選擇尚未統(tǒng)一為瀏覽器。當(dāng)下基座是否應(yīng)基于瀏覽器的權(quán)衡，是C/S與B/S對(duì)比考量的延伸。非瀏覽器基座相比瀏覽器基座具備更大的可塑性，在許多渠道應(yīng)用場(chǎng)景中，傳統(tǒng)瀏覽器技術(shù)難以滿(mǎn)足許多UI之外的能力要求，例如包括外設(shè)調(diào)用在內(nèi)的各種系統(tǒng)級(jí)原生操作，因此我們看到典型的柜面、自助等渠道，大多采用了內(nèi)嵌瀏覽內(nèi)核的非瀏覽器基座。
而隨著相關(guān)領(lǐng)域的發(fā)展，外設(shè)能力通過(guò)模塊實(shí)現(xiàn)轉(zhuǎn)化為服務(wù)實(shí)現(xiàn)，成為了外設(shè)服務(wù)，可以脫離基座運(yùn)行。更甚者，外設(shè)云，為支撐客戶(hù)業(yè)務(wù)旅程重塑的交割異步化，將外設(shè)能力從應(yīng)用程序的從屬定位，提升至了業(yè)務(wù)流程中的場(chǎng)景觸點(diǎn)級(jí)。這些變化，大幅削弱了基座繼續(xù)保留系統(tǒng)原生操作能力的必要，可以通過(guò)瀏覽器加外掛或者遠(yuǎn)程訪問(wèn)的方式，實(shí)現(xiàn)系統(tǒng)級(jí)原生操作能力。
對(duì)于傳統(tǒng)線(xiàn)下渠道進(jìn)行瀏覽器基座改造的探索在達(dá)到一定成熟度后，對(duì)于面向眾多不同建設(shè)階段銀行客戶(hù)的廠商一方，將來(lái)對(duì)于兩種基座的提供與支持依然有可能共存一段時(shí)間，并且也由于需要考慮移動(dòng)APP以及柜面移動(dòng)化形態(tài)的移動(dòng)App的共存共建，就需要將非瀏覽器基座進(jìn)一步做薄，使更多軟件資產(chǎn)在兩套體系中得到復(fù)用。
所以，對(duì)于基座瀏覽器化的技術(shù)工作內(nèi)容將會(huì)是對(duì)原有基座進(jìn)行庖丁解牛般的拆解和轉(zhuǎn)型，確保雙軌運(yùn)行期的效率成本最優(yōu)，落實(shí)在兩個(gè)方面，一個(gè)是轉(zhuǎn)型為插件型微前端框架之上的微應(yīng)用;另一個(gè)是轉(zhuǎn)型為功能性虛擬外設(shè)驅(qū)動(dòng)。此外，必要時(shí)，也需要對(duì)現(xiàn)有技術(shù)生態(tài)中一些主流微前端框架在加載能力及擴(kuò)展能力的局限方面進(jìn)行補(bǔ)充性完善。
超越頁(yè)面的應(yīng)用
在探索基座瀏覽器化的道路上，除了需要解決原生調(diào)用以及舊有底層依賴(lài)的問(wèn)題，還需要注意避免落入網(wǎng)頁(yè)開(kāi)發(fā)的思維局限。應(yīng)用是超越頁(yè)面的，體驗(yàn)優(yōu)先需要做到先執(zhí)行再聯(lián)網(wǎng)，而不是相反。
為了在瀏覽器化的同時(shí)不過(guò)多降低用戶(hù)體驗(yàn)，需要成體系地采用并實(shí)施PWA的相關(guān)技術(shù)，例如Service Worker等，補(bǔ)齊不依賴(lài)于頁(yè)面運(yùn)行的執(zhí)行能力和響應(yīng)能力，甚至需要在大型應(yīng)用系統(tǒng)中結(jié)合微前端框架，實(shí)現(xiàn)安全可控的發(fā)現(xiàn)式擴(kuò)展耦合，才可以較好地適應(yīng)行業(yè)領(lǐng)域特點(diǎn)的各種需求。
利用ServiceWorker技術(shù)，可以實(shí)現(xiàn)在本地應(yīng)用一側(cè)對(duì)遠(yuǎn)程服務(wù)資源進(jìn)行攔截管理的能力，更精細(xì)化資源緩存管理的能力，以及不依賴(lài)于用戶(hù)瀏覽網(wǎng)站的推送能力，通過(guò)這些能力，應(yīng)用系統(tǒng)可以實(shí)現(xiàn)更加高效的應(yīng)用加載，使應(yīng)用系統(tǒng)實(shí)時(shí)加載以及更新體驗(yàn)的流暢程度大大提升。
效率加速的Bundless趨勢(shì)
由于銀行渠道領(lǐng)域的應(yīng)用系統(tǒng)所承載的交易數(shù)量往往十分龐大，因此相關(guān)領(lǐng)域的應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)普遍都有過(guò)這樣的經(jīng)歷，工程剛剛初具規(guī)模就陷入編譯打包泥沼的窘境。
我們發(fā)現(xiàn)，大家對(duì)于這一問(wèn)題的解決方式大致是兩種路徑。一種是直接在技術(shù)層面解決，尤其是利用非瀏覽器基座所帶來(lái)的技術(shù)可控便利，實(shí)現(xiàn)文件級(jí)增量編譯打包和增量更新。另一種是在工程架構(gòu)層面進(jìn)行拆分解耦，以化整為零的方式回避大型應(yīng)用工程的出現(xiàn)。
單獨(dú)使用兩種方式都有其局限性，前者往往缺少了跨團(tuán)隊(duì)?wèi)?yīng)用拆分的方案提出，后者仍然無(wú)法解決大塊頭微前端在開(kāi)發(fā)中操作效率低下的問(wèn)題。兩種方法進(jìn)行結(jié)合可以實(shí)現(xiàn)取長(zhǎng)補(bǔ)短。
近些年來(lái)，Vite大受歡迎，究其本質(zhì)，秉承的正是第一類(lèi)解決方式的Bundless思想。Bundless意味著模塊組合任務(wù)由編譯打包時(shí)，轉(zhuǎn)移到了運(yùn)行時(shí)。具體的，Vite是通過(guò)其Vite Client模塊及現(xiàn)代瀏覽器對(duì)于ESM的支持能力聯(lián)合實(shí)現(xiàn)了運(yùn)行時(shí)模塊組合。但較為可惜的是，目前行業(yè)內(nèi)微前端框架大多選用的是乾坤，而其import-html-entry的沙箱能力尚未支持ESM，不能直接使用vite導(dǎo)出的微應(yīng)用，雖然也有方法將兩者銜接，但其本質(zhì)已是削足適履。
相似地，TurboPack也沿襲了Bundless思路，并大量采用Rust語(yǔ)言開(kāi)發(fā)出極小資源占用的高性能工具平臺(tái)，實(shí)現(xiàn)了號(hào)稱(chēng)700倍于Webpack的性能提升。也就是說(shuō)，用Webpack十幾分鐘干完的事情，用TurboPack只需要1秒鐘。此外，與Vite不同的是，TurboPack將模塊組合的責(zé)任從運(yùn)行時(shí)的瀏覽器端拿到了部署服務(wù)器，在部署時(shí)與下載時(shí)實(shí)現(xiàn)模塊組合，進(jìn)一步減輕瀏覽器壓力。然而，TurboPack當(dāng)前仍然處于Alpha階段，并未正式發(fā)布。
如果Bundless能夠逐漸成為主流趨勢(shì)，那么軟件體系的邊界固化也將從傳統(tǒng)的編譯打包時(shí)，延遲至部署時(shí)甚至是瀏覽時(shí)，這對(duì)于我們?cè)O(shè)計(jì)實(shí)現(xiàn)大型開(kāi)放式渠道應(yīng)用系統(tǒng)將會(huì)具有十分積極的意義。
關(guān)于作者
作者擁有銀行IT領(lǐng)域近20年行業(yè)經(jīng)驗(yàn)，現(xiàn)任贊同科技股份有限公司CTO;作者入行即從事工具平臺(tái)研發(fā)，支撐并推動(dòng)贊同科技在各線(xiàn)產(chǎn)品平臺(tái)形成規(guī)?；焖賾?yīng)用開(kāi)發(fā)配套工具體系，構(gòu)建關(guān)鍵競(jìng)爭(zhēng)力要素;作者主持研發(fā)的渠道系統(tǒng)前后端中間件平臺(tái)，順應(yīng)并支撐業(yè)務(wù)快速發(fā)展創(chuàng)新，在細(xì)分領(lǐng)域市場(chǎng)份額排名常年位居榜首;作者愿在立足技術(shù)面向業(yè)務(wù)的發(fā)展道路上，與同業(yè)共同探索更進(jìn)一步的價(jià)值創(chuàng)造。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。 ）
