背景

系統(tǒng)架構(gòu)風格（System Architecture Style）是描述某一特定應(yīng)用領(lǐng)域中的系統(tǒng)組織方式的慣用模式。架構(gòu)風格定義了一個詞匯表和一組約束，詞匯表中包含一些構(gòu)件和連接件組合起來的。軟件系統(tǒng)架構(gòu)風格反映了領(lǐng)域中眾多軟件系統(tǒng)所共有的結(jié)構(gòu)和語義特性并指導如何將各個模塊和子系統(tǒng)有效地組織成一個完整的系統(tǒng)。軟件架構(gòu)風格的共有部分可以使得不同系統(tǒng)共享一個實現(xiàn)代碼，系統(tǒng)能夠按照常用的、規(guī)范化的方式組織，便于不同設(shè)計者很容易地理解系統(tǒng)架構(gòu)。

題目

請以“軟件系統(tǒng)架構(gòu)風格”論題，依次從以下三個方面進行論述：

1. 概要論述你所參與分析和開發(fā)的軟件系統(tǒng)開發(fā)項目以及你所擔任的主要工作。
2. 分析軟件系統(tǒng)開發(fā)中常用的軟件架構(gòu)風格有哪些？詳細闡述每種風格的具體含義。
3. 詳細說明在你所參與的軟件系統(tǒng)開發(fā)項目中，采用了哪種軟件系統(tǒng)架構(gòu)風格，具體實施效果如何。

論文

摘要

本文討論某大型ERP系統(tǒng)項目的軟件架構(gòu)風格，試圖從項目的實際角度出發(fā)，剖析軟件架構(gòu)風格在軟件設(shè)計過程中發(fā)揮的實際作用和效果。該系統(tǒng)位于全球頂尖ERP系統(tǒng)之列，經(jīng)過多年沉淀和技術(shù)迭代依然彌久歷新，這不僅得益于其豐富的資源管理功能和先進的底層技術(shù)，密不可分的更是其低耦合、高擴展、高可修改性的軟件架構(gòu)風格發(fā)揮著巨大作用。在本文中首先討論了隱式調(diào)用架構(gòu)風格，管道過濾器架構(gòu)風格和解釋器架構(gòu)風格等軟件架構(gòu)風格在項目中如何發(fā)揮著巨大作用，并結(jié)合實際情況闡述選擇合理架構(gòu)風格的過程和依據(jù)。

最后對現(xiàn)有系統(tǒng)的不足之處進行分析，并且探索可能的解決方案。在本項目的研發(fā)過程中，我擔任了項目的架構(gòu)師，與項目經(jīng)理緊密配合完成對項目的具體架構(gòu)工作，并指導開發(fā)人員高效的完成開發(fā)工作，另外還需要負責項目的技術(shù)選型和解決技術(shù)難點。

正文

ERP系統(tǒng)在軟件信息系統(tǒng)家族中有著舉足輕重的地位，我司于2022年承接了某國際大型ERP系統(tǒng)的部分模塊工作，其中包括，支付模塊，人工智能發(fā)票等工作。本人負責支付模塊和人工智能發(fā)票模塊的架構(gòu)工作，另外肩負其余項目組的部分設(shè)計工作。其中支付模塊包含了眾多子系統(tǒng)，比如訂單系統(tǒng)，發(fā)票系統(tǒng)，匯款系統(tǒng)等以及串聯(lián)子系統(tǒng)的集成UI平臺。人工智能發(fā)票模塊是一大亮點，通過使用LLM 完成對遺留系統(tǒng)中大量雜亂發(fā)票拒絕理由的處理，從而分析出清晰的拒絕理由，并且匯總發(fā)票拒絕原因形成報表，乃至預(yù)測發(fā)票拒絕的趨勢，最終降低供應(yīng)商的發(fā)票拒絕次數(shù)，以增強用戶體驗感。

從對遺留系統(tǒng)的分析調(diào)研到對新模塊的設(shè)計和組裝以及對遺留系統(tǒng)的升級和對接，總共歷時一年，投資300萬。在團隊所有人的共同努力下，新模塊順利上線并獲得客戶的一致好評，尤其是智能發(fā)票模塊極大的減少了供應(yīng)商發(fā)票被拒絕的次數(shù)。接下來我們通過對常用軟件系統(tǒng)架構(gòu)風格的分析和比對以及結(jié)合實際項目決策來剖析軟件系統(tǒng)架構(gòu)的巨大作用。

本質(zhì)上講，軟件系統(tǒng)架構(gòu)風格是對以往業(yè)務(wù)的高度抽象，類似于設(shè)計模式，我認為它也是一種經(jīng)驗層面的復(fù)用。假如項目開始之初，沒有正確的對業(yè)務(wù)進行合理的抽象和建模，很難從紛繁的場景中剝離出業(yè)務(wù)的本質(zhì)，這就極易導致后續(xù)的工作很難開展。比如系統(tǒng)需要高度的可修改行和用戶自定義，而我們卻選擇了顯示調(diào)用，一旦項目開展，在開發(fā)階段就是受阻，維護階段更是困難重重。選擇適當?shù)能浖軜?gòu)風格對于項目的成敗至關(guān)重要。

目前主流的軟件系統(tǒng)架構(gòu)風格可以分為五類：1、數(shù)據(jù)流架構(gòu)風格；2、調(diào)用返回架構(gòu)風格；3、虛擬機架構(gòu)風格；4、獨立構(gòu)件架構(gòu)風格；5、數(shù)據(jù)中心架構(gòu)風格。

其一，數(shù)據(jù)流分為，批處理架構(gòu)風格和管道過濾器架構(gòu)風格，二者均需要將數(shù)據(jù)看作整體在獨立的管道或者處理構(gòu)件中依次完成處理，前者著重于批量處理，后者著重于源源不斷的數(shù)據(jù)在管道中逐個處理。
其二，調(diào)用返回分類比較多，比如子程序的顯示調(diào)用或者獨立構(gòu)件、層次間、對象間的互相調(diào)用。但是無論如何這種架構(gòu)風格的核心思想是，封裝。將不同功能封裝進不同構(gòu)件或者更小的對象，進行屬性和功能的隱藏以及解耦和復(fù)用。
其三，虛擬機架構(gòu)風格分為解釋器和規(guī)則系統(tǒng)，這種風格將組裝功能的能力交給了客戶，客戶可以自定義規(guī)則集然后通過解釋器或者規(guī)則系統(tǒng)編譯后再實時運行。優(yōu)點是靈活自定義，缺點是在大數(shù)據(jù)量面前性能不佳。
其四，獨立構(gòu)件風格的核心思想是解耦各個部件的直接調(diào)用，比如事件驅(qū)動?，F(xiàn)在領(lǐng)域中常用的MQ 就是典型的應(yīng)用場景，通過事件驅(qū)動解耦各個部件從而實現(xiàn)性能上的提升。
其五，數(shù)據(jù)中心風格可以分為多種。比如，倉庫，黑板等，數(shù)據(jù)中心模式強調(diào)的是集中處理數(shù)據(jù)或者共享數(shù)據(jù)從而實現(xiàn)數(shù)據(jù)的復(fù)用或者分組分塊處理。

接下來，筆者從實際的ERP項目具體模塊的案例討論，從其如何對如上軟件建構(gòu)風格進行取舍的方向出發(fā)一起探討這些風格的落地和實際效果如何。

筆者所開發(fā)項目的支付模塊本身包含多個子模塊，而子模塊之間又存在著不同程度的相互調(diào)用，比如發(fā)票模塊需要獲取訂單信息，匯款模塊需要獲取發(fā)票信息，并且各個模塊所需要的計算力也不盡相同，結(jié)合客戶想要升級現(xiàn)有系統(tǒng)的夙愿實現(xiàn)對各個模塊的獨立部署和動態(tài)監(jiān)控以及管理過程?；诳蛻衄F(xiàn)有體系，我們設(shè)計出支付模塊V2.0，整個模塊跟ERP系統(tǒng)中其他模塊通過ESB進行連接，這是基于遺留系統(tǒng)的設(shè)計。但是整個支付模塊是基于微服務(wù)架構(gòu)的，將不同模塊拆分為獨立的服務(wù)進行獨立開發(fā)可以極大的縮短開發(fā)周期和測試成本，另外將各個獨立服務(wù)部署于客戶的私有云上，可以實現(xiàn)服務(wù)的動態(tài)管理和擴縮容，對于后期的維護和擴展起到了至關(guān)重要的作用。為了串聯(lián)整個支付模塊，也獨立開發(fā)了一套UI系統(tǒng)，UI系統(tǒng)調(diào)用不同微服務(wù)來獲取相應(yīng)數(shù)據(jù)，從而做到了對用戶的友好操作。另外獨立的UI系統(tǒng)使得前后端可以徹底分離開發(fā)，這也極大的增加了開發(fā)效率。

其中子模塊包含發(fā)票的審批功能，從一開始的調(diào)研中發(fā)現(xiàn)客戶可能會經(jīng)常更改審批流程。筆者及團隊成員經(jīng)過慎重討論后，決定采用解釋器風格。選取了比較穩(wěn)定的Activity作為活動流的中間件，用戶可以通過拖拽的形式完成對流程的自定義，隨后將定義的模板經(jīng)過Activity轉(zhuǎn)換后持久化到數(shù)據(jù)庫。隨后系統(tǒng)完成對Activity的集成工作從而實現(xiàn)審批流程的用戶自定義。該子模塊也是眾多模塊中用戶最受歡迎的模塊。通過犧牲一小部分性能換取了極大的靈活性。

智能發(fā)票模塊著眼于供應(yīng)商被經(jīng)常拒絕發(fā)票的痛點，通過結(jié)合當下比較流行的AI 大模型，分為三大階段完成開發(fā)，1、發(fā)票拒絕原因的智能分類；2、發(fā)票拒絕的周報和月報；3、發(fā)票拒絕的趨勢以及預(yù)測。其中智能分類階段出于對用戶信息安全的考慮需要對原始數(shù)據(jù)進行過濾，其中包含用戶個人信息，企業(yè)敏感信息，發(fā)票數(shù)據(jù)信息等敏感信息。但隨著需求的不斷更新不難發(fā)現(xiàn)這些敏感信息是會變化的，所以設(shè)計之初便提出了管道過濾器架構(gòu)風格，將每種過濾器獨立開發(fā)，然后經(jīng)過一定順序組裝在一起構(gòu)成敏感信息隱藏組件，當某些數(shù)據(jù)需要處理時，可以快速且靈活的自定義組件。經(jīng)過獨立的過濾器數(shù)據(jù)完成需要的敏感數(shù)據(jù)過濾和處理。反之，如果沒有選擇管道過濾器風格，開發(fā)過程中用戶刪除或者增加敏感信息，就會變得非常麻煩，且無法完成獨立開發(fā)。

另外，由于該系統(tǒng)客戶眾多，數(shù)據(jù)量龐大，這些發(fā)票拒絕信息可能會在同一時間不定期的蜂擁至服務(wù)器，如果采用調(diào)用返回或者串行的處理方式可能有系統(tǒng)癱瘓的風險。于是采用隱式調(diào)用，主系統(tǒng)負責生產(chǎn)發(fā)票智能處理事件，Kafka作為高吞吐低延遲的事件處理平臺負責對事件進行轉(zhuǎn)發(fā)，獨立的微服務(wù)負責發(fā)票拒絕的處理工作，從而實現(xiàn)了削峰填谷對發(fā)票拒絕信息的智能處理。對于系統(tǒng)的可修改行也帶來了極大好處，因為隨著系統(tǒng)深入使用，發(fā)現(xiàn)發(fā)票拒絕的數(shù)量在一開始非常巨大而隨著智能發(fā)票系統(tǒng)的引入其拒絕也逐步降低。得益于前期的良好設(shè)計，客戶可以動態(tài)調(diào)整計算量（微服務(wù)的數(shù)量甚至是內(nèi)存大?。?/p>

該系統(tǒng)交付上線后，獲得客戶和使用者（供應(yīng)商和買方）的一致好評，穩(wěn)定運行至今。其不同模塊的高可擴展性，低耦合，高可修改性，高性能更是系統(tǒng)的亮點所在。這些良好性能均得益于項目設(shè)計階段的正確定位以及合理架構(gòu)風格的選擇。不僅如此，合理的架構(gòu)還會大大的提高開發(fā)效率。反之，可以想像，開發(fā)低效，難以擴展，性能不佳，這樣的系統(tǒng)往往都是架構(gòu)的問題。足以見，架構(gòu)是一個信息系統(tǒng)的根基所在。但受限于遺留系統(tǒng)以及其他非主觀性因素的限制，交付模塊仍存在一些值得思考的問題，比如對于LLM 的使用不能僅限于單一生產(chǎn)商（GPT），應(yīng)該可以靈活配置其他大語言模型生產(chǎn)商。另外，系統(tǒng)遺留模塊也有可能以后需要智能+，比如智能發(fā)現(xiàn)供應(yīng)商、智能訂單等等，這一些都在促使一個通用的LLM落地平臺的產(chǎn)生，諸多受限下，現(xiàn)有系統(tǒng)只是和LLM做了簡單的集成。