1.单一结构
系统camstar5 为单一结构的MAP网页，使用vb.net语言开发，框架为webfom。
登录界面
主页面
经过系统上线后发现存在以下问题
- 由于系统使用了camstar封装的控件，页面的每次交互都有很多的数据需要从服务器获取，导致界面反应缓慢，特别是业务逻辑很多界面控件很多的页面
- 开发的学习路线很长，既要懂得vb又要懂得camstar控件的使用
- 增加硬件，多服务都不能解决页面缓慢的问题
以上的问标题导致MES使用的用户体验十分不好，由此我们决定在camstar的基础上开发客户端程序的计划。
2.前后分离1.0
平台：dotnet 4.5 框架MVC +winform
查看官方的文档我们知道服务端是通过socket的方式传输xml来进行数据处理
Xml的转换使用官方的insitexmlclient库，前端使用winform,后端使用webapi
webapi的应用写和更新的操作走camstar server,读数据直接连接数据库，这样大大的减少了页面使用的数据和camstar系统之间的交互频率。
经过上线运行后系统出现了如下问题：
- 业务变更频繁，后台服务经常进行发布
- 更新后用户会话会被删除掉，导致用户验证失败，登录频繁
3.前后分离2.0
2.0在1.0的基础之上添加的缓存用来保存会话，这样解决了用户会话丢失的问题，并且应用发布后用户也不会感觉到有更新，只是会有短暂的卡住。就这样经过1年后，公司上马智能工厂项目，现有的结构已不能满足后续工厂的需求，因此MES进行了重新的升级
4.前后分离3.0
升级的前后考虑了安全，性能，可维护性等因素后，决定使用跨平台的dotnet core+docker,系统架构入下图
新建的智能工厂数据量为现有MES的10倍以上，因此webapi做了集群，使用nginx做负载，在webapi出现性能瓶颈的时候可以进行横向扩展来解决，系统到这个时候基本处于运行稳定状态，但是还存在下面问题
- 发布应用过程繁琐，需要懂dokcer linux知识
- 当需要更改应用配置时，需要重新打包镜像发布
- 发布会造成服务短暂中断
5.azure devops+k8s
前面的系统架构，经过压力测试后发现camstar 成为了系统的瓶颈，因此我们内部做出了如下决定：
- 基础数据还是用camstar管理
- 业务功能自主开发
- 每一块业务都分开来给不同的开发人员（外包）做
调正后系统框架如下
在这里特别感谢kuboard开源项目。从2017年开始踏足MES系统，经过了3年的不断演进，适应业务拥抱变化，一路学习成长，特分享给大家，不足之处请谅解。