構(gòu)建前瞻性應(yīng)用架構(gòu)的優(yōu)秀實(shí)踐

作者：陳峻編譯 2021-02-25 09:00:00

本文總結(jié)了一些值得您遵循的應(yīng)用架構(gòu)優(yōu)秀實(shí)踐，以便您構(gòu)建出結(jié)構(gòu)化的、可擴(kuò)展的應(yīng)用架構(gòu)。

【51CTO.com快譯】不知道您是否聽說過“軟件架構(gòu)師最討厭意大利面”這個(gè)梗?它是指軟件架構(gòu)師在設(shè)計(jì)應(yīng)用系統(tǒng)時(shí)，應(yīng)當(dāng)在匹配業(yè)務(wù)概念的基礎(chǔ)上，開發(fā)出清晰的架構(gòu)與流程，避免出現(xiàn)各種在邏輯上相互纏繞，模塊與層面關(guān)系定義不清，各個(gè)功能彼此交織，進(jìn)而形成難以被運(yùn)維的“意面式架構(gòu)(spaghetti architecture)”。下面，我將總結(jié)一些值得您遵循的應(yīng)用架構(gòu)優(yōu)秀實(shí)踐，以便您構(gòu)建出結(jié)構(gòu)化的、可擴(kuò)展的應(yīng)用架構(gòu)。

為什么應(yīng)用架構(gòu)如此重要?

通常，應(yīng)用架構(gòu)包含了所有的軟件模塊、組件、內(nèi)/外部系統(tǒng)、以及構(gòu)成應(yīng)用之間的交互關(guān)系。顯然，結(jié)構(gòu)良好的應(yīng)用架構(gòu)，可以確保您的應(yīng)用能夠根據(jù)業(yè)務(wù)和用戶的需求進(jìn)行預(yù)期的擴(kuò)展。同時(shí)，好的架構(gòu)既能夠合理地隔離不同的功能概念，又可以在內(nèi)/外部形成良好的依賴關(guān)系。

相反，如下圖所示，如果您在針對各種需求的初期設(shè)計(jì)時(shí)，以及后期的變更中，忽略了對于應(yīng)用架構(gòu)的合理構(gòu)建與維護(hù)，那么將會(huì)導(dǎo)致不同組件之間，依賴關(guān)系的錯(cuò)綜復(fù)雜，甚至難以同步與管理。

那么在實(shí)際項(xiàng)目中，意面式的架構(gòu)到底會(huì)給我們的系統(tǒng)帶來哪些危害呢?

服務(wù)抽象性差：如果未能圍繞著核心業(yè)務(wù)概念，實(shí)現(xiàn)正確地隔離和抽象，那么服務(wù)就會(huì)在不同系統(tǒng)之間分散各種業(yè)務(wù)規(guī)則，進(jìn)而降低代碼的結(jié)構(gòu)化和可重用的程度。
難以管理的依賴關(guān)系：當(dāng)組件之間無法被恰當(dāng)?shù)馗綦x時(shí)，任何針對系統(tǒng)的修改或替換操作，都會(huì)產(chǎn)生滾雪球式的效應(yīng)。也就是說，某一部分的更改，會(huì)影響到與之相關(guān)聯(lián)的所有依賴關(guān)系。
僵化且運(yùn)行緩慢的舊系統(tǒng)：如果系統(tǒng)本身就很復(fù)雜且不靈活，那么我們就需要花費(fèi)更長的時(shí)間，通過調(diào)整來適應(yīng)新的業(yè)務(wù)變化。而且，如果所用到的技術(shù)已經(jīng)過時(shí)，那么隨著時(shí)間的推移，核心數(shù)據(jù)與系統(tǒng)會(huì)對過時(shí)的技術(shù)，累積深度的依賴性，從而導(dǎo)致技術(shù)更新變得難上加難。

如何構(gòu)建可擴(kuò)展的應(yīng)用架構(gòu)?

為了構(gòu)建可靠且可擴(kuò)展的應(yīng)用架構(gòu)，您需要基于嚴(yán)格的定義原則和完善的設(shè)計(jì)概念。顯然，我們的目標(biāo)是：既需要支持快速的業(yè)務(wù)增長和大規(guī)模的擴(kuò)容需求，又需要降低部署的難度并避免高昂的代碼維護(hù)成本。因此，我們可以從如下方面考慮應(yīng)用架構(gòu)的設(shè)計(jì)：

在所有項(xiàng)目參與者之間達(dá)成共識(shí)。
支持定義和計(jì)劃。
持續(xù)進(jìn)行變更。
管理好系統(tǒng)的復(fù)雜性。
管控與降低風(fēng)險(xiǎn)。
最大限度地減少技術(shù)債務(wù)(這是任何前瞻性應(yīng)用架構(gòu)的最終目標(biāo))。

在此，我們引入一個(gè)架構(gòu)畫布(Architecture Canvas)概念。作為一個(gè)支持和加速架構(gòu)設(shè)計(jì)的多層框架，它可以促進(jìn)對可重用的服務(wù)和組件進(jìn)行抽象。通過保留相對獨(dú)立的生命周期，架構(gòu)畫布可以最大程度地減少變更所帶來的影響，進(jìn)而使得應(yīng)用架構(gòu)更易于維護(hù)和擴(kuò)展。

架構(gòu)畫布的邏輯組成如上圖所示。其中，從下往上分別是：

基礎(chǔ)層：在該層中，您可以實(shí)現(xiàn)所有可重用的非功能性需求。例如：連接到外部系統(tǒng)，或者使用可重用的UI模式與主題庫，來擴(kuò)展現(xiàn)有的框架服務(wù)。
核心層：在該層中，您可以實(shí)現(xiàn)各種核心的業(yè)務(wù)服務(wù)。例如：各種圍繞著業(yè)務(wù)概念的服務(wù)、業(yè)務(wù)規(guī)則、業(yè)務(wù)實(shí)體、業(yè)務(wù)交易和業(yè)務(wù)部件等。您需要讓這些服務(wù)獨(dú)立于目標(biāo)系統(tǒng)，并根據(jù)基礎(chǔ)服務(wù)來抽象出任何可能的整合信息。可見，通過基礎(chǔ)層和核心層，您已經(jīng)隔離出了所有可重用的服務(wù)或組件。
最終用戶層：在該層中，您可以通過使用基礎(chǔ)與核心層的服務(wù)，來支持用戶界面，以及與用戶交互的流程。值得注意的是：為了確保整個(gè)生命周期的獨(dú)立性，處于該層面上的模塊，不應(yīng)為其他模塊提供服務(wù)。

架構(gòu)的驗(yàn)證

為確保設(shè)計(jì)架構(gòu)的合理性，且不會(huì)產(chǎn)生“意面式”的爛尾，下面我將為您提供一些可以遵循的準(zhǔn)則和建議。

1.不要帶有橫跨三個(gè)層面的向上引用

鑒于前文提到的結(jié)構(gòu)化分層，我們顯然不應(yīng)該讓與業(yè)務(wù)無關(guān)的基礎(chǔ)服務(wù)，去依賴核心業(yè)務(wù);也不應(yīng)該讓可重用的服務(wù)，依賴各種最終用戶的接口。此外，向上引用往往會(huì)產(chǎn)生一個(gè)群集。如下圖所示，在該群集中，存在直接或間接鏈接關(guān)系的任何兩個(gè)模塊，都具有循環(huán)依賴性。

在上圖中，由于模塊B可以間接地影響模塊A，而模塊A也可以間接地影響模塊B，因此，這就是一組相互依賴的模塊。此外，如果您有另一個(gè)正在使用核心服務(wù)B的最終用戶模塊(EU2)，那么它就會(huì)依賴整個(gè)群集。可見，它們在運(yùn)行時(shí)，不僅會(huì)占用大量不必要的資源，還會(huì)受到集群中某些模塊變化的間接影響。

2.避免最終用戶之間的旁路引用

為了確保正確的隔離，并避免最終用戶具有不同的生命周期，最終用戶模塊不應(yīng)提供可重用的服務(wù)。下圖展示了最終用戶之間的旁路引用關(guān)系。

也就是說，如果最終EU1調(diào)用到了EU2，則表明EU1無法獨(dú)立于EU2，同時(shí)他也就不能獨(dú)立于EU2下面的層級結(jié)構(gòu)中的集群。

3.避免在核心模塊和基礎(chǔ)模塊之間進(jìn)行循環(huán)引用

如果您能夠遵循前面提到的兩個(gè)規(guī)則，那么就不必?fù)?dān)心最終用戶模塊之間可能出現(xiàn)循環(huán)引用。反而，我們應(yīng)當(dāng)重點(diǎn)避免在核心模塊和基礎(chǔ)模塊之間，可能出現(xiàn)的循環(huán)引用。此類模塊之間的循環(huán)引用主要產(chǎn)生于：一些業(yè)務(wù)概念沒能被正確地抽象，進(jìn)而對代碼的管理產(chǎn)生不良的影響。

如上圖所示，循環(huán)引用多發(fā)生在如下兩種情況中：

A和B之間的連接相當(dāng)緊密，甚至它們隸屬于同一模塊(例如，某個(gè)訂單或訂單項(xiàng))。
根據(jù)兩個(gè)概念之間的既定關(guān)系，如果改變一個(gè)模塊的邏輯位置，其單方面的依賴關(guān)系就會(huì)被破壞。例如，合同是由客戶產(chǎn)生的，但是客戶的存在則無需合同的引用。

4.額外的建議

核心模塊不應(yīng)具有前端的篩選條件：如果要實(shí)現(xiàn)某個(gè)服務(wù)，您可能需要添加一些篩選條件，用以進(jìn)行單元測試。但是作為開發(fā)人員，一旦完成了代碼測試，就應(yīng)該及時(shí)去除掉測試的篩選條件。如果出于某種原因，仍需要使用測試篩選條件，來支持某些回歸測試或BDD(行為驅(qū)動(dòng)開發(fā))測試的話，您就需要將其移至最終用戶的測試模塊中。畢竟，將測試篩選條件保留在核心模塊上，是非常危險(xiǎn)的。基于風(fēng)險(xiǎn)管控的考慮，它們只能存在測試環(huán)境中，而不能留在生產(chǎn)環(huán)境里。
所有實(shí)體都應(yīng)當(dāng)被發(fā)布為只讀：通過該實(shí)踐，您可以禁止訪問者(consumers)簡單粗暴地在數(shù)據(jù)庫中創(chuàng)建、更新或刪除記錄。在核心服務(wù)層面上，您應(yīng)當(dāng)抽象出業(yè)務(wù)事務(wù)、驗(yàn)證、規(guī)范化、以及審核等需要與其他系統(tǒng)集成的組件。在實(shí)際項(xiàng)目中，正確的做法是：將所有的業(yè)務(wù)交易的實(shí)施，都發(fā)布給使用者，同時(shí)提供安全且恰當(dāng)?shù)某橄蠓?wù)。
避免在基礎(chǔ)層面上使用業(yè)務(wù)邏輯：有時(shí)候，人們會(huì)傾向于在該層面上實(shí)現(xiàn)各種業(yè)務(wù)規(guī)則。但實(shí)際上，我們應(yīng)當(dāng)確保它與業(yè)務(wù)無關(guān)，并能在任何應(yīng)用領(lǐng)域中被重用。
不要在基礎(chǔ)層面上添加核心業(yè)務(wù)實(shí)體：為了與業(yè)務(wù)無關(guān)，基礎(chǔ)模塊不應(yīng)具有與業(yè)務(wù)相關(guān)的實(shí)體。不過，它們可以通過帶有非業(yè)務(wù)的實(shí)體，以支持應(yīng)用的某些非功能性需求。例如：如果您需要?jiǎng)?chuàng)建通用的服務(wù)，來審計(jì)所有事務(wù)，那么就可以創(chuàng)建一個(gè)審計(jì)實(shí)體。畢竟，某個(gè)軟件應(yīng)用的主要業(yè)務(wù)可能并非審計(jì)，而是銷售產(chǎn)品，拉新客戶或變更合同等。

使用架構(gòu)畫布的應(yīng)用組合

在討論應(yīng)用組合之前，我先聲明一下：這里所說的“應(yīng)用”，與我們通常在業(yè)務(wù)環(huán)境中所提及的“應(yīng)用”，具有不同的含義。在該語境中，我們使用術(shù)語“應(yīng)用”來指代在開發(fā)環(huán)境中的最小部署單元。它既可以是被用于管理的所有環(huán)境，也可以是業(yè)務(wù)應(yīng)用、IT用戶、安全性集合、以及應(yīng)用單個(gè)模塊等。

為了識(shí)別應(yīng)用到底屬于上面提到的哪個(gè)層級，您應(yīng)該對目標(biāo)應(yīng)用進(jìn)行深入分析和模塊化的解構(gòu)。例如：如果某個(gè)應(yīng)用將帶有最終用戶模塊，那么它肯定屬于最終用戶層面。

下面是一組能夠確保設(shè)計(jì)出前瞻架構(gòu)的參考規(guī)則：

規(guī)則1：從模塊的架構(gòu)畫布準(zhǔn)則開始

我們應(yīng)按照上面給出的建議，對模塊進(jìn)行正確地分層。

規(guī)則2：隔離公共服務(wù)

將各個(gè)模塊正確地放置到位后，我們就可以開始設(shè)計(jì)應(yīng)用了。如前所述，如果在“最終用戶應(yīng)用2”上有一個(gè)模塊會(huì)使用到“最終用戶應(yīng)用1”上某一個(gè)模塊，那么我們就應(yīng)該對通用核心應(yīng)用進(jìn)行隔離，以免產(chǎn)生依賴性。如下圖所示，如果兩個(gè)應(yīng)用要進(jìn)行內(nèi)容上的共享與交互，則需要在彼此隔離的情況下，通過通用的應(yīng)用服務(wù)來實(shí)現(xiàn)。

規(guī)則3：請勿混淆所有者角色

如果一個(gè)應(yīng)用擁有多個(gè)所有者，那么由于責(zé)任不清，可能會(huì)導(dǎo)致變更的內(nèi)容與管理過于復(fù)雜。我們可以通過所有權(quán)的聚合與分拆(如下圖)兩個(gè)方式，給每個(gè)應(yīng)用明確設(shè)定一個(gè)所有者。

規(guī)則4：分清參與者角色

與所有者角色類似，參與者也有各自不同的節(jié)奏。例如：有一個(gè)提供不同保險(xiǎn)業(yè)務(wù)的門戶網(wǎng)站。其所有業(yè)務(wù)線都處于同一個(gè)應(yīng)用中，那么任何一個(gè)業(yè)務(wù)(例如車險(xiǎn)業(yè)務(wù))的任何更改都不可能獨(dú)立于其他業(yè)務(wù)。因此，實(shí)際上是由那個(gè)最慢的業(yè)務(wù)線，決定了整體應(yīng)用的發(fā)布周期。

如下圖所示，我們需要通過在每條業(yè)務(wù)線中創(chuàng)建單獨(dú)的應(yīng)用，讓每個(gè)參與者都可以預(yù)估自己的交付速度。在此基礎(chǔ)上，我們可以根據(jù)項(xiàng)目的具體需求，或是將不同參與者的任務(wù)相互隔離，或是通過內(nèi)容共享的方式，加強(qiáng)他們的協(xié)作。