从银行的全渠道建设说起

全渠道建设被视为是商业银行落实“以客户为中心”的制胜关键战略之一。近些年来，银行的全渠道建设不断扩大并深化，从技术角度看，分为以下四个层面：第一个是在各类用户触点的交互端层面，加强技术栈统一的建设，例如智慧网点;第二个是在聚合各渠道的中枢层面，加强公共复用的能力与中心的建设，例如渠道中台;第三个是在整合前后端的整体系统层面，实现灵活优化的跨端协同的场景创新的建设，例如云柜;第四个是在贯穿系统全生命周期的数字化转型层面，形成领域构建治理方法论以及使其得以落地的数字化平台的建设，例如渠道旅程场景需求梳理方法论及其落地平台。

在这些层面中，第一个层面，也就是在交互端加强技术栈统一的建设层面，往往是全渠道建设的首要切入层面，其建设的深度广度，决定了其他三个层面建设的基本格局。

当下，“大前端”概念被许多银行提出。有的银行，基于可信设备的角度，规划将柜面、自助、网点PAD、内部管理端、坐席、行员手机APP等渠道进行统一建设;也有的银行，基于对客服务的角度，规划将柜面、自助、网点PAD、网银、手机银行等渠道进行统一建设。这些动态，标志着全渠道建设的第一层面，在过去基于网点场景的多渠道统一建设的基础上，进一步横向扩大，势必在纵的方向引发为保障这一进程顺利发展而提供必要支撑的技术，迎接新一轮挑战。

交互端技术关切点的不断深入

如今各渠道的交互端技术已然是H5体系占据绝对主流，所采用的基础前端框架大多是React和Vue，相关的技术建设在一开始大多是面向行业特点场景应用的组件库与基础SDK包的提取封装完善，这是一项长期任务。

虽然React和Vue仍然在持续发展，但SolidJS与Svelte已经连续两年占据StateOfJS满意度(Would Use Again)排名前两位，Svelte更是连续四年成为最想学习的前端框架排名首位。在渠道应用场景越来越追求流畅体验的需求推动下，像Svelte和SolidJS这种通过编译形成更轻更快精准刷新机制从而得以抛弃笨重VDOM的框架，将有可能成为取代React和Vue等基于VDOM技术框架的备选，值得尝试探索。

同时，我们需要审视现有建成的组件库进行思考。现有组件库本身的技术架构是否做了标准与特色、交互与功能的分层?现有组件库在面对基础技术更新换代时，可以多大程度快速继承资产而避免繁冗的重复建设?是否需要引入Design System以及Component Story Format此类的标准规范确保开发用户体验与操作用户体验得以在不同组件框架间取得一致?

即使上述问题得到轻松解答和有效应对，在“大前端”趋势推动之下，让更多团队加入共同建设并形成完全复刻的技术栈是难以实现且弊大于利的。因此，多种技术体系共存的统一层面，需要重新定位并将关切点向底层转移，从完全统一变为相对统一，从单一垄断变为围绕主流的多样共存。相应的，我们看到，越来越多的银行已经或正在引入微前端框架，将中台领域微服务架构治理的诸多理念付诸于前端领域。“大前端”的“大”恰恰需要从“微前端”的“微”做起。

在引入微前端框架以后，许多曾经高度依赖或绑定基座的渠道特色技术架构，由于在紧贴浏览引擎这一层之上将极有可能统一插入微前端框架，势必将引起过去通过Js-Bridge沟通UI层与原生层而实现的诸多机制不得不进行新的一轮重构改造。

借此之势，基座方案何去何从的问题也再度被摆了出来。

基座变革呼之欲出

基座在交互端技术栈中，作为包含有浏览引擎的系统级应用程序，一般是浏览器程序或者是内嵌chromium/webview浏览内核并采用CEF、Electron或者Tauri等技术的基础程序。

虽然交互端UI技术已几乎统一为H5技术，但基座的选择尚未统一为浏览器。当下基座是否应基于浏览器的权衡，是C/S与B/S对比考量的延伸。非浏览器基座相比浏览器基座具备更大的可塑性，在许多渠道应用场景中，传统浏览器技术难以满足许多UI之外的能力要求，例如包括外设调用在内的各种系统级原生操作，因此我们看到典型的柜面、自助等渠道，大多采用了内嵌浏览内核的非浏览器基座。

而随着相关领域的发展，外设能力通过模块实现转化为服务实现，成为了外设服务，可以脱离基座运行。更甚者，外设云，为支撑客户业务旅程重塑的交割异步化，将外设能力从应用程序的从属定位，提升至了业务流程中的场景触点级。这些变化，大幅削弱了基座继续保留系统原生操作能力的必要，可以通过浏览器加外挂或者远程访问的方式，实现系统级原生操作能力。

对于传统线下渠道进行浏览器基座改造的探索在达到一定成熟度后，对于面向众多不同建设阶段银行客户的厂商一方，将来对于两种基座的提供与支持依然有可能共存一段时间，并且也由于需要考虑移动APP以及柜面移动化形态的移动App的共存共建，就需要将非浏览器基座进一步做薄，使更多软件资产在两套体系中得到复用。

所以，对于基座浏览器化的技术工作内容将会是对原有基座进行庖丁解牛般的拆解和转型，确保双轨运行期的效率成本最优，落实在两个方面，一个是转型为插件型微前端框架之上的微应用;另一个是转型为功能性虚拟外设驱动。此外，必要时，也需要对现有技术生态中一些主流微前端框架在加载能力及扩展能力的局限方面进行补充性完善。

超越页面的应用

在探索基座浏览器化的道路上，除了需要解决原生调用以及旧有底层依赖的问题，还需要注意避免落入网页开发的思维局限。应用是超越页面的，体验优先需要做到先执行再联网，而不是相反。

为了在浏览器化的同时不过多降低用户体验，需要成体系地采用并实施PWA的相关技术，例如Service Worker等，补齐不依赖于页面运行的执行能力和响应能力，甚至需要在大型应用系统中结合微前端框架，实现安全可控的发现式扩展耦合，才可以较好地适应行业领域特点的各种需求。

利用ServiceWorker技术，可以实现在本地应用一侧对远程服务资源进行拦截管理的能力，更精细化资源缓存管理的能力，以及不依赖于用户浏览网站的推送能力，通过这些能力，应用系统可以实现更加高效的应用加载，使应用系统实时加载以及更新体验的流畅程度大大提升。

效率加速的Bundless趋势

由于银行渠道领域的应用系统所承载的交易数量往往十分庞大，因此相关领域的应用开发团队普遍都有过这样的经历，工程刚刚初具规模就陷入编译打包泥沼的窘境。

我们发现，大家对于这一问题的解决方式大致是两种路径。一种是直接在技术层面解决，尤其是利用非浏览器基座所带来的技术可控便利，实现文件级增量编译打包和增量更新。另一种是在工程架构层面进行拆分解耦，以化整为零的方式回避大型应用工程的出现。

单独使用两种方式都有其局限性，前者往往缺少了跨团队应用拆分的方案提出，后者仍然无法解决大块头微前端在开发中操作效率低下的问题。两种方法进行结合可以实现取长补短。

近些年来，Vite大受欢迎，究其本质，秉承的正是第一类解决方式的Bundless思想。Bundless意味着模块组合任务由编译打包时，转移到了运行时。具体的，Vite是通过其Vite Client模块及现代浏览器对于ESM的支持能力联合实现了运行时模块组合。但较为可惜的是，目前行业内微前端框架大多选用的是乾坤，而其import-html-entry的沙箱能力尚未支持ESM，不能直接使用vite导出的微应用，虽然也有方法将两者衔接，但其本质已是削足适履。

相似地，TurboPack也沿袭了Bundless思路，并大量采用Rust语言开发出极小资源占用的高性能工具平台，实现了号称700倍于Webpack的性能提升。也就是说，用Webpack十几分钟干完的事情，用TurboPack只需要1秒钟。此外，与Vite不同的是，TurboPack将模块组合的责任从运行时的浏览器端拿到了部署服务器，在部署时与下载时实现模块组合，进一步减轻浏览器压力。然而，TurboPack当前仍然处于Alpha阶段，并未正式发布。

如果Bundless能够逐渐成为主流趋势，那么软件体系的边界固化也将从传统的编译打包时，延迟至部署时甚至是浏览时，这对于我们设计实现大型开放式渠道应用系统将会具有十分积极的意义。

关于作者

作者拥有银行IT领域近20年行业经验，现任赞同科技股份有限公司CTO;作者入行即从事工具平台研发，支撑并推动赞同科技在各线产品平台形成规模化快速应用开发配套工具体系，构建关键竞争力要素;作者主持研发的渠道系统前后端中间件平台，顺应并支撑业务快速发展创新，在细分领域市场份额排名常年位居榜首;作者愿在立足技术面向业务的发展道路上，与同业共同探索更进一步的价值创造。

免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。

责任编辑：kj005