index.md 8.0 KB
MES项目常见问题解答
尚未解答问题
前端开发环境
Q: NetAdvantage_WinForms_20092安装后，LC错误，怎么获得授权？
A: 待解答
Q: UI设计页面怎么设计页面，比如增加这套控件什么的？
主要是这套自定义控件怎么使用，注意事项。冲突。
A: 待解答
Q: 设计模式中的设计向导你们使用么？
A: 待回答
Q: VS2019打开设计页面后，为什么要在C盘写日志，为了避免这个我必须以管理员身份启动VS2019吗？
A: 待解答
Q: 前端似乎有实体对象， 表象是生成，能提供对应生成工具么？
PS 后端也应该有套生成工具
A: 待解答
后端问题
Q: 后端业务如何进行单元测试
A:
接口问题
开发环境问题
Q: 开发环境需要哪些软件？
A: 开发环境需要以下软件：
- 客户端开发：Visual Studio (支持C#)
- 服务端开发：IntelliJ IDEA 或 Eclipse (支持Java)
- 数据库工具：SQL Developer 或 PL/SQL Developer
- 版本控制：Git
- 构建工具：Maven (Java项目)
- 网络调试工具：Fiddler (抓包工具)
Q: 如何使用Fiddler抓包工具？
A: Fiddler是一款常用的网络抓包工具，使用步骤如下：
- 下载并安装Fiddler软件
- 启动Fiddler，默认会自动捕获所有HTTP/HTTPS流量
- 配置浏览器或应用程序使用Fiddler作为代理
- 在Fiddler界面中查看捕获的网络请求和响应
- 使用Fiddler的过滤器功能过滤特定的请求
- 使用Fiddler的断点功能修改请求或响应
- 使用Fiddler的自动响应功能模拟服务器响应
Q: Fiddler如何捕获HTTPS流量？
A: 要使用Fiddler捕获HTTPS流量，需要以下步骤：
- 启动Fiddler
- 点击"Tools" -> "Options" -> "HTTPS"
- 勾选"Decrypt HTTPS traffic"
- 点击"Yes"安装Fiddler根证书
- 在浏览器中导入Fiddler根证书（如果需要）
- 重启浏览器，Fiddler就可以捕获HTTPS流量了
Q: 如何搭建开发环境？
A: 搭建开发环境的步骤如下：
- 安装必要的开发工具
- 从版本控制系统中获取代码
- 配置数据库连接
- 配置服务端运行环境
- 配置客户端运行环境
- 启动服务端和客户端进行测试
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: 避免事务死锁的策略有：
- 串行处理（上策）：
- 业务服务端不执行代码，只是把代码发队列
- 队列服务器串行消费
- 消费完成后结果写入redis，由业务服务端轮询拉取
- 用户无感知
- 缓存锁（中策）：
- 每次执行前，锁住主表对应行
- 发现锁不住时，业务终止，并提示用户等下再试
- 用户偶尔被打扰，无法保证锁干净
- 完全由告警系统兜底（下策）：
- 让系统继续这样
- 告警不停刷出问题所在
- 将常见问题模式化
系统翻新
Q: 为什么系统需要翻新？
A: 系统需要翻新的原因包括：
- 旧系统故障严重
- 旧系统不必要复杂度太高
- 旧系统缺乏核心维护人员
- 旧系统缺乏代码
- 旧系统缺乏文档
- 旧系统页面隔离（可逐个页面替换）
Q: 系统翻新的策略是什么？
A: 系统翻新的策略包括：
- 架构重构：采用串行处理策略，引入消息队列，解决事务死锁问题
- 代码优化：将业务逻辑从SQL中迁移到代码中，提高可维护性和可测试性
- 文档建设：建立完善的文档体系，包括架构文档、API文档、操作手册等
- 团队建设：培养核心维护人员，建立知识传承机制
- 告警系统完善：扩展告警规则，实现故障自动修复机制
- 逐步替换：利用页面隔离的特点，逐个页面进行翻新替换，降低风险
告警系统
Q: 告警系统的组成是什么？
A: 告警系统由以下组件组成：
- nacos注册器
- 若干告警规则服务器
- 告警后端
- 告警vue前端
- 告警观察员
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中，难以理解和维护
- 架构复杂度：混合架构，组件众多，集成复杂