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