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年的不斷演進，適應業務擁抱變化，一路學習成長，特分享給大家，不足之處請諒解。