前言:
1、本思维架构图是基于:受限于某现实场景下的最优规划。
2、本思维架构图是基于:工业制造行业的低代码开发平台。
工业制造业的特点:
这个行业比较简单,基本要求都是:
1、对生产的设备进行数据采集与设置,并进行监控或告警。 2、要求有自定义看板,适合根据图表监控特定的设备数据。 3、功能不多,模块也比较独立,数据表全是由设备采集而需自动生成。 4、做为低代码平台的标配:自定义界面(针对行业,还需提供VB、Python、JS等多种封装好的工业函数)
根据行业和模块的独立性,以及快速响应开发的需求,构思并设计了大一统的蓝图。
下面补上之前的思维架构图,原图有点大,这里截图拆分:
1、后端:微服务架构:
作用:
运行作为注册中心,提供统一的访问地址。
说明:
1、对于工业制造化场景,因为设备一直在生产,因此要求系统不能停机,一停机可能生场的设备没有对应的数据就会报废。 2、测试环境,必须到现场才能有硬件设备测试,同时还要求模块新增或升级、Bug问题修复时,保持系统可用。 3、原有插件式模块,很容易引发旧全局问题。
因此,微服务应用,比起插件式应用,在这里更适合场景。
这只是大体的规划思路图,核心包括:
1、基础负载均衡。 2、版本升级丝滑。 3、模块新增或移除简便。
目前Taurus.MVC 已经实现并发布了V3.0.2微服务架构版本,仅待写文介绍了。
2、后端:WebAPI 开发框架:
作用:
1、提供标准化接口开发方式。 2、提供统一的数据库操作类。 3、提供统一的日志操作与管理。
4、提供统一的WebAPI开发测试文档。
说明:
Taurus.MVC 本身已有WebAPI功能,因此直接上图即可:
框架的核心要素,极大提升开发效率:
1、数据库:框架自带CYQ.Data,一次编码,满足各种数据库要求。 2、日志:可以通过配置LogConn,统一监控。 3、开发文档:框架自带,前后端无需沟通,都统一在注册中心地址访问。
3、后端:系统权限控制平台:
作用:
1、提供标准化增删改查接口,实现基本业务的无代码。
2、提供基本的权限相关功能。
3、对微服务程序提供统一管理功能。
说明:
该平台的设计类似Aries、即无代码实现标准化的基础数据增删改查。
因为前后端分离与前端技术受限的原故,这里是规划重新开发。
并且做为了一个独立的微服务程序,独立完成开发、测试、部署。
4、后端:各独立的消息中间件:
作用:
1、接收由硬件采集的数据。 2、将采集数据入库。 3、将硬件采集的实时数据以Socket方式快速回传给前端显示。
说明:
硬件数据的采集,可由C#或C++编写,对接PLC的各设备协议采集即可。
采集程序可独立,通过MQ发布订阅方式,由中间件接收,入库。
5、后端:数据采集中件间
作用:
1、负责采集硬件设备的端数据。 2、沉淀出支持各硬件协议的采集组件。
说明:
数据采集后,可以通过MQ的订阅发布,将最新变更的数据推送过去。
6、后端:各独立的微服务应用程序
作用:
提供标准化或差异化的行业模块。
说明:
根据行业特性,可以沉淀出标准化或差异化的行业模块,沉淀的行业项目越多,后期越接近无代码,只需要选择对应的服务即可。
最终实现:业务人员,从系统中选出对应模块,导出即可成为统一的解决方案。
7、前端:基础框架
作用:
1、提供自定义界面布局(Web、App)。 2、根据行业特性,提供并沉淀业务组件。
说明:
做为前后端分离部分,前端提供封装的使用方法的便捷性,会很大影响开发效率。
8、边缘模块:监控与授权
作用:
1、提供对硬件的运行告警与运行模块的监控与重启。 2、提供软件授权的解决方案。
说明:
由于生产设备的系统,都运行在内网环境,因此,需要提前预测故障的可能性,
并且在故障发生前,需要收到告警信息,并提前处理好该问题,避免故障直接发生,导致客户损失。
9、构建大一统的测试环境
作用:
1、对于实施团队:直接选择业务模块,导出解决方案。 2、对于测试团队:长久的运行,可以提前监控出问题,提前修正。 3、对于开发团队:可以提前优化升级系统,为实施团队提供更稳定的模块。
10、程序员的自我修养
作用:
提供统一的开发标准,打造流水线开发人员。
说明:
对于业务型的公司,除了新人,是很难得到成长的。
因此,程序员在此类公司,必须具有很强的自我修养,才能在技术上更进一步。
因而,研究框架的底层实现,是最便捷的一种方式。
总结:
因为遇人不淑的原因,仅开始规划出全局,就Say GoodBye了,因此目前停留在规划阶段。
相关文章
暂无评论...