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