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