我的軟考歷程

摘要

2023年9月，我所在的公司通過了研發紗線MES系統的立項，該系統為國內紗線工廠提供SAAS服務，旨在提高紗線工廠的數字化和智能化水平。我在該項目中擔任系統架構設計師一職，負責該項目的架構設計工作。本文結合我在該項目中的實踐，詳細論述了分布式事務技術及其應用。在該項目中，我們采用了微服務架構，把系統根據領域分析劃分成了一個個的微服務，每一個微服務都有自己獨立的數據庫，這樣就不可避免會面臨分布式事務的問題，為了解決該問題，我們采用了基于seata的2pc和tcc以及基于消息隊列的和最終一致性的機制來保障分布式事務。最終在2024年7月，該項目正式上線并對外提供服務，目前已經有563家工廠接入了該系統，系統運行良好，得到了客戶的一致贊揚。

項目背景

隨著中國制造不斷地產業升級以及工廠數字化和智能化的持續發展，我所在的某地紡織科技公司基于自研的物聯網平臺相繼開發了染整一體化和織布一體化平臺，這些平臺上線后，得到了紗線工廠的追捧，也為公司帶來了豐厚的經濟回報。基于此，我司于2023年2月開始研發紗線MES系統，該系統預算730萬，建設工期發10個月，該項目涵蓋了紗線工廠從清花、梳棉、并條、精梳、粗紗、細紗到絡筒的全流程工序，將為紗線工廠提供全面的生產管理解決方案。該項目采用物聯網層次架構模型，整體分為感知層、網絡層和應用層。其中網絡層為公司已有的物聯網平臺，這次的重點建設內容為感知層和應用層，感知層使用Golang語言開發，作為聯網網關部署在工廠側，負責工廠數據的采集和云端指令的下發。應用層為紗線MES系統主體，采用Java語言開發，使用Spring Cloud微服務架構，數據庫使用Mysql，緩存使用Redis，前端框架使用vue.js，日志、監控和鏈路追蹤采用skywalking、prometheus、grafana和ELK，最終通過devops的方式部署在kubernetes集群中。系統上線后，將提供以下：基礎管理、數據接入、工單排產、數字孿生、工資計算、智控中心和數據分析等等功能，通過以下功能，可以全面提升紗線工廠的數字化和智能化水平，使其運營水平和生產效率得到質的飛躍。

論述內容

該系統涉及模塊眾多，每一個業務都比較獨立，所以我們架構組討論決定采用微服務架構模型，把獨立的業務作為一個個獨立的微服務單獨開發、測試和部署。在此情況下，每一個微服務都采用了獨立的數據庫，就不可避免產生了分布式事務的問題。比如，排產配置功能，在設置排產時，會調用工資、絡筒、細紗等微服務的接口，并對各自的數據庫進行表的修改，這種情況下，如果出現某一個服務的修改失敗，就產生了分布式數據的不一致。為了解決這個問題，就需要引入分布式事務解決方案。目前主流的分布式事務解決方案有以下四種：1、兩階段提交；2、TCC機制；3、基于消息隊列的分布式事務；4、基于本地表的事務。

1、兩階段提交。

這是一種經典的分布式事務解決方案，兩階段包括表決和執行兩個階段，在表決階段都通過后才會提交事務，只要有一個節點有問題就回滾事務，都不提交。該方式可以保障事務的可靠性，缺點是性能較差，事務協調者需要等待所有節點的反饋。針對兩階段提交的特點，我們在需要嚴格保證事務型的業務上使用，通常要容忍一定的性能損耗。在紗線MES系統中，班組設置非常重要，紗線MES中的絡筒、粗紗、細紗的數據統計都跟班組設置有關，一旦班組設置出現數據不一致問題，將導致紗線MES系統中的多個業務模塊的數據出現不一致，讓后續產生的工資計算、統計報表、數字孿生、大屏等等出現數據問題，為了解決這個問題，我們采用了兩階段提交方式，并引入了阿里開源的seata框架，通過該框架，確保了數據的一致性，避免發生數據問題，有力提升了系統的準確度。

2、TCC機制。

這是一種常見的分布式事務解決方式，TCC分別為Try，Confirm、cancel，在執行一項任務時，每一個節點都要提供Try、Confirm和cancel方法，Try方法負責鎖定該任務需要的資源，比如你要排產，在try階段就要把排產的工單給提前鎖定，避免后續執行出現問題。在Confirm階段，各個節點就需要執行任務了，在該階段要保障任務正常執行，同時要滿足冪等性，避免多次執行出現問題。如果在Try階段，發現資源不夠，或者任務沒法執行，就執行cancel方法，把鎖定的資源等釋放掉。TCC機制優點是靈活，缺點是對系統代碼侵入比較多，需要編寫的代碼比較多，不太好控制。

3、基于消息隊列的分布式事務。

消息隊列在大型系統中應用廣泛，它有著削峰、解耦、異步、性能好的優點，同時通過它還可以實現分布式事務。具體做法如下：首先，需要設置消息發送方的發送級別，需要多個消息節點收到消息才返回成功，只要成功就確定消息已經進入了消息隊列中，這就保證了消息在發送方的事務型。在消息的消費側，需要取消消費者的自動提交機制，采用手動提交機制，只有消息被正常執行才提交消息。如此就保證了消費者側的事務型。目前基于消息隊列的分布式事務在大型項目中非常流行。在紗線MES系統中，工廠會觸發停機事件，該事件到了云端后，云端需要處理停機業務，該業務涉及到工資微服務、絡筒和細紗以及粗紗微服務，在這個過程中，如果有某個微服務處理失敗，就會造成停機業務出現不同步的現象，為了解決這個問題，我們采用了基于消息隊列的分布式事務方式。具體操作流程如下：發起方發送一個半消息，該消息存儲在消息隊列中，但是并沒有并消費者消息，當發起方處理完成后，確認了事務再通知消息隊列，讓消費者消費。通過這種方式，既保證了事務，又沒有系統之間的耦合。

4、基于本地表的分布式事務。

該方法需要提供一個本地表，把執行失敗的任務記錄到本地表中去，然后通過定時任務去執行失敗的任務，如果執行三次還失敗就報警給相關責任人，讓責任人接入處理。我們在項目開發過程中，對于一些對時間比較敏感的業務就可以采用這種方式。比如在邊端上報粗紗線核心數據時，由于模型匹配問題導致粗紗核心數據處理失敗，這種情況下如果采用TCC或者AT模式將會影響云端處理的速度，基于此，就可以采用本地表的方式，把核心過程數據記錄在表中，后面通過定時任務進行觸發重新執行，讓核心處理過程再次執行一遍，如果還是不行，就生成報警信息，通過短信、電話、飛書等方式通知響應開發人員介入處理。這種方式既保證了業務處理的快速又保證了事務的最終一致性，在現在系統開發中應用十分廣泛。
以上四種方式在微服務架構中得到了廣泛的應用，借助分布式事務，微服務才能保證數據的可靠性，避免出現系統性故障。

總結

通過采用分布式事務，我們保障了數據的可靠性，保障了項目的性能、可用性、安全性、可修改性等質量指標，確保了項目的按時上線。最終在2023年12月，該項目正式上線并對外提供服務，目前已經有563家工廠接入了我們的系統，系統運行良好，表現優異，得到了客戶工廠和公司領導的一致好評。項目雖然獲得了成功，但是也遇到過一些問題，在項目初期，由于產品對紗線業務的不熟悉，導致了多次功能的調整和返工，這讓開發人員產生了抵觸情緒。為了解決這個問題，我提出兩個解決方案：1、派產品去工廠一線，熟悉紗線工廠操作流程，與工人交流，掌握紗線業務的難點和痛點，保障需求質量。2、開發人員也要參與需求的整理過程，有問題反饋給產品，同時在做設計時，采用靈活的設計模式，為需求的變更留下可操作的空間。通過這兩個方法，最終解決了這個問題。得益于本次項目的實踐，我不僅學到了分布式事務相關的知識，也鍛煉了自己的架構和管理能力，我意識到只有不斷地學習和實踐才能讓知識融匯于自己的技術體系之中，才能在未來的工作中游刃有余、勇擔大任，為祖國的信息化建設貢獻自己的力量。