作者丨Pierre Pureur
譯者丨崔晧
策劃丨云昭
審校丨梁策、孫淑娟
開篇
創建和維護可持續的軟件架構對于架構師和工程師而言是一項挑戰。為了迎接挑戰，他們需要通過預先設計嘗試滿足每一個需求，提供每一種功能，并規劃每一個系統組件，而這需要在實施之前完善架構設計。另一方面，他們也可以讓敏捷開發引導架構設計，從而構建軟件架構的雛形，這樣做可以在前期架構規劃匱乏的情況下，讓開發團隊開始軟件的功能交付。但遺憾的是，在交付可持續架構方面，這兩種方法都不是百發百中。
持續架構 (CA Continuous Architecture ) 方法在前期設計和架構雛形之間提供了一種有意義的折衷方案，同時它也是敏捷、DevOps 和云時代實現可持續架構性的有效途徑。
什么是持續架構?
持續架構是一種方法，但不是非常正式的方法論，它可以很容易地與具體環境相適應。
來自：穆拉特·埃代爾 (Murat Erder)、皮埃爾·普雷爾 (Pierre Pureur) 及約恩·伍茲 (Eoin Woods) 所著《持續架構實踐》(Continuous Architecture In Practice)
如上圖所示，持續架構基于以下六個簡單原則，描述了在敏捷、DevOps 和云世界中如何不斷完善軟件架構：
- 構建產品：將項目演化為產品。構建產品的過程比僅僅為項目設計解決方案更有效，這樣可以使團隊更多專注于客戶需求。
- 關注質量，而不是功能需求。通過質量驅動系統架構的構建。
- 非必要不設計：基于事實而不是猜測來設計架構。設計和實現永遠不會使用的功能只是浪費時間和資源，毫無意義。
- 擁抱架構變化——利用“小力量”。大的、單體的、緊密耦合的組件隨著架構發展很難改變，相反，利用小型、松散耦合的軟件元素，能更加靈活多變地適應架構變化。
- 架構設計需要考慮：構建、測試、部署和運維等多方面因素。大多數架構方法只關注軟件構建活動，但架構師和工程師更需要關注測試、部署和運維，以支持持續交付。
- 架構設計決定組織結構：團隊的組織方式會推動系統的架構和設計。
這些原則提供了架構設計的思維方式，但不一定要照抄。以下四項基本內容也需要考慮：
- 關注質量：這是優秀架構設計應該著力解決的跨領域需求。
- 推動架構決策：架構決策是架構活動的主要工作單元。
- 明晰技術債務：對技術債務的理解和管理是可持續架構的關鍵。
- 實施反饋循環：在軟件開發迭代中了解架構決策對開發的影響。自動化是有效反饋循環的關鍵方面。
此外，持續架構包括一個架構“工具箱”，其中囊括一整套經過驗證的工具，例如決策日志、實用程序樹和架構策略。軟件架構師和工程師可以根據具體環境，維護與和擴展工具箱里的內容。
質量是可持續性的關鍵
在軟件架構的背景下，我們所說的可持續性到底是什么意思呢?可持續的軟件架構專注于滿足已知的、當前的需求，同時不影響滿足未來、未知需求的能力。也就是適合當下面向未來。由于質量需求推動架構設計工作(持續架構原則 2)，因此滿足質量需求是創建可持續架構的有效方法。
遺憾的是，質量需求并不像功能需求那樣有據可查，它們可能被記錄為簡單的項目列表：例如， 指出“系統必須快速”或“系統必須具有可擴展性”，但不會告訴軟件架構師和工程師如何設計滿足這些要求。
為了更好地描述質量要求，我們可以使用 ATAM Scenarios 和 Utility Trees 方法，具體如下所示：
資料來源：穆拉特·埃代爾 (Murat Erder) 和 皮埃爾·普雷爾 (Pierre Pureur) 所著：《持續架構：基于敏捷和云中的可持續架構》( Continuous Architecture: Sustainable Architecture In An Agile and Cloud-Centric World )
該方法依賴于場景中的三個關鍵屬性：
- “刺激”描述了系統的任何外部因素，例如來自用戶或者系統的故障，這種刺激會對應用場景進行重新定義。
- “響應”描述了預期系統對刺激的響應。
- “測量”通過提供一個可測量的目標(可以是一個范圍)來進一步定義對刺激的響應。
還有幾個質量屬性對于闡述數字時代的可持續軟件架構也很重要，它們包括：安全性、可擴展性、性能以及彈性。軟件架構師和工程師不見得對其有深刻的理解，或者在系統設計中優先考慮這些因素。然而，質量屬性相關的要求是架構設計過程的關鍵組成部分。
架構決策和技術債務
推動架構決策是持續架構中的一項基本活動，因此架構決策是從業者的主要工作單元。幾乎每個架構決策都需要做出權衡。例如，為優化質量屬性要求(例如性能)的實現而做出的決定可能會對其他質量屬性(例如可用性或可維護性)的實現產生負面影響。同時加速軟件系統的交付而做出的決策可能會增加技術債務，這些債務需要在未來的某個時候“償還”，并可能影響系統的可持續性。最后，架構決策還會影響系統的成本，可能需要做出妥協以滿足分配給該系統的預算。
由于團隊無法控制的約束，權衡不能做到最佳，并且決策依賴于利益相關者的反饋。創建和維護可持續架構的關鍵使持續做出架構決策并做出有意識的權衡，同時還要根據需要進行調整。
保持對架構決策(包括所有相關約束)的記錄也非常重要，因為創建可持續架構本身就是在團隊受約束的情況下為其找到最佳解決方案。因此，記錄團隊的選擇、決策的基本原理以及權衡決定就顯得尤為重要了。同時，在最終決策之前還需要評估和記錄逆轉決策的成本，因為為了保持系統的可持續性，未來的某個時間點可能需要逆轉一些決策。持續架構原則 3 提醒我們，要根據事實而非猜測來設計架構，而事實可能會隨著時間改變，從而影響我們已經做出的決定。最后，將決策日志與源代碼保存在同一存儲庫中，確保架構決策記錄保持最新和準確。
架構策略
選擇和應用架構策略是解決質量屬性要求的絕佳方法。架構策略是一種經過驗證的技術，起源于卡內基梅隆大學軟件工程學院 (SEI/CMU) 的研究。架構策略是一種設計決策，它影響軟件架構處理特定質量屬性的程度。 架構策略通常(但不幸的是并非總是)記錄在目錄中，以促進架構師對知識和工具的重用。例如，下圖展示用于處理可伸縮性故障的策略：
資料來源：穆拉特·埃代爾 (Murat Erder)、皮埃爾·普雷爾 (Pierre Pureur) 和 約恩·伍茲 (Eoin Woods) 所著：《持續架構實踐》 (Continuous Architecture In Practice)
在創建和維護軟件系統時，使用架構策略有助于系統的可持續性，因為這樣的設計是基于高質量模塊來架構的。
構建可持續的軟件系統
正如上文所提到的，在當前敏捷、DevOps 和云計算的背景下，軟件架構師和工程師通常很難在大型前期設計和架構雛形之間找到一個好的折衷方案。需要多少次架構設計才能完成第一次迭代交付并定義質量屬性要求?團隊又如何構建“前期”架構來應對不可避免的需求變化?
為了回答這些問題，可持續架構方法建議從“最小可行架構”的角度進行思考，按照持續架構原則 3“非必要不設計”從少量架構決策設計實際要求。通過這種方法，團隊可以快速創建一個可行的軟件系統，該系統可以發布到生產環境中。然后繼續根據需要做出設計決策，以處理新需求和變更。此外，將計劃、進度和決策傳達給所有系統利益相關者也很重要。
使用最小可行架構策略是一種以更低成本快速將軟件產品推向市場的有效方法。但我們所說的“最小可行架構”到底是什么意思呢?簡單來說，創建最小可行架構包括以下步驟：
最初的設計架構用來滿足軟件系統的需求，以便快速創建可行的系統用于生產。
然后，可以不斷擴充最小可行架構，以滿足隨時間推移而附加的需求。因此，保持架構設計的靈活性至關重要，利用持續架構原則 4(“擁抱架構變化——利用小力量”)是實現這一目標的絕佳方式。
軟件架構師和工程師在構建系統時傾向于考慮最壞的情況。例如，他們可以通過估計系統能夠處理的最大事務數(交易數)來評估可擴展性要求，然后在評估的數字上再添加一個“安全限度”。由于客戶所提供交易數據有可能是一個樂觀的猜測，因此，團隊可能會構建新系統來處理不切實際的交易數量，并給設計增加不必要的復雜性。
所以，最好在架構啟動時就基于實際估計的最小值架構系統，并根據實際數據變化調整架構。這種方法創建了一個更具可持續性的軟件系統，并且比基于最壞情況設計的系統更具成本優勢。此外，可持續架構還包括處理系統故障和監控關鍵質量屬性(如可擴展性和彈性)的機制。
總結
軟件架構由質量屬性要求驅動，其中包括安全性、可擴展性、性能和彈性等，這些因素對于數字時代的可持續軟件架構來說非常重要。當今的架構設計是一個持續不斷的決策流程，這些決策被不斷重新審視，以支持軟件產品的可持續交付。在一個敏捷、云和 DevOps 時代，架構已成為團隊要擔負的責任。通過持續架構方法以及最小可行架構策略，或許會讓你離目標實現更進一步。
部分內容來自 穆拉特·埃代爾 (Murat Erder)、皮埃爾·普雷爾 (Pierre Pureur) 和 約恩·伍茲 (Eoin Woods) 所著《持續架構實踐》 ( Continuous Architecture In Practice)以及 穆拉特·埃代爾 (Murat Erder) 和 皮埃爾·普雷爾 (Pierre Pureur) 所著《持續架構：基于敏捷和云中的可持續架構》( Continuous Architecture: Sustainable Architecture In An Agile and Cloud-Centric World )
譯者介紹
崔皓，51CTO 社區編輯，資深架構師，擁有 18 年的軟件開發和架構經驗，10 年分布式架構經驗。曾任惠普技術專家。樂于分享，撰寫了很多熱門技術文章，閱讀量超過 60 萬。《分布式架構原理與實踐》作者。
原文標題：??Sustainable architectures in a world of Agile??, DevOps, and cloud，作者： Pierre Pureur
