前言：
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了，因此目前停留在规划阶段。