軟件架構(gòu)領(lǐng)域正在爆發(fā)一場(chǎng)新的革命。Gartner權(quán)威發(fā)布2023年十大科技趨勢(shì)之一“可持續(xù)IT架構(gòu)”，可持續(xù)架構(gòu)得到越來(lái)越多從業(yè)人員認(rèn)同。創(chuàng)建和維護(hù)可持續(xù)的軟件架構(gòu)對(duì)于架構(gòu)師和工程師而言也是一項(xiàng)巨大的挑戰(zhàn)。

1 持續(xù)架構(gòu)的引入

如今，定義前期架構(gòu)的價(jià)值降低了很多，但系統(tǒng)仍必須滿足其具有挑戰(zhàn)性的質(zhì)量屬性；軟件涉眾仍然有著復(fù)雜、沖突且重疊的需求；仍有許多設(shè)計(jì)選項(xiàng)需要被理解和權(quán)衡；為了使系統(tǒng)能夠滿足涉眾的需求，也許我們比以往任何時(shí)候更需要解決交叉問(wèn)題。這些挑戰(zhàn)與長(zhǎng)久以來(lái)困擾軟件架構(gòu)師的挑戰(zhàn)是一樣的。然而，在當(dāng)今的環(huán)境里使用軟件架構(gòu)來(lái)應(yīng)對(duì)這些挑戰(zhàn)的方式必須要改變了。敏捷性和DevOps 實(shí)踐正在從根本上改變IT 專家(包括軟件架構(gòu)師)的工作方式。軟件架構(gòu)的實(shí)踐方式可能會(huì)發(fā)生變化，但我們相信它比以往任何時(shí)候都更加重要。

雖然軟件架構(gòu)仍然是產(chǎn)品交付成功的重要因素，但它需要發(fā)展以應(yīng)對(duì)這樣的環(huán)境，在這種環(huán)境中，系統(tǒng)通常被開發(fā)為一組并行且很大程度上獨(dú)立的組件(微服務(wù))。對(duì)于這種軟件開發(fā)風(fēng)格，如果像過(guò)去一樣采用單一架構(gòu)師或由一小組技術(shù)主管做出所有關(guān)鍵決策，最終只會(huì)讓架構(gòu)師負(fù)擔(dān)過(guò)重并導(dǎo)致開發(fā)停滯。這種軟件交付方法需要由更多的人以較小的增量來(lái)執(zhí)行架構(gòu)工作，并且比以往更注重早期的價(jià)值交付。

讓我們用物理上的建筑來(lái)類比并理解軟件架構(gòu)的重要性。在這個(gè)假設(shè)的場(chǎng)景中，我們受雇建造位于加利福尼亞州科羅納多的標(biāo)志性建筑Hotel Del Coromado 的復(fù)制品。這家酒店出現(xiàn)在1959 年著名的電影《熱情如火》中，它實(shí)際上代表了佛羅里達(dá)州南部的塞米諾爾麗茲酒店。這部電影的一位富有的粉絲想要在佛羅里達(dá)州擁有一座該酒店的復(fù)制品。

建造原本的酒店并不是一個(gè)簡(jiǎn)單的過(guò)程。工程于1887年3月開始，原始建筑計(jì)劃在施工期間不斷修改和添加。酒店于1888年2月開業(yè)且尚未完全完工，在其132 年的歷史中經(jīng) 過(guò)多次翻修和升級(jí)。那么我們將如何處理這個(gè)項(xiàng)目呢？

敏捷開發(fā)人員可能希望立即開始建造。相比之下，企業(yè)架構(gòu)師會(huì)說(shuō)，鑒于酒店的復(fù)雜歷史，立即著手建造會(huì)造成大量浪費(fèi)。相反，他希望做大量的前期規(guī)劃，并根據(jù)當(dāng)前的建筑技術(shù)和實(shí)踐制定一個(gè)五年的建設(shè)計(jì)劃。

然而這兩種方法可能都不是理想的方式。而持續(xù)架構(gòu)的目標(biāo)則是彌合兩種方法之間的差距以獲得更好的整體結(jié)果。

2 持續(xù)架構(gòu)的定義

滿足以下六個(gè)簡(jiǎn)單準(zhǔn)則的架構(gòu)就可以被稱為持續(xù)架構(gòu)：?

準(zhǔn)則 1 ：用產(chǎn)品思維，而非項(xiàng)目思維來(lái)設(shè)計(jì)架構(gòu)。從產(chǎn)品的角度進(jìn)行構(gòu)建比單純?cè)O(shè)計(jì)點(diǎn)的解決方案更有效率，更容易讓團(tuán)隊(duì)專注于客戶的需求。

準(zhǔn)則 2 ：聚焦質(zhì)量屬性，而不僅僅是功能性需求。質(zhì)量屬性需求驅(qū)動(dòng)著架構(gòu)。

準(zhǔn)則 3 ：在絕對(duì)必要的時(shí)候再做設(shè)計(jì)決策。架構(gòu)設(shè)計(jì)取決于事實(shí)，而不是猜 測(cè)。設(shè)計(jì)和實(shí)施可能永遠(yuǎn)都用不到的功能是無(wú)意義的，是對(duì)時(shí)間和資源的浪費(fèi)。

準(zhǔn)則 4 ：利用“微小的力量”，面向變化來(lái)設(shè)計(jì)架構(gòu)。大的、單體的、緊耦合的組件很難改變。相反，應(yīng)該使用小且松耦合的軟件元素。

準(zhǔn)則 5 ：為構(gòu)建、測(cè)試、部署和運(yùn)營(yíng)來(lái)設(shè)計(jì)架構(gòu)。大多數(shù)架構(gòu)方法只關(guān)注軟件構(gòu)建活動(dòng)，但我們認(rèn)為架構(gòu)師也應(yīng)該關(guān)注測(cè)試、部署和運(yùn)營(yíng)，以支持持續(xù)交付。

準(zhǔn)則 6 ：在完成系統(tǒng)設(shè)計(jì)后，開始為團(tuán)隊(duì)做組織建模。團(tuán)隊(duì)的組建方式驅(qū)動(dòng)著系統(tǒng)的架構(gòu)和設(shè)計(jì)。

這六項(xiàng)準(zhǔn)則、 基本活動(dòng)和工具可以幫助我們進(jìn)行架構(gòu)活動(dòng)并定義軟件架構(gòu)的關(guān)鍵組件，例如：

• 系統(tǒng)上下文
• 影響架構(gòu)的關(guān)鍵功能性需求
• 驅(qū)動(dòng)架構(gòu)的質(zhì)量屬性
• 架構(gòu)和設(shè)計(jì)決策
• 架構(gòu)藍(lán)圖?

有趣的是，軟件架構(gòu)的組件并不是孤立存在的，而是相互關(guān)聯(lián)的(見圖1)。創(chuàng)建軟件架構(gòu)需要在需求、決策、藍(lán)圖甚至最終架構(gòu)工件(可執(zhí)行代碼本身)之間做出一系列權(quán)衡。

▲圖1 軟件架構(gòu)的關(guān)鍵組件

3 持續(xù)架構(gòu)與其他架構(gòu)方法的區(qū)別

那么持續(xù)架構(gòu)與其他架構(gòu)方法有什么不同呢？

首先，我們不認(rèn)為它是一種方法論，而是一組準(zhǔn)則，工具、技術(shù)和思想可以被視為架構(gòu)師有效處理持續(xù)交付項(xiàng)目的工具集。使用這些準(zhǔn)則、工具、技術(shù)和思想，沒(méi)有預(yù)設(shè)的順序或流程可遵循，  完全取決于每個(gè)架構(gòu)師。我們發(fā)現(xiàn)它們對(duì)我們運(yùn)作過(guò)的項(xiàng)目和產(chǎn)品很有效，  而且它們本質(zhì)上是動(dòng)態(tài)的且具有高適應(yīng) 性。我們希望讀者會(huì)受到啟發(fā)，適應(yīng)持續(xù)架構(gòu)工具集的內(nèi)容，并用新的想法來(lái)擴(kuò)展工具集，為快速交付健壯且有效的軟件項(xiàng)目提供架構(gòu)支持。

我們堅(jiān)信利用持續(xù)架構(gòu)方法可以幫助架構(gòu)師處理和消除瓶頸。持續(xù)架構(gòu)的目標(biāo)是通過(guò)在整個(gè)過(guò)程中系統(tǒng)地應(yīng)用架構(gòu)視角和準(zhǔn)則來(lái)加速軟件開發(fā)和交付過(guò)程。因此，我們能夠創(chuàng)建一個(gè)可持續(xù)的系統(tǒng)，在很長(zhǎng)一段時(shí)間內(nèi)為組織創(chuàng)造價(jià)值。

與大多數(shù)主要關(guān)注軟件交付生命周期( Software Delivery Life Cycle ，SDLC) 的軟件設(shè)計(jì)和構(gòu)建方面的傳統(tǒng)軟件架構(gòu)方法不同，持續(xù)架構(gòu)為整個(gè)過(guò)程帶來(lái)了架構(gòu)視角，就如準(zhǔn)則5 所說(shuō)，為構(gòu)建、測(cè)試、部署和運(yùn)營(yíng)來(lái)設(shè)計(jì)架構(gòu)。它的存在盡可能地避免了大架構(gòu)超前綜合征，架構(gòu)團(tuán)隊(duì)不需要再創(chuàng)建復(fù)雜的工件來(lái)描述技術(shù)功能，軟件開發(fā)人員也不再會(huì)陷入等待而無(wú)事可做。它幫助架構(gòu)師創(chuàng)建彈性、高適應(yīng)性且靈活的架構(gòu)，這些架構(gòu)可以快速實(shí)現(xiàn)為可執(zhí)行代碼，測(cè)試并部署到生產(chǎn)環(huán)境中，以便該系統(tǒng)的用戶能夠提供反饋，而這是對(duì)架構(gòu)的最終驗(yàn)證。

此外，持續(xù)架構(gòu)方法側(cè)重于交付軟件而不是文檔。與傳統(tǒng)的架構(gòu)方法不同，我們將工件視為一種手段，而不是目的。

4 持續(xù)架構(gòu)提供的準(zhǔn)則和工具

我們并不是要定義一個(gè)具體的架構(gòu)方法論或開發(fā)流程。我們的主要目標(biāo)是分享一組在實(shí)際工作中的核心準(zhǔn)則和工具。事實(shí)上，應(yīng)用持續(xù)架構(gòu)是關(guān)于如何理解準(zhǔn)則和理念，并把它們應(yīng)用到自己的環(huán)境中去。這么做的時(shí)候，讀者可以自主決定使用哪些工具以及如何解讀必要的活動(dòng)。?

為了應(yīng)對(duì)當(dāng)前的挑戰(zhàn)，即在敏捷與持續(xù)交付的實(shí)用主義中建立堅(jiān)固的架構(gòu)基礎(chǔ)，我們已定義了這個(gè)基于價(jià)值的方法。然而，這并不意味著使用持續(xù)交付是使用持續(xù)架構(gòu)的先決條件。類似地，我們意識(shí)到一些公司可能還沒(méi)有準(zhǔn)備好在各方面都采用敏捷方法論。甚至，即使一個(gè)公司已經(jīng)完全投入到敏捷工作中，某些情況下(比如采用第三方軟件包時(shí))，其他方法也可能更為合適(見圖2）。

▲圖2 應(yīng)用持續(xù)架構(gòu)

這是不是意味著持續(xù)架構(gòu)在這種情況下不可用呢？絕對(duì)不是。持續(xù)架構(gòu)的好處之一就是，其工具可以很好地與其他軟件開發(fā)方法融合，不是僅限于敏捷開發(fā)。

持續(xù)架構(gòu)也在兩個(gè)維度中運(yùn)作：規(guī)模和軟件交付速度(見圖3)。軟件交付速度的維度決定著如何在這個(gè)加速交付循環(huán)的世界中采用架構(gòu)實(shí)踐。盡管規(guī)模維度注重于運(yùn)營(yíng)層面，我們相信持續(xù)架構(gòu)準(zhǔn)則可以被穩(wěn)定地應(yīng)用在所有的產(chǎn)品規(guī)模中，只是關(guān)注的層次和需要使用的工具會(huì)有所不同。

?▲圖3 持續(xù)架構(gòu)的維度

本文摘編于《持續(xù)架構(gòu)實(shí)踐：持續(xù)架構(gòu)實(shí)踐：敏捷和DevOps時(shí)代下的軟件架構(gòu)》，經(jīng)出版方授權(quán)發(fā)布（書號(hào)：9787111717744），轉(zhuǎn)載請(qǐng)保留文章來(lái)源。