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