基于架构软件设计方法及应用

随着国内外化工行业的繁荣与发展,从2018年开始,某能源集团下属的化工部,连续投资建设了MES(生产制造)系统、设备管理系统、安全管控系统、能源管理系统。这些系统建设得都非常好,无论是业务的切合度,还是系统的运行情况都非常良好。但是这些系统都是各自运行,相互独立。也就形成了一个个所谓的信息孤岛。为了消除这些信息孤岛,该化工部又投资建设了化工生产综合运营管控系统,简称运营管控系统。正好是我们公司承建了该系统,作为公司技术骨干,我有幸担任该系统的架构师,负责整个系统的架构设计。

运营管控系统主要是集成、整合生产、安全、设备、能源这几个系统。系统主要通过页面或者报表的形式给各相关单位提供查询、分析以及录入数据的功能,同时也为化工部领导做决策分析时提供数据支撑。经过仔细梳理,运营管控系统分为5个大模块,工厂模型、工作台、通用服务、业务活动监测、运营管控。

我们知道,基于架构的软件设计强调由商业,质量和功能需求的组合驱动软件架构设计。强调用视角与视图描述软件架构,用用例与质量场景描述需求。基于架构的软件设计有三个基础,即功能分解,架构风格的选择,以及软件模板的使用。按照基于架构的软件设计方法的理论,整个过程包括架构需求、架构设计、架构文档化、架构复审、架构实现和架构演化六个阶段。这六个阶段可以说是一步接一步。这六个阶段的具体工作内容,这里就不一一论述了。在我们实际开发过程中,重点是架构需求,架构设计,架构实现这三个阶段。

架构需求

在需求的前期阶段,我们采用了用户访谈和调查问卷结合的方式,把需求调研团队分成了几组,分别进行需求收集。通过与化工部业务专家的进行详细沟通。我们对运营管控主要业务功能、用户角色等有了整体、全面的了解。之后又制作了调查问卷表格,下发给各级单位业务人员,经过整理分析后,我们基本获悉了各级业务活动、过程细节。在需求的中期阶段,我们在化工部领导的协助和安排下,前往各个化工厂进行实地调研,对化工生产现场进行了观摩,了解了在现在各个化工厂生产方式以及具体生产流程。在需求的后期阶段,我们基本上已经掌握大部分业务需求,通过快速原型法构造出了一个运营管控原型系统,供专家和用户试用与反馈,让用户也参与到设计中,提供了工作流程方面、业务领域方面不可或缺的经验,也为以后项目通过验收提供了有力支持。

架构设计

在此阶段主要解决的问题是如何合理设计与描述软件架构。根据4+1的视图模型,我们基本按从5个不同的视角来描述软件体系架构,其中包括场景视图、逻辑视图、实现视图、进程视图、物理视图。场景视图使用UML模型中的用例图来进行建模,结合用户需求,在系统中设定了数据录入员、调度员、业务专家、系统管理员等用户角色,并分别为这些角色标识了相应用例。逻辑视图使用UML模型中的包图来进行建模。经过项目组分析讨论,决定采用B\S架构风格开发,将系统分为前端VUE部分和后端Springboot服务两部分,也就是业界比较常见前后分离模式。前端VUE直接部署在Nginx下,后端Springboot都是Jar包形式运行,基本上是一个服务一个Jar包。物理视图使用UML模型中的部署图来进行建模,部署图其实就是服务器如何部署。化工部所有的系统都部署在能源集团的内网,不存在什么内外部署的方式。根据实际情况,我们知道该系统同时在线访问人数不超过100人,按集团运维规定,所有的服务都采用了双节点部署方式。

架构实现

在这个阶段主要是解决系统构件开发和组装问题。构件来源主要是使用原有的构件和开发新构件。运营管控系统需要与MES系统和安全管控系统进行数据同步,我们使用Apache开源组件ETL实现数据同步;微服务架构的基础框架,如springboot,Spring Cloud、Eureka等。对于常见信息系统共同具备的用户管理、角色权限管理、日志记录、内容维护、消息中心等基本功能,在原来的项目中都有成熟的构件,无需再次开发。对于运营管控系统中所特有的构件,根据具体业务,我们单独开发。在运营管控系统中,我们用到了多种设计模式,例如用单例模式来实现各类编码的生成。构件实现完成后,我们根据不同业务类型,采用了不同的构件组装方式。例如设备管理系统需要从运营管控的工厂模型模块中获取物料信息,采用MQ消息机制。这个过程是不同的系统之间同步数据,采用异步消息方式;涉及审批流程的业务,采用基于工作流的组装方式。

从运营管控整体开发来看,良好的架构风格选择降低了模块之间的耦合度,同时提高了系统的安全性,可用性和可靠性等多项指标,更大程度的满足系统需求,保证系统后期的快速二次开发和数据接入。但在系统开发过程中也遇到一些问题,有些控制层代码跳过了服务层,直接与持久层的交互使得代码有些混乱,后面我们统一成了三层模式,控制层、服务层、持久层。在服务层我们采用了Redis作为缓存,虽然增加了系统的复杂性,但数据访问速率得到了极大的提高。

运营管控系统于2023年4月顺利上线,到现在稳定运行半年有余。简单总结一下,我们在项目的架构风格选择等方面积累了更多的经验,同时也暴露出我们团队在架构风格选择方面、在开发方面还是存在一些不足。尽力争取在以后的系统开发中,我们能做到更好,走得更远。

相关推荐
想进大厂的小王1 小时前
项目架构介绍以及Spring cloud、redis、mq 等组件的基本认识
redis·分布式·后端·spring cloud·微服务·架构
阿伟*rui2 小时前
认识微服务,微服务的拆分,服务治理(nacos注册中心,远程调用)
微服务·架构·firefox
ZHOU西口3 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
嚣张农民4 小时前
推荐3个实用的760°全景框架
前端·vue.js·程序员
梓羽玩Python5 小时前
推荐一款用了5年的全能下载神器:Motrix!全平台支持,不限速下载网盘文件就靠它!
程序员·开源·github
deephub5 小时前
Tokenformer:基于参数标记化的高效可扩展Transformer架构
人工智能·python·深度学习·架构·transformer
梓羽玩Python6 小时前
这款一站式AI体验平台值得收藏起来!GPT-4o、GPT-4o Mini、Claude 3.5 Sonnet免费使用!
人工智能·程序员·设计
架构师那点事儿6 小时前
golang 用unsafe 无所畏惧,但使用不得到会panic
架构·go·掘金技术征文
W Y9 小时前
【架构-37】Spark和Flink
架构·flink·spark
Gemini19959 小时前
分布式和微服务的区别
分布式·微服务·架构