作者丨Pierre Pureur

譯者丨崔晧

策劃丨云昭

審校丨梁策、孫淑娟

開篇

創(chuàng)建和維護(hù)可持續(xù)的軟件架構(gòu)對于架構(gòu)師和工程師而言是一項(xiàng)挑戰(zhàn)。為了迎接挑戰(zhàn)，他們需要通過預(yù)先設(shè)計(jì)嘗試滿足每一個(gè)需求，提供每一種功能，并規(guī)劃每一個(gè)系統(tǒng)組件，而這需要在實(shí)施之前完善架構(gòu)設(shè)計(jì)。另一方面，他們也可以讓敏捷開發(fā)引導(dǎo)架構(gòu)設(shè)計(jì)，從而構(gòu)建軟件架構(gòu)的雛形，這樣做可以在前期架構(gòu)規(guī)劃匱乏的情況下，讓開發(fā)團(tuán)隊(duì)開始軟件的功能交付。但遺憾的是，在交付可持續(xù)架構(gòu)方面，這兩種方法都不是百發(fā)百中。

持續(xù)架構(gòu) (CA Continuous Architecture ) 方法在前期設(shè)計(jì)和架構(gòu)雛形之間提供了一種有意義的折衷方案，同時(shí)它也是敏捷、DevOps 和云時(shí)代實(shí)現(xiàn)可持續(xù)架構(gòu)性的有效途徑。

什么是持續(xù)架構(gòu)?

持續(xù)架構(gòu)是一種方法，但不是非常正式的方法論，它可以很容易地與具體環(huán)境相適應(yīng)。

來自：穆拉特·埃代爾 (Murat Erder)、皮埃爾·普雷爾 (Pierre Pureur) 及約恩·伍茲 (Eoin Woods) 所著《持續(xù)架構(gòu)實(shí)踐》(Continuous Architecture In Practice)

如上圖所示，持續(xù)架構(gòu)基于以下六個(gè)簡單原則，描述了在敏捷、DevOps 和云世界中如何不斷完善軟件架構(gòu)：

1. 構(gòu)建產(chǎn)品：將項(xiàng)目演化為產(chǎn)品。構(gòu)建產(chǎn)品的過程比僅僅為項(xiàng)目設(shè)計(jì)解決方案更有效，這樣可以使團(tuán)隊(duì)更多專注于客戶需求。
2. 關(guān)注質(zhì)量，而不是功能需求。通過質(zhì)量驅(qū)動系統(tǒng)架構(gòu)的構(gòu)建。
3. 非必要不設(shè)計(jì)：基于事實(shí)而不是猜測來設(shè)計(jì)架構(gòu)。設(shè)計(jì)和實(shí)現(xiàn)永遠(yuǎn)不會使用的功能只是浪費(fèi)時(shí)間和資源，毫無意義。
4. 擁抱架構(gòu)變化——利用“小力量”。大的、單體的、緊密耦合的組件隨著架構(gòu)發(fā)展很難改變，相反，利用小型、松散耦合的軟件元素，能更加靈活多變地適應(yīng)架構(gòu)變化。
5. 架構(gòu)設(shè)計(jì)需要考慮：構(gòu)建、測試、部署和運(yùn)維等多方面因素。大多數(shù)架構(gòu)方法只關(guān)注軟件構(gòu)建活動，但架構(gòu)師和工程師更需要關(guān)注測試、部署和運(yùn)維，以支持持續(xù)交付。
6. 架構(gòu)設(shè)計(jì)決定組織結(jié)構(gòu)：團(tuán)隊(duì)的組織方式會推動系統(tǒng)的架構(gòu)和設(shè)計(jì)。

這些原則提供了架構(gòu)設(shè)計(jì)的思維方式，但不一定要照抄。以下四項(xiàng)基本內(nèi)容也需要考慮：

1. 關(guān)注質(zhì)量：這是優(yōu)秀架構(gòu)設(shè)計(jì)應(yīng)該著力解決的跨領(lǐng)域需求。
2. 推動架構(gòu)決策：架構(gòu)決策是架構(gòu)活動的主要工作單元。
3. 明晰技術(shù)債務(wù)：對技術(shù)債務(wù)的理解和管理是可持續(xù)架構(gòu)的關(guān)鍵。
4. 實(shí)施反饋循環(huán)：在軟件開發(fā)迭代中了解架構(gòu)決策對開發(fā)的影響。自動化是有效反饋循環(huán)的關(guān)鍵方面。

此外，持續(xù)架構(gòu)包括一個(gè)架構(gòu)“工具箱”，其中囊括一整套經(jīng)過驗(yàn)證的工具，例如決策日志、實(shí)用程序樹和架構(gòu)策略。軟件架構(gòu)師和工程師可以根據(jù)具體環(huán)境，維護(hù)與和擴(kuò)展工具箱里的內(nèi)容。

質(zhì)量是可持續(xù)性的關(guān)鍵

在軟件架構(gòu)的背景下，我們所說的可持續(xù)性到底是什么意思呢?可持續(xù)的軟件架構(gòu)專注于滿足已知的、當(dāng)前的需求，同時(shí)不影響滿足未來、未知需求的能力。也就是適合當(dāng)下面向未來。由于質(zhì)量需求推動架構(gòu)設(shè)計(jì)工作(持續(xù)架構(gòu)原則 2)，因此滿足質(zhì)量需求是創(chuàng)建可持續(xù)架構(gòu)的有效方法。

遺憾的是，質(zhì)量需求并不像功能需求那樣有據(jù)可查，它們可能被記錄為簡單的項(xiàng)目列表：例如， 指出“系統(tǒng)必須快速”或“系統(tǒng)必須具有可擴(kuò)展性”，但不會告訴軟件架構(gòu)師和工程師如何設(shè)計(jì)滿足這些要求。

為了更好地描述質(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 )

該方法依賴于場景中的三個(gè)關(guān)鍵屬性：

• “刺激”描述了系統(tǒng)的任何外部因素，例如來自用戶或者系統(tǒng)的故障，這種刺激會對應(yīng)用場景進(jìn)行重新定義。
• “響應(yīng)”描述了預(yù)期系統(tǒng)對刺激的響應(yīng)。
• “測量”通過提供一個(gè)可測量的目標(biāo)(可以是一個(gè)范圍)來進(jìn)一步定義對刺激的響應(yīng)。

還有幾個(gè)質(zhì)量屬性對于闡述數(shù)字時(shí)代的可持續(xù)軟件架構(gòu)也很重要，它們包括：安全性、可擴(kuò)展性、性能以及彈性。軟件架構(gòu)師和工程師不見得對其有深刻的理解，或者在系統(tǒng)設(shè)計(jì)中優(yōu)先考慮這些因素。然而，質(zhì)量屬性相關(guān)的要求是架構(gòu)設(shè)計(jì)過程的關(guān)鍵組成部分。

架構(gòu)決策和技術(shù)債務(wù)

推動架構(gòu)決策是持續(xù)架構(gòu)中的一項(xiàng)基本活動，因此架構(gòu)決策是從業(yè)者的主要工作單元。幾乎每個(gè)架構(gòu)決策都需要做出權(quán)衡。例如，為優(yōu)化質(zhì)量屬性要求(例如性能)的實(shí)現(xiàn)而做出的決定可能會對其他質(zhì)量屬性(例如可用性或可維護(hù)性)的實(shí)現(xiàn)產(chǎn)生負(fù)面影響。同時(shí)加速軟件系統(tǒng)的交付而做出的決策可能會增加技術(shù)債務(wù)，這些債務(wù)需要在未來的某個(gè)時(shí)候“償還”，并可能影響系統(tǒng)的可持續(xù)性。最后，架構(gòu)決策還會影響系統(tǒng)的成本，可能需要做出妥協(xié)以滿足分配給該系統(tǒng)的預(yù)算。

由于團(tuán)隊(duì)無法控制的約束，權(quán)衡不能做到最佳，并且決策依賴于利益相關(guān)者的反饋。創(chuàng)建和維護(hù)可持續(xù)架構(gòu)的關(guān)鍵使持續(xù)做出架構(gòu)決策并做出有意識的權(quán)衡，同時(shí)還要根據(jù)需要進(jìn)行調(diào)整。

保持對架構(gòu)決策(包括所有相關(guān)約束)的記錄也非常重要，因?yàn)閯?chuàng)建可持續(xù)架構(gòu)本身就是在團(tuán)隊(duì)受約束的情況下為其找到最佳解決方案。因此，記錄團(tuán)隊(duì)的選擇、決策的基本原理以及權(quán)衡決定就顯得尤為重要了。同時(shí)，在最終決策之前還需要評估和記錄逆轉(zhuǎn)決策的成本，因?yàn)闉榱吮３窒到y(tǒng)的可持續(xù)性，未來的某個(gè)時(shí)間點(diǎn)可能需要逆轉(zhuǎn)一些決策。持續(xù)架構(gòu)原則 3 提醒我們，要根據(jù)事實(shí)而非猜測來設(shè)計(jì)架構(gòu)，而事實(shí)可能會隨著時(shí)間改變，從而影響我們已經(jīng)做出的決定。最后，將決策日志與源代碼保存在同一存儲庫中，確保架構(gòu)決策記錄保持最新和準(zhǔn)確。

架構(gòu)策略

選擇和應(yīng)用架構(gòu)策略是解決質(zhì)量屬性要求的絕佳方法。架構(gòu)策略是一種經(jīng)過驗(yàn)證的技術(shù)，起源于卡內(nèi)基梅隆大學(xué)軟件工程學(xué)院 (SEI/CMU) 的研究。架構(gòu)策略是一種設(shè)計(jì)決策，它影響軟件架構(gòu)處理特定質(zhì)量屬性的程度。 架構(gòu)策略通常(但不幸的是并非總是)記錄在目錄中，以促進(jìn)架構(gòu)師對知識和工具的重用。例如，下圖展示用于處理可伸縮性故障的策略：

資料來源：穆拉特·埃代爾 (Murat Erder)、皮埃爾·普雷爾 (Pierre Pureur) 和 約恩·伍茲 (Eoin Woods) 所著：《持續(xù)架構(gòu)實(shí)踐》 (Continuous Architecture In Practice)

在創(chuàng)建和維護(hù)軟件系統(tǒng)時(shí)，使用架構(gòu)策略有助于系統(tǒng)的可持續(xù)性，因?yàn)檫@樣的設(shè)計(jì)是基于高質(zhì)量模塊來架構(gòu)的。

構(gòu)建可持續(xù)的軟件系統(tǒng)

正如上文所提到的，在當(dāng)前敏捷、DevOps 和云計(jì)算的背景下，軟件架構(gòu)師和工程師通常很難在大型前期設(shè)計(jì)和架構(gòu)雛形之間找到一個(gè)好的折衷方案。需要多少次架構(gòu)設(shè)計(jì)才能完成第一次迭代交付并定義質(zhì)量屬性要求?團(tuán)隊(duì)又如何構(gòu)建“前期”架構(gòu)來應(yīng)對不可避免的需求變化?

為了回答這些問題，可持續(xù)架構(gòu)方法建議從“最小可行架構(gòu)”的角度進(jìn)行思考，按照持續(xù)架構(gòu)原則 3“非必要不設(shè)計(jì)”從少量架構(gòu)決策設(shè)計(jì)實(shí)際要求。通過這種方法，團(tuán)隊(duì)可以快速創(chuàng)建一個(gè)可行的軟件系統(tǒng)，該系統(tǒng)可以發(fā)布到生產(chǎn)環(huán)境中。然后繼續(xù)根據(jù)需要做出設(shè)計(jì)決策，以處理新需求和變更。此外，將計(jì)劃、進(jìn)度和決策傳達(dá)給所有系統(tǒng)利益相關(guān)者也很重要。

使用最小可行架構(gòu)策略是一種以更低成本快速將軟件產(chǎn)品推向市場的有效方法。但我們所說的“最小可行架構(gòu)”到底是什么意思呢?簡單來說，創(chuàng)建最小可行架構(gòu)包括以下步驟：

最初的設(shè)計(jì)架構(gòu)用來滿足軟件系統(tǒng)的需求，以便快速創(chuàng)建可行的系統(tǒng)用于生產(chǎn)。

然后，可以不斷擴(kuò)充最小可行架構(gòu)，以滿足隨時(shí)間推移而附加的需求。因此，保持架構(gòu)設(shè)計(jì)的靈活性至關(guān)重要，利用持續(xù)架構(gòu)原則 4(“擁抱架構(gòu)變化——利用小力量”)是實(shí)現(xiàn)這一目標(biāo)的絕佳方式。

軟件架構(gòu)師和工程師在構(gòu)建系統(tǒng)時(shí)傾向于考慮最壞的情況。例如，他們可以通過估計(jì)系統(tǒng)能夠處理的最大事務(wù)數(shù)(交易數(shù))來評估可擴(kuò)展性要求，然后在評估的數(shù)字上再添加一個(gè)“安全限度”。由于客戶所提供交易數(shù)據(jù)有可能是一個(gè)樂觀的猜測，因此，團(tuán)隊(duì)可能會構(gòu)建新系統(tǒng)來處理不切實(shí)際的交易數(shù)量，并給設(shè)計(jì)增加不必要的復(fù)雜性。

所以，最好在架構(gòu)啟動時(shí)就基于實(shí)際估計(jì)的最小值架構(gòu)系統(tǒng)，并根據(jù)實(shí)際數(shù)據(jù)變化調(diào)整架構(gòu)。這種方法創(chuàng)建了一個(gè)更具可持續(xù)性的軟件系統(tǒng)，并且比基于最壞情況設(shè)計(jì)的系統(tǒng)更具成本優(yōu)勢。此外，可持續(xù)架構(gòu)還包括處理系統(tǒng)故障和監(jiān)控關(guān)鍵質(zhì)量屬性(如可擴(kuò)展性和彈性)的機(jī)制。

總結(jié)

軟件架構(gòu)由質(zhì)量屬性要求驅(qū)動，其中包括安全性、可擴(kuò)展性、性能和彈性等，這些因素對于數(shù)字時(shí)代的可持續(xù)軟件架構(gòu)來說非常重要。當(dāng)今的架構(gòu)設(shè)計(jì)是一個(gè)持續(xù)不斷的決策流程，這些決策被不斷重新審視，以支持軟件產(chǎn)品的可持續(xù)交付。在一個(gè)敏捷、云和 DevOps 時(shí)代，架構(gòu)已成為團(tuán)隊(duì)要擔(dān)負(fù)的責(zé)任。通過持續(xù)架構(gòu)方法以及最小可行架構(gòu)策略，或許會讓你離目標(biāo)實(shí)現(xiàn)更進(jìn)一步。

部分內(nèi)容來自 穆拉特·埃代爾 (Murat Erder)、皮埃爾·普雷爾 (Pierre Pureur) 和 約恩·伍茲 (Eoin Woods) 所著《持續(xù)架構(gòu)實(shí)踐》 ( 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)驗(yàn)，10 年分布式架構(gòu)經(jīng)驗(yàn)。曾任惠普技術(shù)專家。樂于分享，撰寫了很多熱門技術(shù)文章，閱讀量超過 60 萬?！斗植际郊軜?gòu)原理與實(shí)踐》作者。

原文標(biāo)題：??Sustainable architectures in a world of Agile??, DevOps, and cloud，作者： Pierre Pureur