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

随着国内外化工行业的繁荣与发展,从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 小时前
Token计费系统设计与优化:算力API的后端架构实践
架构
Decay__4 小时前
12_MySQL InnoDB 内存与锁调优 —— Buffer Pool、redo log、隔离级别与锁等待
运维·数据库·sql·mysql·架构
爱敲代码的小黄4 小时前
神经网络入门指南:从 CNN、RNN 到 Attention
人工智能·面试·程序员
一只爱撸猫的程序猿5 小时前
我看着一个 AI 引擎在 14 天里,从"记忆"走进了"搜索"
人工智能·后端·架构
陈随易8 小时前
纯 Go 写的 JS 引擎,跑分超过了 C 语言的 QuickJS
前端·后端·程序员
Dawson Zhu9 小时前
从空间 Scaling 到时间 Scaling
人工智能·语言模型·架构·aigc·agi
陈随易10 小时前
专注飞机 FocusFlight,两个人把番茄钟做成了一趟航班
前端·后端·程序员
爱勇宝12 小时前
忙不是勋章,身体才是职场人唯一的长期资产
程序员
kyriewen14 小时前
我扫了 422 个仓库,近一半 CI 在裸装依赖
前端·javascript·程序员
致力于划水第一线15 小时前
现在矿石每天签到只送一个了吗
程序员