架構的“分而治之”

fuckyouass 8年前發布 | 10K 次閱讀軟件架構 Java

什么是“分而治之”

面對業務功能復雜的企業級軟件，我們一般都會尋找各種方式或者是標準進行抽象、進而將業務拆分或組合，從而達到分而治之的目的。

JAVA很早就有模塊化的概念，也就是OSGi，在我看來，他應該可以算是微服務化的一個非常早期的表現形式了。OSGi聯盟進行管理的標準規范，就好比是如今各微服務間傳遞數據的協議約定。而一個個bundle，就好比是一個個獨立部署的服務。他的bundle管理，以及相互之間的依賴關系，就如同各個單獨部署的微服務之間的鏈路監控。只不過微服務是獨立部署的，有獨立的JVM容器，獨立的硬件環境，通信是需要經過網絡傳輸的。而OSGi不是，它是運行再同一個JVM下面下的，數據交互是在同一個進程內部。

但是，上面的內容并不重要，本文也不是重點要去講OSGi或者是微服務的實現，回歸正題，我們還是來討論一下，如何去進行一個業務項目進行分解、架構，從而實現分而治之。

如何去定義架構

關于架構，有非常多的定義。百度的描述如下：軟件架構（software architecture）是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。來自ANSI/IEEE Std 1471-2000的定義如下：架構是一個系統的基本組織，通過組件、組件之間和組件與環境之間的關系以及管理其設計和演變的原則的具體體現。

簡單的說，架構就是一系列的決策，這些決策設計軟件系統的組織、組成系統之間的協作方式。

架構，沒有固定的風格，也沒有一招鮮走遍天的模式，所謂的架構，應該是自上而下的，不僅要關注高層的服務，還要關注中間的模塊甚至是底層的代碼。作為架構師，相對于開發人員，其更有價值的應該是在于他的廣度和抽象能力，而并非其在某個業務的深度，作為該角色所要去突破的，也并非是去做廣度基礎上的深度，而應該是盡可能的提升有效的交流，將高層次的理念轉化為具體的實現，從而和具體的開發人員在系統的設計上達成“共識”，尤其是在各組件之間的交互問題上、邊界劃分上，更是應該早早地達成共識。

以下是一張架構師和開發團隊在軟件作業中的關系圖。

架構的目標是什么

架構的目標，簡單的說就是消除架構，在靈活性和復雜度之間取得一個平衡點，從而使變化所帶來的影響和成本都有所降低。而最好的方式，就是將大型的系統進行業務分析，識別接縫，定義邊界，進而組件化、模塊化、服務化，最終分而治之。

架構分解的案例

大型項目中，模塊之間的耦合是無可避免的，因為總是有一些業務需要模塊間的相互合作來完成。但是模塊間的循環依賴，是需要在架構階段去盡可能的避免的，尤其是在復雜場景中存在的多個模塊之間的間接循環關系。如果不消除這種循環依賴關系，那么就很難去做到服務化的分而治之。

比如有一個面向車商服務的項目，里面有涉及到人、車、訂單的關系，從現實場景來說，他們是一個兩兩雙向關聯的關系：訂單包含了車、買家、賣家，車包含了訂單和車主，人包含了成交的訂單和擁有的車。

那么，如何去化解呢？我們可以做業務上移，也可以做服務下沉。

上移：是將導致依賴的成因上移到一個更高等級的模塊中去，從而消除雙向依賴，變成自上而下的單向模式，上移后如下：

下沉：是將導致依賴的成因放到一個較低等級的模塊中去，如下：如此，我們就將人、車和訂單之間的關系進行了原則性上的解耦。解除了原有的依賴關系。但業務依舊是以一個項目在對外提供服務的。

后續隨著業務的擴大，可能人、車、訂單又各自孵化出很多的自有的業務邏輯，項目體量越來越大，投入進來的人也越來越多。每次的業務調整、項目上線都會讓工程師們膽戰心驚，生怕牽一發而動全身。

這個時候，其實不管是上移式的還是下沉的方案，都可以輕松將這三個業務獨立成單獨的項目，安排合適數量的工程師去獨立維護，而對外只是暴露服務化的接口而已。至于最終是選擇上移還是下沉，這就要看具體的業務場景了。以下面分別是針對上移和下沉的兩種情況的拆分：再后來，隨著業務數據越來越多，對于每個業務小組來說，既維護上層業務，又維護基礎數據之間的存儲關系、業務關聯、分庫分表等等，可能就會出現有些力不從心了，而且不同的小組之間，對于基礎數據的抽象化層面來看，也很難去做到全局的統一。所以這個時候，就需要從上一步拆離的項目中，抽象出共同的一部分來進行統一維護和對外提供服務。最后，當單個基礎服務也承載不了的時候，那就再開始拆分。