軟件架構領域正在爆發一場新的革命。Gartner權威發布2023年十大科技趨勢之一“可持續IT架構”，可持續架構得到越來越多從業人員認同。創建和維護可持續的軟件架構對于架構師和工程師而言也是一項巨大的挑戰。

1 持續架構的引入

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

雖然軟件架構仍然是產品交付成功的重要因素，但它需要發展以應對這樣的環境，在這種環境中，系統通常被開發為一組并行且很大程度上獨立的組件(微服務)。對于這種軟件開發風格，如果像過去一樣采用單一架構師或由一小組技術主管做出所有關鍵決策，最終只會讓架構師負擔過重并導致開發停滯。這種軟件交付方法需要由更多的人以較小的增量來執行架構工作，并且比以往更注重早期的價值交付。

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

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

敏捷開發人員可能希望立即開始建造。相比之下，企業架構師會說，鑒于酒店的復雜歷史，立即著手建造會造成大量浪費。相反，他希望做大量的前期規劃，并根據當前的建筑技術和實踐制定一個五年的建設計劃。

然而這兩種方法可能都不是理想的方式。而持續架構的目標則是彌合兩種方法之間的差距以獲得更好的整體結果。

2 持續架構的定義

滿足以下六個簡單準則的架構就可以被稱為持續架構：?

準則 1 ：用產品思維，而非項目思維來設計架構。從產品的角度進行構建比單純設計點的解決方案更有效率，更容易讓團隊專注于客戶的需求。

準則 2 ：聚焦質量屬性，而不僅僅是功能性需求。質量屬性需求驅動著架構。

準則 3 ：在絕對必要的時候再做設計決策。架構設計取決于事實，而不是猜 測。設計和實施可能永遠都用不到的功能是無意義的，是對時間和資源的浪費。

準則 4 ：利用“微小的力量”，面向變化來設計架構。大的、單體的、緊耦合的組件很難改變。相反，應該使用小且松耦合的軟件元素。

準則 5 ：為構建、測試、部署和運營來設計架構。大多數架構方法只關注軟件構建活動，但我們認為架構師也應該關注測試、部署和運營，以支持持續交付。

準則 6 ：在完成系統設計后，開始為團隊做組織建模。團隊的組建方式驅動著系統的架構和設計。

這六項準則、 基本活動和工具可以幫助我們進行架構活動并定義軟件架構的關鍵組件，例如：

• 系統上下文
• 影響架構的關鍵功能性需求
• 驅動架構的質量屬性
• 架構和設計決策
• 架構藍圖?

有趣的是，軟件架構的組件并不是孤立存在的，而是相互關聯的(見圖1)。創建軟件架構需要在需求、決策、藍圖甚至最終架構工件(可執行代碼本身)之間做出一系列權衡。

▲圖1 軟件架構的關鍵組件

3 持續架構與其他架構方法的區別

那么持續架構與其他架構方法有什么不同呢？

首先，我們不認為它是一種方法論，而是一組準則，工具、技術和思想可以被視為架構師有效處理持續交付項目的工具集。使用這些準則、工具、技術和思想，沒有預設的順序或流程可遵循，  完全取決于每個架構師。我們發現它們對我們運作過的項目和產品很有效，  而且它們本質上是動態的且具有高適應 性。我們希望讀者會受到啟發，適應持續架構工具集的內容，并用新的想法來擴展工具集，為快速交付健壯且有效的軟件項目提供架構支持。

我們堅信利用持續架構方法可以幫助架構師處理和消除瓶頸。持續架構的目標是通過在整個過程中系統地應用架構視角和準則來加速軟件開發和交付過程。因此，我們能夠創建一個可持續的系統，在很長一段時間內為組織創造價值。

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

此外，持續架構方法側重于交付軟件而不是文檔。與傳統的架構方法不同，我們將工件視為一種手段，而不是目的。

4 持續架構提供的準則和工具

我們并不是要定義一個具體的架構方法論或開發流程。我們的主要目標是分享一組在實際工作中的核心準則和工具。事實上，應用持續架構是關于如何理解準則和理念，并把它們應用到自己的環境中去。這么做的時候，讀者可以自主決定使用哪些工具以及如何解讀必要的活動。?

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

▲圖2 應用持續架構

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

持續架構也在兩個維度中運作：規模和軟件交付速度(見圖3)。軟件交付速度的維度決定著如何在這個加速交付循環的世界中采用架構實踐。盡管規模維度注重于運營層面，我們相信持續架構準則可以被穩定地應用在所有的產品規模中，只是關注的層次和需要使用的工具會有所不同。

?▲圖3 持續架構的維度

本文摘編于《持續架構實踐：持續架構實踐：敏捷和DevOps時代下的軟件架構》，經出版方授權發布（書號：9787111717744），轉載請保留文章來源。