论软件系统架构风格

论软件系统架构风格,第1张

摘要
本人于2020年1月参与某集团保险一体化研发项目,该系统致力于实现全国保险业务种类的整合、数据分析、订单汇总、账单汇总,为集团人员提供全国保险账单的管理、安全监控、数据保护方面提供全方位的软件支持,在该项目中我主要担任系统架构师岗位,负责整体架构设计与中间件选型。
本文以该保险一体化项目为例,主要讨论了软件架构风格在该项目中的具体应用。底层架构风格我们采用了虚拟机风格中的解释器,因该保险业务需要对接上游系统共计26种不同的数据协议,使用解释器风格可以满足保险一体化数据协议兼容性需求;中间层关于应用层的数据流转我们采用了独立构件风格中的隐式调用,这种风格主要用于降低系统间的耦合度、简化软件架构,提高可修改性方面的架构属性;应用系统层我们采用了B/S的架构风格,实现了信息的全球传输、查询和发布。最终项目成功上线,获得了用户的一致好评。

正文
随着该集团保险业务的迅速扩展,各集团子公司保险业务扩展迅猛,每年的保险种类不断发生变更,每个月数据从子公司上传到总公司总是发生数据协议不统一、订单数量及金额少数匹配不上的情况。之前的保险业务系统功能比较单一,实现比较简单,已经不能满足现代化信息系统快速变化的特点,且老系统框架比较老旧,采用了C/S的架构风格,每次将数据上传至总部总是需要在本地安装客户端,每次系统升级、维护、部署都比较麻烦。为了实现全球的信息传输、查询和发布,以及为了实现集团统一化管理,从2020年1月开始我被该集团任命为该保险一体化项目的系统架构师,架构小组共6人,我主要负责整体的架构设计与中间件选型,5月份完成架构工作,整个项目共耗时1年,2021年2月顺利通过验收,获得了业务的一致好评。
在架构工作开始阶段,我们便意识到,软件系统架构风格反映了领域中众多软件系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码,系统能够按照常用的、规范化的方式来组织,便于不同设计者很容易地理解系统架构。因此,在我集团总工程师的建议下,我们使用了虚拟机风格、独立构件风格以及B/S架构风格这三种较常用风格。虚拟机风格中的解释器风格能够提供灵活的解析引擎,这类风格非常适用于复杂流程的处理。独立构件风格包括进程通信风格与隐式调用风格,我们为了简化架构复杂度采用了隐式调用风格,通过消息订阅和发布控制系统间信息交互,不仅能降低系统耦合度,而且还可以提高架构的可修改性,B/S架构风格是基于浏览器和服务器的软件架构,它主要使用http协议进行通信和交互,简化客户端的工作,方便了后期系统升级、维护和部署,以下正文将重点描述架构风格的实施过程和效果。
底层架构风格我们使用了解释器风格来满足上游系统不同的数据协议。解释器风格是虚拟机风格中的一种,具备良好的灵活性,在本项目中,因为我们的架构设计需要兼容26种不同的数据协议,一般来说,这种软件编写难度非常高,代码维护难度压力也很大,所以这个解释器的设计任务就很明了了。软件设计需要高度抽象、协议的适配由配置文件来承担。具体做法如下:我们对上游的26种数据协议的数据结构进行了高度抽象,将每个上游系统的协议id和数据进行关系建模,将整体协议标识做为一个根节点,使用xml的数据结构搭建一套基于可变模板的解释器,协议目标的产生可以由上游系统提供的word文档进行解析得到,解释器支持协议模板热部署,这种可以将透传二进制数据直接映射成java可序列化对象,将数据协议的复杂度简化,后期数据协议更改不会对软件产生影响,仅仅改变协议模板文件即可。
中间层我们使用了独立构件风格种的隐式调用来简化构件间的交互复杂度,降低系统耦合度。主要的实现手段是,我们采用了一个开源的消息中间件作为连接构件,这个构件是apache基金会下的核心开源项目activemq,它是一款消息服务器,其性能和稳定性久经考验。由上文提到的解释器解析出对象后数据经过activemq分发到各个订阅此消息的应用系统,这些应用包括订单系统、账单系统、入湖系统等,这种多web应用的情况非常适合采用消息发布与消息订阅的机制,能够有效解决耦合问题,我们在编码的过程中发现只要采用这种风格的web应用,整个迭代过程效率极高,错误率降低,而且我们使用的spring框架,消息队列的管理完全基于配置,清晰简单,维护性良好,例如订单系统、账单系统、入湖系统等消息队列分类清晰,可以随时修改其结构,也能够随时增加其他主题的消息队列,不同的web系统监听的队列也可以随时变换组合,基于消息中间件的架构设计能够让系统的构建化思路得到良好实施,总体来说这种架构风格带来了非常清晰的数据流转架构,简化了编码难度,降低项目的二次开发难度。
应用系统层我们主要采用B/S的架构风格,主要用于解决保险全国一体化项目维护难,升级难的问题。鉴于该集团之前使用的C/S架构,子公司又分布在全国各个地区,路途遥远,且都是内网通讯,用户传输数据需要在本地安装客户端,且只能通过VPN网络访问公司内网。一旦更新客户端,很可能需要在全国各个站点跑一遍。这让我们在系统推广和维护方面面临较大压力。我们采用的B/S架构风格能够解决这个难题,并充分考量现在的技术成熟度,例如现在的html5完全能够实现以前客户端的功能,项目中我们使用了大量的前端缓存技术和websocket技术,能够满足项目实时性交互等需求。这种风格中页面和逻辑处理存储在web服务器上,维护和软件升级只需要更新服务器端即可,及时生效,用户体验较好,例如界面上优化,修改一些javascript脚本或者css文件就可以马上看到效果了
项目于2021年2月完成验收,运行至今,其中协议解释器软件性能没有出现过问题,消息中间件的性能经过多次调优吞吐量也接近了硬盘IO极限,满足当前的消息交互总量,另外由于我们的项目多次紧急状态下能够快速使用协议变动,得到过该集团的邮件表扬。除了机房几次突发性的网络故障外,项目至今还未有重大生产事故,项目组现在留1个开发人员和1个售后在维护,系统的维护量是可控的,系统运行也比较稳定。
不足之处有两个方面,第一在架构设计的过程中我们忽略了系统的安全性,在系统上线之后,由于要给某些系统管理员添加默认的密码,给这个用户添加默认的随机密码后,发现这里面有些用户根本不去修改初始默认密码。针对第一种问题,我们在用户首次登陆的时候,强制要求用户去修改初始密码,并在密码强度方面做了复杂度校验,提高了系统的安全性。针对第二种问题,我方采用了服务器冗余和心跳检测等策略,在一台服务器不可用的情况下,由另外一台服务器接管,提高了系统的可用性。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/725120.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-26
下一篇 2022-04-26

发表评论

登录后才能评论

评论列表(0条)

保存