論軟體架構風格

摘要：

        2020年3月，本人就職的某網際網路公司承擔了“XXAPP電子商務系統”的開發工作，該項目是集團為使用者提供電子商務業務的重點項目，主要實作消費者的網上購物和線上支付以及各種商務活動、交易活動。本人作為核心成員有幸加入其中，擔任架構師一職，主要負責該系統的需求分析和架構設計。在該系統中，筆者結合實際需求，從安全性、穩定性、可擴充性、開發和運維難度等多方面綜合考慮，最終為系統選擇了層次架構風格和面向對象架構風格。本文以該項目為例，介紹其各自特點，最後結合項目詳細介紹層次架構風格和面向對象架構風格的實際應用，以及開發過程中遇到的問題和具體解決方案。這種架構設計有效地降低了維護成本，提高了系統的安全性，可拓展性，可複用性和可移植性。系統上線後得到了廣大使用者和集團對于系統的認可。

正文：

        2020年3月，我參與了公司電子商務系統”的研發，擔任系統架構師職務，進行系統的架構工作。該系統的外部實體主要是分為4類組織，使用者，商戶，系統管理人員，金融支付機構。電商系統有幾個特點，模型多且複雜度高，資料流鍊路長，業務變化快，應對突發流量性能要求高等特點。包括商品庫存、訂單支付、營銷活動、售後配送、使用者權益、商戶管理等幾大業務模型。随着業務不斷疊代之後，每個模型的邊界和管理會越來越複雜和邏輯備援。

        本文結合作者的實踐，以XXAPP電子商務系統為例，論述軟體架構風格的具體應用。首先介紹本項目的概況，以及常用的軟體架構風格有哪些，并且介紹其各自特點。然後針對筆者參與設計的系統所采用的的架構風格進行具體描述。最後結合項目實際實施情況，對該架構風格進行總體評價，對于設計中遇到的問題進行總結概述。

1.架構風格分類

        架構風格定義了用于描述系統的術語表和一組指導建構系統的規則，是系統組織方式的慣用模式，可以為我們的項目提供架構級的通用解決方案。這種架構級的軟體重用可以極大提高我們的系統建設。軟體系統開發中常用的軟體架構風格有資料流風格，調用/傳回風格，獨立構件風格，虛拟機風格，倉庫風格。在此筆者列舉幾類進行較長的描述：

        調用傳回風格包括主程式/子程式、面向對象和層次架構，其中，層次架構風格的特點是每層使用下一層的提供的服務，同時為上一層提供自己的服務，隻能見到與自己鄰接的層，逐漸解決，化整為零，降低系統複雜度。

        獨立構件風格包括程序通信和事件驅動，其中事件驅動的架構風格中，構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中其他構件的一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，提高了系統可擴充性。

資料流風格包括批處理序列和管道過濾器；虛拟機風格包括解釋器和基于規則系統，該架構風格主要用于自定義規則或步驟，有良好的靈活性；倉庫風格包括資料庫系統、超文本系統和黑闆系統，主要用于語音識别等領域。

2.層次風格的具體實踐

        在項目啟動初期，我們架構組通過開會研讨，列舉了需實作的非功能性需求，例如安全性、可修改性、可用性等，然後結合複雜的電子商務業務。以及開發和維護的難點，最終決定采用層次架構風格和面向對象架構風格。首先采用層次架構風格，将整個系統進行層次劃分，共分為五個層次，分别是：表示層、網關層、應用層、服務層和資料層。這樣可以充分解決子產品之間的耦合性，提升系統可修改性，可擴充性；并且通過層次劃分指定了上層結構僅能調用下層服務，下層服務也隻能服務于上層結構，以此保證系統的安全性。對于複雜的電子商務業務需求，我們采用面向對象的架構風格，通過對象的關系可以很好地将複雜的資料模型進行映射，充分實作代碼的複用，提升系統的可修改性。下面筆者将具體介紹層次結構下的具體應用。

        表示層負責代表業務的視圖展示，核心系統的前端頁面、手機APP、H5頁面等，通過通路下層網關接口的API進行業務邏輯的互動，進而将資料的變化展示給使用者，實作前後端分離部署。

        網關層主要負責使用者權益、路由轉發、流量控制等功能，并将應用層共有的頭部校驗提取到網關層利用過濾器的方式實作，一方面可以提高系統的可修改性，減少代碼備援；另一方面可以提高系統的安全性。對于錯誤請求甚至非法請求可以直接在網關層攔截，對于合法的請求SpringMVC架構便會根據請求路徑轉發到應用層進行處理。

        應用層主要負責對不同的請求進行服務編排與調用。通過業務的政策來選擇工作方式，也可以配置多條疊代校驗規則完成業務上對不同業務邏輯的校驗，這些政策和疊代規則都是配置化可以随意拆分組裝，充分實作服務層代碼塊的複用，降低業務邏輯的耦合性，大大提高系統的可擴充性。

        服務層負責核心的業務邏輯處理，使用Spring架構為應用層服務支援，通過面向對象的架構風格簡化了業務邏輯的複雜性。在該層次中，根據業務邏輯的定義，将各個業務流程的處理盡可能的剝離成單獨的服務閉環，面向公共的服務子產品統一提取。充分做到高内聚、低耦合。然後由應用層訂制好的服務鍊，順序地調用服務層不同的業務子產品，進而完成本次請求。

        資料持久層作為最底層的概念，僅服務于唯一上層，服務層，通過面向對象的架構風格，将複雜的業務概念映射到具體的資料模型上，采用兩級存儲，MySQL作為核心資料存儲，Redis資料庫作為資料緩存，減少核心資料庫的讀壓力，為資料的一緻性、安全性提供有力保障。

3.遇到的問題及解決方案

        在系統開發到中期，由于複雜的電子商務業務的海量資料處理再加上層次結構的調用弊端，性能瓶頸逐漸暴露，針對這個問題，經過架構組開會讨論制定了以下兩點解決方案：

        首先，針對資料庫通路的性能優化，筆者決定使用分庫分表的模式實作資料庫的實體分離，降低資料庫伺服器的IO消耗，後期還可以針對伺服器做橫向擴充。同時增加緩存資料庫作為應用系統與資料庫系統的中間件，對于業務系統常用到的碼表、位址表、配置表等基礎資訊可以預先緩存到緩存資料庫中，進一步提高了資料通路效率。