实战丨基于模块化的企业级业务平台客户端架构方案

浏览量:238 次

图2 定制化更新流程

 

服务端具有当前版本和下一版本的信息,客户端在正常运行过程中,会随机触发检查更新的逻辑。当发现需要下载下一个版本的升级包时,启动一个限速并支持断点续传的工具进行后台下载。由于下载的时间点分散、速度受控,且几率不高,因此完全不会影响网络流量。

 

实际升级中,启动器会优先检查本地是否已经存在下载好的升级包,如果存在就不再去服务器下载,彻底解决了大量升级导致的流量问题。该方案也可以作为企业建设CDN网络基础设施前解决补丁或升级包下发的备选方案。

 

本地化扩展

本地化扩展是指赋予传统BS架构技术调用操作系统底层能力的一种技术。在本方案中,主要包含FlashAIR的ANE技术和NativeProcess技术。

 

ANE即AdobeAirNativeExtension的缩写,它可以实现Air运行层调用操作系统库文件(在Windows中主要指DLL文件)的功能。它和NativeProcess技术的主要区别在于前者实现了本地库和运行时的共享内存和强耦合,可以以高性能的方式实现AVM本不具备或性能较差的一些能力,如日志、编码转换、加解密、Windows控制API、图像处理等。但是使用中要特别注意对本地化代码的异常处理逻辑。由于共享内存,所以一旦出现未捕获的运行异常,就会导致主程序崩溃。

 

NativeProcess技术主要用于平台对接或使用一些已开发好的本地程序,如Word/Excel填充、PDF转换、外设唤起等。使用该技术时,客户端和程序是解耦的,双方通过参数或命令行的方式进行异步交互,具备较好的健壮性和扩展性。

 

整体架构

基于以上关键技术方案,笔者所属项目团队设计并开发了一套实际可运行的业务处理平台,并在生产中集成了超过一百套业务系统,实现了前端体系的业务整合,平台逻辑架构示意如图3所示。

图3 平台逻辑架构

 

在用户视角,不同的业务系统被统一到一个UI界面中操作,统一权限管理降低了营运管理的成本,实现了千人千面的权限控制;单点登录则隐藏了多套业务系统的事实,大大提升了用户体验。从开发视角,仍然按照不同业务条线进行常规的开发,并没有增加太多的交流沟通成本,甚至每个业务系统都能够开发自己的UI界面,供各类用户使用,减少代理转发或接口转发的情况。本结构有效解决了本文开头所提的问题。

 

在项目推进中,我们还整合了许多业务的公共类需求和营运控制类需求,如柜员签到签退,业务量统计,自定义菜单等。同时我们还将业务系统较难实现的操作系统级的功能(如外设调用、打印、word/excel转换和生成等)统一包装在平台层供功能模块直接使用,从而大大降低了业务开发的工作量。

 

平台目前采用的Adobe AIR技术栈从今天的视角来看,已不再是最优选择。随着Adobe逐步降低对Flash/Flex相关技术体系的支持,以及社区活跃度的降温,可以预见在3~5年后该技术会慢慢退出历史舞台。从企业视角出发,如果尚未技术选型,那么笔者推荐使用基于JS技术的Electron/HTML体系;如果已经使用了Flex或其他技术,则可以考虑逐步向HTML体系迁移;同时保证前端程序对高版本H5技术的兼容,等到应用系统大部分已切换技术后,再进行客户端层面的迁移改造。

 

总结与展望

随着云计算进程的推进,企业的应用系统会逐步迁移至云端。后端会按照微服务的模式拆得很细,而前端则会根据受众的不同进行有机的打散和整合,最终形成一个个模块化的功能以及一个或多个独立的运行平台。

 

微服务加微前端,云平台加业务运行平台,企业应用会在这种新的架构模式下形成一种高效的开发部署机制,从而提升企业整体的敏捷性,适应业务的快速变化。在双平台支撑下,企业需要进一步完善双端的开发框架和项目脚手架,在公共服务层提供除具体业务逻辑外尽量多的基础能力;同时由平台实现基础的运行监控、日志、高可用能力,解放业务IT的创造力,为企业创造更大的价值。

往期精选:

(点击查看精彩内容)

 实战丨零售银行“供给侧改革”如何补短板

 实战丨使用SVM预测软件程序变更的风险

 实战丨强化身份治理构建完善的网络安全体系

● 实战丨金融行业云计算管理平台的研究与设计

 实战丨“春天工程”关于精益敏捷研发模式的探索




《金融电子化》新媒体部:主任 / 邝源  编辑 / 潘婧

 
®关于本站文章™ | 若非注明原创,默认 均为网友分享文章,如有侵权,请联系我们™
㊣ 本文永久链接: 实战丨基于模块化的企业级业务平台客户端架构方案