軟件架構(gòu)領(lǐng)域正在爆發(fā)一場新的革命。Gartner權(quán)威發(fā)布2023年十大科技趨勢之一“可持續(xù)IT架構(gòu)”，可持續(xù)架構(gòu)得到越來越多從業(yè)人員認同。創(chuàng)建和維護可持續(xù)的軟件架構(gòu)對于架構(gòu)師和工程師而言也是一項巨大的挑戰(zhàn)。
1 持續(xù)架構(gòu)的引入
如今，定義前期架構(gòu)的價值降低了很多，但系統(tǒng)仍必須滿足其具有挑戰(zhàn)性的質(zhì)量屬性；軟件涉眾仍然有著復雜、沖突且重疊的需求；仍有許多設計選項需要被理解和權(quán)衡；為了使系統(tǒng)能夠滿足涉眾的需求，也許我們比以往任何時候更需要解決交叉問題。這些挑戰(zhàn)與長久以來困擾軟件架構(gòu)師的挑戰(zhàn)是一樣的。然而，在當今的環(huán)境里使用軟件架構(gòu)來應對這些挑戰(zhàn)的方式必須要改變了。敏捷性和DevOps 實踐正在從根本上改變IT 專家(包括軟件架構(gòu)師)的工作方式。軟件架構(gòu)的實踐方式可能會發(fā)生變化，但我們相信它比以往任何時候都更加重要。
雖然軟件架構(gòu)仍然是產(chǎn)品交付成功的重要因素，但它需要發(fā)展以應對這樣的環(huán)境，在這種環(huán)境中，系統(tǒng)通常被開發(fā)為一組并行且很大程度上獨立的組件(微服務)。對于這種軟件開發(fā)風格，如果像過去一樣采用單一架構(gòu)師或由一小組技術(shù)主管做出所有關(guān)鍵決策，最終只會讓架構(gòu)師負擔過重并導致開發(fā)停滯。這種軟件交付方法需要由更多的人以較小的增量來執(zhí)行架構(gòu)工作，并且比以往更注重早期的價值交付。
讓我們用物理上的建筑來類比并理解軟件架構(gòu)的重要性。在這個假設的場景中，我們受雇建造位于加利福尼亞州科羅納多的標志性建筑Hotel Del Coromado 的復制品。這家酒店出現(xiàn)在1959 年著名的電影《熱情如火》中，它實際上代表了佛羅里達州南部的塞米諾爾麗茲酒店。這部電影的一位富有的粉絲想要在佛羅里達州擁有一座該酒店的復制品。
建造原本的酒店并不是一個簡單的過程。工程于1887年3月開始，原始建筑計劃在施工期間不斷修改和添加。酒店于1888年2月開業(yè)且尚未完全完工，在其132 年的歷史中經(jīng) 過多次翻修和升級。那么我們將如何處理這個項目呢？
敏捷開發(fā)人員可能希望立即開始建造。相比之下，企業(yè)架構(gòu)師會說，鑒于酒店的復雜歷史，立即著手建造會造成大量浪費。相反，他希望做大量的前期規(guī)劃，并根據(jù)當前的建筑技術(shù)和實踐制定一個五年的建設計劃。
然而這兩種方法可能都不是理想的方式。而持續(xù)架構(gòu)的目標則是彌合兩種方法之間的差距以獲得更好的整體結(jié)果。
2 持續(xù)架構(gòu)的定義
滿足以下六個簡單準則的架構(gòu)就可以被稱為持續(xù)架構(gòu)：?
準則 1 ：用產(chǎn)品思維，而非項目思維來設計架構(gòu)。從產(chǎn)品的角度進行構(gòu)建比單純設計點的解決方案更有效率，更容易讓團隊專注于客戶的需求。
準則 2 ：聚焦質(zhì)量屬性，而不僅僅是功能性需求。質(zhì)量屬性需求驅(qū)動著架構(gòu)。
準則 3 ：在絕對必要的時候再做設計決策。架構(gòu)設計取決于事實，而不是猜 測。設計和實施可能永遠都用不到的功能是無意義的，是對時間和資源的浪費。
準則 4 ：利用“微小的力量”，面向變化來設計架構(gòu)。大的、單體的、緊耦合的組件很難改變。相反，應該使用小且松耦合的軟件元素。
準則 5 ：為構(gòu)建、測試、部署和運營來設計架構(gòu)。大多數(shù)架構(gòu)方法只關(guān)注軟件構(gòu)建活動，但我們認為架構(gòu)師也應該關(guān)注測試、部署和運營，以支持持續(xù)交付。
準則 6 ：在完成系統(tǒng)設計后，開始為團隊做組織建模。團隊的組建方式驅(qū)動著系統(tǒng)的架構(gòu)和設計。
這六項準則、 基本活動和工具可以幫助我們進行架構(gòu)活動并定義軟件架構(gòu)的關(guān)鍵組件，例如：
- 系統(tǒng)上下文
- 影響架構(gòu)的關(guān)鍵功能性需求
- 驅(qū)動架構(gòu)的質(zhì)量屬性
- 架構(gòu)和設計決策
- 架構(gòu)藍圖?
有趣的是，軟件架構(gòu)的組件并不是孤立存在的，而是相互關(guān)聯(lián)的(見圖1)。創(chuàng)建軟件架構(gòu)需要在需求、決策、藍圖甚至最終架構(gòu)工件(可執(zhí)行代碼本身)之間做出一系列權(quán)衡。
▲圖1 軟件架構(gòu)的關(guān)鍵組件
3 持續(xù)架構(gòu)與其他架構(gòu)方法的區(qū)別
那么持續(xù)架構(gòu)與其他架構(gòu)方法有什么不同呢？
首先，我們不認為它是一種方法論，而是一組準則，工具、技術(shù)和思想可以被視為架構(gòu)師有效處理持續(xù)交付項目的工具集。使用這些準則、工具、技術(shù)和思想，沒有預設的順序或流程可遵循， 完全取決于每個架構(gòu)師。我們發(fā)現(xiàn)它們對我們運作過的項目和產(chǎn)品很有效， 而且它們本質(zhì)上是動態(tài)的且具有高適應 性。我們希望讀者會受到啟發(fā)，適應持續(xù)架構(gòu)工具集的內(nèi)容，并用新的想法來擴展工具集，為快速交付健壯且有效的軟件項目提供架構(gòu)支持。
我們堅信利用持續(xù)架構(gòu)方法可以幫助架構(gòu)師處理和消除瓶頸。持續(xù)架構(gòu)的目標是通過在整個過程中系統(tǒng)地應用架構(gòu)視角和準則來加速軟件開發(fā)和交付過程。因此，我們能夠創(chuàng)建一個可持續(xù)的系統(tǒng)，在很長一段時間內(nèi)為組織創(chuàng)造價值。
與大多數(shù)主要關(guān)注軟件交付生命周期( Software Delivery Life Cycle ，SDLC) 的軟件設計和構(gòu)建方面的傳統(tǒng)軟件架構(gòu)方法不同，持續(xù)架構(gòu)為整個過程帶來了架構(gòu)視角，就如準則5 所說，為構(gòu)建、測試、部署和運營來設計架構(gòu)。它的存在盡可能地避免了大架構(gòu)超前綜合征，架構(gòu)團隊不需要再創(chuàng)建復雜的工件來描述技術(shù)功能，軟件開發(fā)人員也不再會陷入等待而無事可做。它幫助架構(gòu)師創(chuàng)建彈性、高適應性且靈活的架構(gòu)，這些架構(gòu)可以快速實現(xiàn)為可執(zhí)行代碼，測試并部署到生產(chǎn)環(huán)境中，以便該系統(tǒng)的用戶能夠提供反饋，而這是對架構(gòu)的最終驗證。
此外，持續(xù)架構(gòu)方法側(cè)重于交付軟件而不是文檔。與傳統(tǒng)的架構(gòu)方法不同，我們將工件視為一種手段，而不是目的。
4 持續(xù)架構(gòu)提供的準則和工具
我們并不是要定義一個具體的架構(gòu)方法論或開發(fā)流程。我們的主要目標是分享一組在實際工作中的核心準則和工具。事實上，應用持續(xù)架構(gòu)是關(guān)于如何理解準則和理念，并把它們應用到自己的環(huán)境中去。這么做的時候，讀者可以自主決定使用哪些工具以及如何解讀必要的活動。?
為了應對當前的挑戰(zhàn)，即在敏捷與持續(xù)交付的實用主義中建立堅固的架構(gòu)基礎，我們已定義了這個基于價值的方法。然而，這并不意味著使用持續(xù)交付是使用持續(xù)架構(gòu)的先決條件。類似地，我們意識到一些公司可能還沒有準備好在各方面都采用敏捷方法論。甚至，即使一個公司已經(jīng)完全投入到敏捷工作中，某些情況下(比如采用第三方軟件包時)，其他方法也可能更為合適(見圖2）。
▲圖2 應用持續(xù)架構(gòu)
這是不是意味著持續(xù)架構(gòu)在這種情況下不可用呢？絕對不是。持續(xù)架構(gòu)的好處之一就是，其工具可以很好地與其他軟件開發(fā)方法融合，不是僅限于敏捷開發(fā)。
持續(xù)架構(gòu)也在兩個維度中運作：規(guī)模和軟件交付速度(見圖3)。軟件交付速度的維度決定著如何在這個加速交付循環(huán)的世界中采用架構(gòu)實踐。盡管規(guī)模維度注重于運營層面，我們相信持續(xù)架構(gòu)準則可以被穩(wěn)定地應用在所有的產(chǎn)品規(guī)模中，只是關(guān)注的層次和需要使用的工具會有所不同。
?▲圖3 持續(xù)架構(gòu)的維度
本文摘編于《持續(xù)架構(gòu)實踐：持續(xù)架構(gòu)實踐：敏捷和DevOps時代下的軟件架構(gòu)》，經(jīng)出版方授權(quán)發(fā)布（書號：9787111717744），轉(zhuǎn)載請保留文章來源。
