我的軟考歷程
摘要
2023年2月，我所在的公司通過了研發紗線MES系統的立項，該系統為國內紗線工廠提供SAAS服務，旨在提高紗線工廠的數字化和智能化水平。我在該項目中擔任系統架構設計師一職，負責該項目的架構設計工作。本文結合我在該項目中的實踐，詳細論述了微服務架構及其應用。微服務架構把系統分為一個個獨立的模塊，每個模塊單獨管理、開發、部署和運行，所以它具有技術異構型、容錯性、高可用性、模塊獨立性等特點。本項目采用微服務架構開發，提高了項目的開發和迭代速度，讓項目的性能、可用性、可修改性、安全性、可維護性得到了保障。最終在2023年12月，該項目正式上線并對外提供服務，目前已經有563家工廠接入了該系統，系統運行良好，得到了客戶的一致贊揚。
項目背景
隨著我國從制造業大國向制造業強國的轉換以及工廠數字化和智能化的持續推進，我所在的某地某科技公司基于自研的物聯網平臺相繼開發了染整一體化和織布一體化平臺，這些平臺上線后，得到了工廠的追捧，也為公司帶來了豐厚的經濟回報。基于此，我司于2023年2月開始研發紗線MES系統，該系統預算730萬，建設工期10個月，涵蓋紗線工廠從清花、梳棉、并條、精梳、粗紗、細紗到絡筒的全流程工序，將為紗線工廠提供全面的生產管理解決方案以及基于數據的智能決策分析能力。該項目為物聯網層次架構，整體分為感知層、網絡層和應用層。其中網絡層為公司已有的物聯網平臺，這次重點建設內容為感知層和應用層，感知層使用Golang語言開發，作為聯網網關部署在工廠側，負責工廠數據的采集和云端指令的下發。應用層為紗線MES系統主體，采用Java語言開發，使用Spring Cloud微服務架構，數據庫使用Mysql，緩存使用Redis，前端框架使用vue.js，日志、監控和鏈路追蹤采用skywalking、prometheus、grafana和ELK，最終通過devops的方式部署在kubernetes集群中。系統上線后，將提供以下：基礎管理、數據接入、工單排產、數字孿生、工資計算、智控中心和數據分析等等功能，通過以上功能，可以全面提升紗線工廠的數字化和智能化水平，使其運營水平和生產效率得到質的飛躍。
論述內容
該系統涉及模塊眾多，如果采用單體架構，在開發效率和部署上會面臨問題，單體架構中每一個模塊進行改動都要進行整體的測試和部署，這很影響開發和部署的效率，造成服務的不穩定性。而微服務架構相對于單體架構具有以下特點：1、模塊獨立性，可以獨立管理、開發、測試和部署并獨立運行。2、技術異構性，由于每個微服務互相不影響，所以每個微服務都可以采用不同的技術實現。3、容錯性、可用性，微服務之間不存在緊密耦合，一個微服務出現問題，不影響其他微服務。4、可擴展性，微服務之間是獨立的，所以可以獨立的擴展，不影響其他微服務，具有良好的擴展性。不過微服務也存在如下問題：1、分布式下的復雜性，由于微服務采用分布式的模式，就存在服務管理，注冊，發現、服務依賴等問題。2、微服務的數據一致性，由于每個微服務采用獨立的數據庫，當有依賴事務時，就需要保證數據的一致性，這在分布式下是比較困難的。3、運維的復雜性，傳統的手工部署在微服務模式下難以實施。本文結合我在該項目中的實踐，詳細論述微服務架構的實施以及相應問題的解決方案。
1、分布式下的復雜性。
為了解決微服務在分布式下的復雜性，我們采用Spring Cloud架構，使用nacos作為服務的配置和注冊中心，每一個服務啟動時都會把自己的ip和端口相關信息推送到nacos中，這樣nacos就維護了全部的微服務實例信息。當一個微服務有請求時，就會通過nacos獲取對應的ip和端口信息，然后通過ribbon實現負載均衡，通過open-feign進行遠程調用。同時，微服務還面臨分布式配置的問題，如果沒有全局的配置中心，在發布服務時會因為配置的不一致或者手工的錯誤而導致失敗，有了nacos作為分布式配置中心，免去了手工維護配置的不穩定性，讓系統不會因為配置而產生錯誤，同時nacos可以按環境保存配置，在不同的環境之間做了隔離，避免了因為環境而導致的問題。
2、數據的一致性問題。
微服務采用多實例部署，當一個請求的業務涉及多個微服務時，就會存在不同微服務修改數據的可能，在單體情況下，可以采用一個事務進行處理，但是在微服務下就沒法這樣做了。為了解決這個問題，我們采用了多種方式：1、批處理。2、seata。3、基于消息隊列。第一種方式比較簡單，比如紗線的前紡數據，這一部分數據對于業務不那么重要，所以我們每日都會通過批量處理的方式進行校驗，如果數據不對再觸發邊端的重復上報。第二種方式是通過阿里開源的seata，它是一個開源的分布式事務解決方案，通過它，我們使用AT模式可以做到對業務沒有侵入而實現分布式事務。當然這種方式對性能有很大影響，在使用時要對重要的事務進行處理，比如在紗線業務中，工單排產是一個復雜過程，這個過程會涉及到不同微服務的數據調整，一旦出現錯誤，會造成嚴重的后果，那這種就需要用seata來保證處理過程的分布式事務性。第三種是采用消息隊列，比如我們采用RocketMQ消息隊列，它提供了一種特性的消息：事務消息，通過它可以實現分布式下的數據一致性。比如在紗線業務中，我們對工資做計算時，就是通過生產的數據進行觸發消息執行的。
3、運維的復雜性。
在微服務架構情況下，如果采用手工部署，基本時不可能完成，也會對項目的進度造成重大影響。基于此，我們采用了docker和kubernetes以及cicd技術，當我們的代碼在提交后，就會觸發cicd的自動編譯，自動代碼掃碼和執行單元測試，當這一步驟完成后，就會進行docker鏡像的制作，并把生成的鏡像提交到鏡像倉庫中。最后，我們就可以一鍵進行鏡像的部署，把微服務部署到kubernetes集群中。通過這種方式，我們有效地保障了項目的進度，同時減少了人工導致的錯誤，保障了項目的質量。
總結
通過采用微服務架構模型，我們提升了開發和迭代速度，保障了項目的性能、可用性、安全性、可修改性等質量指標，確保了項目的按時上線。最終在2023年12月，該項目正式上線并對外提供服務，目前已經有563家工廠接入了我們的系統，系統運行良好，表現優異，得到了客戶工廠和公司領導的一致好評。項目雖然獲得了成功，但是也遇到過一些問題，在項目初期，由于產品對紗線業務的不熟悉，導致了多次功能的調整和返工，這讓開發人員產生了抵觸情緒。為了解決這個問題，我提出兩個解決方案：1、派產品去工廠一線，熟悉紗線工廠操作流程，與工人交流，掌握紗線業務的難點和痛點，保障需求質量。2、開發人員也要參與需求的整理過程，有問題反饋給產品，同時在做設計時，采用靈活的設計模式，為需求的變更留下可操作的空間。通過這兩個方法，最終解決了這個問題。得益于本次項目的實踐，我不僅學到了微服務相關的知識，也鍛煉了自己的架構和管理能力，我意識到只有不斷地學習和實踐才能讓知識融匯于自己的技術體系之中，才能在未來的工作中游刃有余、勇擔大任，為祖國的信息化建設貢獻自己的力量。
)
