# MES项目常见问题解答 ## 尚未解答问题 ### 前端开发环境 #### Q: NetAdvantage_WinForms_20092安装后，LC错误，怎么获得授权？ ![NetAdvantage_WinForms_20092 LC错误截图](./images/微信图片_20260303140609_774_623.png) A: 待解答 #### Q: UI设计页面怎么设计页面，比如增加这套控件什么的？ 主要是这套自定义控件怎么使用，注意事项。冲突。 ![.](./images/ScreenShot_2026-03-04_141049_805.png) A: 待解答 #### Q: 设计模式中的设计向导你们使用么？ ![](./images/ScreenShot_2026-03-04_141445_630.png) A: 待回答 #### Q: VS2019打开设计页面后，为什么要在C盘写日志，为了避免这个我必须以管理员身份启动VS2019吗？ ![](./images/ScreenShot_2026-03-04_140332_295.png) A: 待解答 #### Q: 前端似乎有实体对象， 表象是生成，能提供对应生成工具么？ PS 后端也应该有套生成工具 ![](./images/ScreenShot_2026-03-04_142035_870.png) A: 待解答 ### 后端问题 #### Q: 后端业务如何进行单元测试 A: 待解答 ### 接口问题 ### Q: 接口业务正在使用的入口接口有哪些 A: 待解答 ### Q: MES除了对产销输出业务，还对哪些系统输出了，能给个列表么？ A: 待解答 ### Q: 能提供一个接口的POSTMAN的调试模板或者单元测试入口么？ A: 待解答 ## 开发环境问题 ### Q: 开发环境需要哪些软件？ A: 开发环境需要以下软件： - 客户端开发：Visual Studio (支持C#) - 服务端开发：IntelliJ IDEA 或 Eclipse (支持Java) - 数据库工具：SQL Developer 或 PL/SQL Developer - 版本控制：Git - 构建工具：Maven (Java项目) - 网络调试工具：Fiddler (抓包工具) ### Q: 如何使用Fiddler抓包工具？ A: Fiddler是一款常用的网络抓包工具，使用步骤如下： 1. 下载并安装Fiddler软件 2. 启动Fiddler，默认会自动捕获所有HTTP/HTTPS流量 3. 配置浏览器或应用程序使用Fiddler作为代理 4. 在Fiddler界面中查看捕获的网络请求和响应 5. 使用Fiddler的过滤器功能过滤特定的请求 6. 使用Fiddler的断点功能修改请求或响应 7. 使用Fiddler的自动响应功能模拟服务器响应 ### Q: Fiddler如何捕获HTTPS流量？ A: 要使用Fiddler捕获HTTPS流量，需要以下步骤： 1. 启动Fiddler 2. 点击"Tools" -> "Options" -> "HTTPS" 3. 勾选"Decrypt HTTPS traffic" 4. 点击"Yes"安装Fiddler根证书 5. 在浏览器中导入Fiddler根证书（如果需要） 6. 重启浏览器，Fiddler就可以捕获HTTPS流量了 ### Q: 如何搭建开发环境？ A: 搭建开发环境的步骤如下： 1. 安装必要的开发工具 2. 从版本控制系统中获取代码 3. 配置数据库连接 4. 配置服务端运行环境 5. 配置客户端运行环境 6. 启动服务端和客户端进行测试 ### Q: 开发环境常见问题有哪些？ A: 开发环境常见问题包括： - 数据库连接失败：检查数据库服务是否启动，连接字符串是否正确 - 服务端启动失败：检查端口是否被占用，配置文件是否正确 - 客户端无法连接服务端：检查网络连接，服务端是否正常运行 - 代码编译错误：检查依赖是否正确，代码是否有语法错误 ### Q: 如何解决开发环境中的依赖问题？ A: 解决依赖问题的方法： - 客户端：使用NuGet管理依赖包 - 服务端：使用Maven管理依赖包 - 确保所有依赖包版本兼容 - 定期更新依赖包以修复安全漏洞 ## 系统架构 ### Q: MES系统的技术栈是什么？ A: MES系统采用C#客户端和Java服务端的混合架构，数据库使用多账号多表空间的设计。具体包括： - 客户端：C# (9641个cs文件) - 服务端：Java (3094个java文件，1763个xml文件) - 数据库：多账号多表空间，表数量多且列数大 ### Q: 系统的主要组件有哪些？ A: 系统主要组件包括： - 客户端：C#开发的桌面应用 - 服务端：多个Java服务，如CoreFS.Authentication、CoreUpLoadApp、ServiceMesToJh等 - 数据库：多个数据库账号和表空间 - 告警系统：包含nacos注册器、告警规则服务器、告警后端、告警vue前端、告警观察员 ## 系统问题 ### Q: 系统常见的故障有哪些？ A: 系统常见故障包括： - 事务死锁：大量操作下容易出现死锁，导致系统卡住 - 性能问题：业务逻辑全部放在SQL中，性能差 - 维护困难：缺乏核心维护人员，外包人员不可靠 - 代码管理混乱：大量代码在封装文件里，暴露出的文件不是最新代码 - 文档缺失：完全没有任何可读文档 ### Q: 如何避免事务死锁？ A: 避免事务死锁的策略有： 1. **串行处理（上策）**： - 业务服务端不执行代码，只是把代码发队列 - 队列服务器串行消费 - 消费完成后结果写入redis，由业务服务端轮询拉取 - 用户无感知 2. **缓存锁（中策）**： - 每次执行前，锁住主表对应行 - 发现锁不住时，业务终止，并提示用户等下再试 - 用户偶尔被打扰，无法保证锁干净 3. **完全由告警系统兜底（下策）**： - 让系统继续这样 - 告警不停刷出问题所在 - 将常见问题模式化 ## 系统翻新 ### Q: 为什么系统需要翻新？ A: 系统需要翻新的原因包括： 1. 旧系统故障严重 2. 旧系统不必要复杂度太高 3. 旧系统缺乏核心维护人员 4. 旧系统缺乏代码 5. 旧系统缺乏文档 6. 旧系统页面隔离（可逐个页面替换） ### Q: 系统翻新的策略是什么？ A: 系统翻新的策略包括： 1. **架构重构**：采用串行处理策略，引入消息队列，解决事务死锁问题 2. **代码优化**：将业务逻辑从SQL中迁移到代码中，提高可维护性和可测试性 3. **文档建设**：建立完善的文档体系，包括架构文档、API文档、操作手册等 4. **团队建设**：培养核心维护人员，建立知识传承机制 5. **告警系统完善**：扩展告警规则，实现故障自动修复机制 6. **逐步替换**：利用页面隔离的特点，逐个页面进行翻新替换，降低风险 ## 告警系统 ### Q: 告警系统的组成是什么？ A: 告警系统由以下组件组成： 1. nacos注册器 2. 若干告警规则服务器 3. 告警后端 4. 告警vue前端 5. 告警观察员 ### Q: 告警系统的工作原理是什么？ A: 告警系统的工作原理如下： - 需要的告警往nacos上注册 - 告警后端轮询执行这些注册 - 告警结果按照扫描批次写入数据库中 - 告警vue来进行紧急扫描以及观察扫描结果 ## 技术问题 ### Q: 前端代码的主要问题是什么？ A: 前端代码的主要问题是： - 前端主要工作是拼装SQL，逻辑分散 - 前后端参数是魔法约定，缺乏标准化接口 - 难以理解和测试 ### Q: 后端代码的主要问题是什么？ A: 后端代码的主要问题是： - 复杂的业务逻辑，大量的SQL操作和事务处理 - 缺乏模块化设计，代码冗余度高 - 难以维护和扩展 ## 数据库 ### Q: 数据库的结构是怎样的？ A: 数据库采用多账号多表空间的设计，具体包括： | 账号 | 表空间 | 表/视图 数量 | 存储过程 | | ---------- | ------- | ------- | ---- | | core | CX_DB | 49 | 0 | | CG_DLINK | PMS_DB | 0 | 0 | | cxmeter | CX_DB | 0 | 0 | | CXUSER | CX_BIG | 1337 | 257 | | LIMSUSER | LIMS_DB | 100 | 4 | | cx_mes | | 1/70 | 13 | | CXREADONLY | | 2 | 0 | ### Q: 数据库的主要问题是什么？ A: 数据库的主要问题是： - 表的数量很多，表列数非常大 - 建表随意，缺乏规范化设计 - 存储过程当作定时任务在做，逻辑混乱 ## 项目管理 ### Q: 项目的体量如何？ A: 项目体量较大，具体包括： - 客户端：9641个cs文件 - 服务端：3094个java文件，1763个xml文件 - 数据库：多个账号和表空间，大量表和存储过程 ### Q: 项目的复杂度如何？ A: 项目复杂度较高，主要体现在： - 链路复杂度：前后端参数是魔法约定，缺乏标准化接口 - 代码复杂度：业务逻辑全部放在SQL中，难以理解和维护 - 架构复杂度：混合架构，组件众多，集成复杂