00-軟件架構(gòu)權(quán)衡-我們?yōu)槭裁匆约叭绾芜M行權(quán)衡？

對于“軟件架構(gòu)”這個詞有很多定義和含義。而且，“軟件開發(fā)”、“軟件設(shè)計”和“軟件架構(gòu)”這三個概念之間存在相當大的重疊，它們在許多方面相互交融。

從核心上看，可以將軟件架構(gòu)視為在構(gòu)建應(yīng)用程序時，對不同選擇進行權(quán)衡的學(xué)科。

1 為什么需要權(quán)衡以及我們?yōu)槭裁丛谝猓?/span>

我們在構(gòu)建軟件時必須進行權(quán)衡的原因，與其他學(xué)科中的權(quán)衡原因相同。計算系統(tǒng)是復(fù)雜的，復(fù)雜性越高，實現(xiàn)特定系統(tǒng)的全部目標的方式就越微妙。這些目標：

• 既可以是功能性的（例如提供用戶自助服務(wù)的能力、處理特定事件、接受某些輸入并產(chǎn)生輸出）
• 也可以是非功能性的（例如每秒處理數(shù)百萬個請求、實現(xiàn)零信任安全、提供100毫秒以下的響應(yīng)時間）

如金融投資中，人們普遍理解風險與收益之間的權(quán)衡。投資越風險，潛在的財務(wù)回報越大。投資越安全，預(yù)期收益就越小。

同樣的規(guī)則也適用于計算，特別是在設(shè)計分布式應(yīng)用程序時。許多組織遇到的問題不是他們必須做出某些讓步或權(quán)衡，而是大多數(shù)組織要么對自己所做的權(quán)衡不了解，要么缺乏系統(tǒng)的、明確的和有效的方法來進行這些權(quán)衡。

本“架構(gòu)權(quán)衡”系列的目的是闡明在軟件架構(gòu)的不同原則之間進行權(quán)衡時的決策過程以及此類決策的具體技術(shù)影響。

2 我們在權(quán)衡什么？

如上所述，大多數(shù)與系統(tǒng)和應(yīng)用程序架構(gòu)相關(guān)的決策都涉及某種程度的權(quán)衡。

既然我們已經(jīng)知道為什么需要討論、權(quán)衡和有意識地思考架構(gòu)權(quán)衡，我們可以談?wù)勎覀儗嶋H在系統(tǒng)和應(yīng)用程序中進行權(quán)衡的方面。

這些架構(gòu)權(quán)衡有時分為兩大類：

• 系統(tǒng)的基本架構(gòu)特性有關(guān)（如可擴展性與簡潔性）
• 與具體技術(shù)、機制和架構(gòu)風格有關(guān)（如同步通信與異步通信、Kafka與消息總線等）。前者更為廣泛的權(quán)衡類別也決定了更具體的權(quán)衡

本文重點討論第一類架構(gòu)權(quán)衡——基礎(chǔ)架構(gòu)特性。

因此，當我們談?wù)摷軜?gòu)權(quán)衡時，我們實際上是在討論我們希望支持哪些架構(gòu)特性并將其納入我們的主要目標。另一方面，我們也在識別那些我們有意識地決定不太關(guān)注或完全放棄的架構(gòu)特性，以便更加重視那些我們認為更重要的特性。

下面是一些架構(gòu)特性和一些常見的權(quán)衡場景。

3 架構(gòu)特性

當談?wù)撓到y(tǒng)或應(yīng)用程序架構(gòu)的固有或基礎(chǔ)特性時，我們實際上是指一組關(guān)鍵屬性，這些屬性定義了特定的系統(tǒng)或應(yīng)用程序。以下是這些特性的一小部分示例。這絕不是一個詳盡的列表，還有許多其他的架構(gòu)特性。

• 可擴展性
• 可觀測性
• 可審計性
• 彈性
• 響應(yīng)性
• 可測試性
• 互操作性
• 可維護性
• 可支持性

這些特性有時被稱為“系統(tǒng)屬性”、“架構(gòu)屬性”或干脆稱為“后綴-ility”屬性。

這些系統(tǒng)特性或?qū)傩哉Э粗滤坪跏仟毩⒌模珜嶋H上，它們中的許多是相互交織的，可能有直接或反向關(guān)系。

4 互操作性 vs 可擴展性、彈性和響應(yīng)性

讓我們以互操作性為例。為了使系統(tǒng)具備互操作性，它需要能夠輕松地與其他系統(tǒng)進行交互和通信。這通常意味著所有這些系統(tǒng)都需要使用通用協(xié)議。它們需要使用共同商定的標準，并且這些標準還需要設(shè)計得易于將來的系統(tǒng)也能相對輕松地“插入”到這種通信中。

然而，如果一個系統(tǒng)優(yōu)先考慮互操作性，這很可能會影響系統(tǒng)的可擴展性。

舉個具體的例子，假設(shè)現(xiàn)有的應(yīng)用程序使用REST協(xié)議（依賴HTTP）進行通信。假設(shè)我們要引入一個新系統(tǒng)。為了使這個新應(yīng)用程序與現(xiàn)有的應(yīng)用程序互操作，我們決定該應(yīng)用程序的所有進出通信都通過REST/HTTP進行。這看起來很合理。

然而，如果將新系統(tǒng)的通信限制在依賴HTTP上，可能會限制其響應(yīng)能力和可擴展性，尤其是在需要處理大量請求的情況下。假設(shè)這個新系統(tǒng)需要每秒處理數(shù)百萬個請求，并且是異步的（即調(diào)用者無需等待應(yīng)用程序確認其已處理請求）。這種情況下，由于需要異步通信且Kafka協(xié)議（理論上）比HTTP開銷更小，這種場景可能更適合使用事件驅(qū)動技術(shù)如Kafka。

換句話說，在這種情況下，互操作性與響應(yīng)性以及可擴展性呈反比關(guān)系。

5  簡單性、易上手性和可支持性 vs 響應(yīng)性

另一個可能不太技術(shù)性、更具組織性的權(quán)衡發(fā)生在決定以易于支持作為主要架構(gòu)驅(qū)動因素時。這可能意味著使用技術(shù)團隊熟悉的技術(shù)。這也可能意味著使用行業(yè)內(nèi)廣泛使用和已知的技術(shù)和范式，以便新團隊成員可以更快更高效地上手。

將可支持性作為首要任務(wù)聽起來是顯而易見的，因為誰不想要一個易于理解、支持并且易于向新開發(fā)人員介紹的系統(tǒng)呢？然而，仍然存在成本和權(quán)衡。

基于技術(shù)或范式的選擇是否為大量專業(yè)人員所熟知，可能會阻礙架構(gòu)的許多其他特性?？蓴U展性、響應(yīng)性、彈性、可用性、安全性以及系統(tǒng)的許多其他方面很可能會被放在第二位。

例如，考慮需要設(shè)計一個處理和存儲交易性和強關(guān)系數(shù)據(jù)的金融應(yīng)用程序。假設(shè)實施該應(yīng)用程序的團隊熟悉NoSQL數(shù)據(jù)存儲如MongoDB。雖然MongoDB是一個適合松散關(guān)聯(lián)的文檔型數(shù)據(jù)的優(yōu)秀選擇，但它不適合具有嚴格和復(fù)雜關(guān)系的數(shù)據(jù)。

對于不同實體之間具有復(fù)雜關(guān)系且需要臨時復(fù)雜查詢來檢索這些數(shù)據(jù)的數(shù)據(jù)，通常不太適合像MongoDB這樣的存儲。這類數(shù)據(jù)通常更適合“傳統(tǒng)”的關(guān)系數(shù)據(jù)庫如Postgres或MySQL。

如果我們將可支持性作為這個應(yīng)用程序的主要架構(gòu)驅(qū)動因素，最終很可能會導(dǎo)致應(yīng)用程序失敗，并引發(fā)一系列挑戰(zhàn)，最終導(dǎo)致應(yīng)用程序完全無法擴展，數(shù)據(jù)庫成為瓶頸（這是常見的問題）。

6 可維護性 vs 彈性和容錯性

一般而言，系統(tǒng)越簡單、移動部件越少，越容易維護。使用的技術(shù)和部署環(huán)境越少，系統(tǒng)運行和維護的速度和難度越低。

例如，在托管云運行服務(wù)中運行單實例應(yīng)用程序要比分布在不同節(jié)點、不同集群、云區(qū)域和地區(qū)的分布式集群應(yīng)用程序更容易維護。一些組織甚至通過跨多個云環(huán)境部署其系統(tǒng)來確保業(yè)務(wù)連續(xù)性、容錯性和災(zāi)難恢復(fù)（迅速流行但有些爭議的多云模式）。

由于每個云（Azure、AWS、GCP、IBM、Oracle等）提供商都有一套獨特的功能、部署模型和機制，在多個云上維護一組應(yīng)用程序成為一個顯著挑戰(zhàn)（通常是無法維持的）。

7 找到平衡點

上述的三個架構(gòu)權(quán)衡示例可能更偏向極端情況。然而，它們代表了許多團隊和組織在規(guī)劃和選擇正確的架構(gòu)權(quán)衡路徑時所面臨的一些非?，F(xiàn)實的挑戰(zhàn)。

好消息是，您不必在二者之間做出選擇。軟件架構(gòu)權(quán)衡以及軟件開發(fā)的現(xiàn)實要更加復(fù)雜，實際上是一個選擇的漸變。在這里，您可以選擇在一定程度上實現(xiàn)可擴展性，同時在一定程度上實現(xiàn)簡單性和互操作性。

關(guān)鍵在于如何找到不同架構(gòu)特性之間的平衡，以及如何做出知情的、有意識的選擇。

8 有意識地了解架構(gòu)權(quán)衡

如我們在開頭所說，許多，甚至可以說大多數(shù)組織，都是無意識地做出權(quán)衡。這往往導(dǎo)致這些組織做出錯誤的權(quán)衡，給其業(yè)務(wù)和底線帶來長期且不利的影響。

依賴數(shù)字系統(tǒng)的企業(yè)必須有一個適當?shù)挠媱澓土鞒虂碜龀鲕浖軜?gòu)和技術(shù)決策以及權(quán)衡。在沒有建立正確的架構(gòu)權(quán)衡意識的情況下，這些組織承擔著不合理的風險，其影響和可能顯著減緩組織進展的概率很大，在最壞的情況下甚至可能造成無法修復(fù)的損害。

接下來的部分將討論如何進行架構(gòu)權(quán)衡的推理和規(guī)劃，以及一些具體和常見的情況。

01-軟件架構(gòu)權(quán)衡-無意識決策的問題

0 前言

錯誤的技術(shù)決策常常會回過頭來困擾我們，原因并不在于決策本身是錯誤的，而是因為做出該決策的人并未充分理解其全部影響，或更常見的，決策者甚至不知道自己在做決策。這是一種無意識的決策。換句話說，問題核心在于缺乏意識或缺乏決策的謹慎。稍后詳細討論這問題。

先澄清“技術(shù)決策”含義。這些決策涉及編碼/實現(xiàn)、軟件設(shè)計、架構(gòu)、供應(yīng)商選擇和與第三方集成，還有非技術(shù)性的決策——即產(chǎn)品和業(yè)務(wù)決策，同樣重要。本文以及整個架構(gòu)權(quán)衡系列重點關(guān)注技術(shù)方面及其與業(yè)務(wù)的交集。

先統(tǒng)一術(shù)語：

• MVP（最小可行產(chǎn)品）
• POC（概念驗證）
• Monolith（單體架構(gòu)）：獨立應(yīng)用程序，執(zhí)行全部或大部分功能
• Serverless（無服務(wù)器）：應(yīng)用程序運行時和部署主要由云管理
• Microservices（微服務(wù)）：細粒度、解耦、獨立部署的應(yīng)用程序，每個應(yīng)用程序負責特定功能

雖然本文主要提到初創(chuàng)企業(yè)，但大多數(shù)內(nèi)容適用于任何技術(shù)團隊或組織。

1 這是什么？

如何增強對技術(shù)決策的信心是一個很少被討論但絕對關(guān)鍵的話題，它對建立一個能夠隨著組織擴展和增長而提供服務(wù)的健康技術(shù)和架構(gòu)戰(zhàn)略至關(guān)重要。

看典型初創(chuàng)企業(yè)的生命周期，這個企業(yè)經(jīng)受住市場挑戰(zhàn)，并踏上增長道路。有許多流行的模型描述了這一生命周期的不同階段，每個模型都有其獨特的視角。

下面的心理模型幫助直觀理解這種生命周期，重點是決策通常在哪些階段做出。初創(chuàng)企業(yè)的生命周期：

上述顯示，我們在MVP階段開始做出大部分長期的技術(shù)決策。

注意，這是開始做出這類決策的階段。決策過程永遠不會停止。MVP階段（及之后）的決策與POC階段（及之前）的決策的區(qū)別在于：POC階段的決策通常是臨時的。它們只是為盡快推出某種產(chǎn)品的初步雛形。通常，這些產(chǎn)品甚至不是完全功能性的，而更多是展示最終結(jié)果的視覺表示。

MVP階段的技術(shù)決策必須開始關(guān)注。這就是技術(shù)決策意識發(fā)揮作用的地方。該階段的技術(shù)決策通常產(chǎn)生長期影響，因為這些決策將成為后續(xù)決策的基礎(chǔ)，并將影響組織發(fā)展方向（至少在技術(shù)方面）。

2 錯誤的決策總是問題的根源嗎？

記住，我在開頭提到的問題不一定是決策本身的問題，而是缺乏意識和決策的謹慎嗎？盡管這可能看起來違反直覺，但錯誤決策常?？梢宰钚I(yè)務(wù)影響來解決。若能及時、流暢識別并解決問題，并有一個明確流程來調(diào)整決策，其影響不會像原本那么劇烈。

這只有在決策是以有意識的方式做出，并意識到?jīng)Q策正在被做出及其方式時才會發(fā)生。

3 示例

假設(shè)一個初創(chuàng)企業(yè)處早期MVP階段。團隊正開發(fā)SaaS，該產(chǎn)品聚合某種數(shù)據(jù)并將其暴露給外部。

因此，團隊須決定如何部署SaaS?；A(chǔ)設(shè)施咋樣的？應(yīng)用程序咋構(gòu)建？有許多方式構(gòu)建應(yīng)用程序和部署產(chǎn)品，選擇很多。

團隊面臨選擇（假設(shè)使用AWS作為云提供商）：

3.1 單體架構(gòu)

將服務(wù)結(jié)構(gòu)化為單體應(yīng)用程序。將所有功能都放在一起。部署在托管的容器編排服務(wù)中：

• 一個數(shù)據(jù)庫
• 一個應(yīng)用程序

3.2 微服務(wù)

從一開始就將服務(wù)設(shè)計為由微服務(wù)組成。有多個服務(wù)和多個數(shù)據(jù)庫。所有內(nèi)容都部署在容器編排服務(wù)中。

3.3 無服務(wù)器/函數(shù)即服務(wù)

目前非常流行的方法?？捎肁WS Lambda運行應(yīng)用程序，使用DynamoDB作為數(shù)據(jù)庫。AWS負責運行所有這些的重任。

4 指導(dǎo)方針

團隊應(yīng)選哪種方案？選擇的影響是啥？影響多大？應(yīng)投入多少精力分析每種選擇？這些都是隱藏在行間的問題。此外，在每個選擇中還有更多細節(jié)選擇！

現(xiàn)在正是關(guān)鍵時刻，團隊需做出一個有意識的和有理由的選擇。注意，這不一定是正確選擇，因為可能有多個正確選擇，并且“正確”可能隨未來更多背景的變化而改變。

通常，團隊會隱含、無意識或在不了解影響的情況下做出決定。

那團隊該咋做？他們咋確保他們的選擇能最好服務(wù)于組織？幸好我們站在牛頓肩膀上，請遵循如下指導(dǎo)方針：

4.1 保持記錄

若你從本文中只學(xué)到一件事，那必須是這點?？雌饋磉@應(yīng)該是最容易做到的事情，但我見過的團隊，很少能認真記錄其技術(shù)決策。

我理解，文檔很枯燥無趣，尤其當你專注于構(gòu)建下一個大項目時。然而，它只需要很少時間，而清晰記錄技術(shù)決策的巨大好處顯而易見，它將不斷地為你帶來十倍、百倍、千倍回報。

每當面臨技術(shù)決策并做任何重要選擇時，記錄何時及為何做出該選擇。不需要是一份龐大的文件或復(fù)雜東西。

以下內(nèi)容即可：

? 做出決定的時間

? 選擇有哪些

? 每種選擇的優(yōu)缺點

? 為何選擇特定選項

? 潛在擔憂

在一個成熟團隊/組織中，你可能需要使用更正式東西，如ADR（架構(gòu)決策記錄）。然而，對MVP級項目，上述內(nèi)容足夠。

這樣的記錄將允許你回顧并理解為何做出這些決策，并在以后防止混淆。它還將幫助你及早發(fā)現(xiàn)這些決策的任何陷阱。這引出下一要點：

4.2 定期重新審視你的決策

做出“正確”選擇往往不如做出“有意識”選擇重要，因為今天的“正確”選擇可能是明年的“錯誤”選擇。定期重審技術(shù)決策，重新評估，與團隊一起頭腦風暴，你將始終掌握組織技術(shù)狀態(tài)的脈搏。

讓這些成為定期的節(jié)奏。每月進行一兩次會議?；蛎績蓚€月一次會議?；蛎考径纫淮稳鞎h。無論哪種方式，重要的你要持續(xù)進行這些會議，并承諾將其作為定期的脈搏檢查，以識別哪些技術(shù)解決方案仍然有效，哪些無效。

其實還有很多...

4.3 始終提出問題（尤其是當出現(xiàn)問題時）

質(zhì)疑你的技術(shù)選擇。根據(jù)公司目標進行預(yù)測，并查看這些目標如何與當前的技術(shù)狀態(tài)對齊。是否能改進？咋改進？

在這里最有幫助的是對產(chǎn)品遇到的技術(shù)問題有敏銳意識。是否存在可擴展性問題？生產(chǎn)的錯誤率高嗎？

用戶等待20s才能加載網(wǎng)站？基礎(chǔ)設(shè)施每周一、周四都崩潰？

這些問題是最好的指示，表明要做出改變了，并且需要重新審視和/或做出一些技術(shù)決策。

關(guān)注這些問題，記錄它們，并詢問咋解決它們（希望也能記錄下你的發(fā)現(xiàn)）是開始這一過程的好方法。

5 結(jié)論

最終，你無法保證今天做出的決策或技術(shù)選擇能永遠為組織服務(wù)。在技術(shù)和業(yè)務(wù)需求不斷變化的環(huán)境中，組織轉(zhuǎn)向、市場趨勢和其他因素的影響下，很難準確預(yù)測這些選擇將如何塑造組織的未來技術(shù)狀態(tài)。

然而，制定一個清晰、直觀和簡化的決策過程，可以優(yōu)化這些決策，并在環(huán)境變化時提供調(diào)整和改變的途徑。

這個過程將確保我們所做的架構(gòu)權(quán)衡在我們所處的時間和條件下是正確的。

02-軟件架構(gòu)權(quán)衡-架構(gòu)特性

本系列00文重點討論啥是架構(gòu)權(quán)衡以及為什么它們很重要。01文，闡述了在軟件架構(gòu)中進行有意識決策過程的必要性。

本文總結(jié)討論具體的架構(gòu)特性及為啥理解這些特性對系統(tǒng)至關(guān)重要。為做到這點，需理解：

• 啥是架構(gòu)特性
• 選擇關(guān)注某一特性有時會迫使我們在另一特性上做出權(quán)衡

換句話說，架構(gòu)特性是指你的系統(tǒng)總體能力的具體方面，這就是架構(gòu)的“ability”（屬性），你很快就會明白為什么。

以下是一些常見的架構(gòu)特性。這絕不是一個詳盡的列表——只是一些你在設(shè)計和構(gòu)建應(yīng)用程序時最常遇到的特性，也是我在全職職業(yè)生涯和咨詢實踐中最常見的特性。

我試圖在這里做的是識別特性，指出它在何時最有可能重要，關(guān)注它時我們在做什么權(quán)衡，以及一些實現(xiàn)該特性的方法。當然，這一切都是非常高層次的，每一個具體點上還有更多內(nèi)容可以討論。

1 架構(gòu)特性

1.1 可審計性（Auditability）

這是啥？

你的系統(tǒng)在運行，事件在流轉(zhuǎn)。用戶啟動動作并導(dǎo)致事情發(fā)生。許多情況下，你希望有一個明確記錄，記錄這些事情的發(fā)生。即你希望記錄某個用戶在特定時間發(fā)起了某個特定的動作，以及該動作的具體情況。

何時重要？

• 金融等受監(jiān)管行業(yè)
• 遵守內(nèi)部和外部標準（ISO、PCI、SOC、SOX）
• 出于安全原因，以便你可以識別和調(diào)查未經(jīng)授權(quán)的活動

我們在做啥權(quán)衡

• 系統(tǒng)的復(fù)雜性增加
• 測試變得更復(fù)雜，因為你需要測試審計事件在整個系統(tǒng)中是否被正確記錄

一些實現(xiàn)方式

• 將審計事件日志與應(yīng)用日志分開記錄。這可以存入數(shù)據(jù)庫、獨立日志流、第三方日志聚合系統(tǒng)或另一種永久云存儲（例如AWS的S3）。
• 制定明確的數(shù)據(jù)保留和清除策略（金融數(shù)據(jù)通常需要保留7年）。
• 注意成本——大部分數(shù)據(jù)可以移到較少頻繁使用的存儲層（冷存儲），因為這些數(shù)據(jù)可能不需要即時檢索。

1.2 可觀測性（Observability）

這是什么？ 通常，人們對監(jiān)控和可觀測性之間的區(qū)別感到困惑。確實，這兩個概念有很多重疊之處，常常被互換使用。一個常見的區(qū)分方式是，可觀測性指的是在問題發(fā)生前識別系統(tǒng)潛在問題的能力。監(jiān)控是通過日志、指標、跟蹤、警報和儀表板查看系統(tǒng)內(nèi)部發(fā)生的情況的能力。監(jiān)控是實現(xiàn)可觀測性的一部分。

在本文中，我將監(jiān)控和可觀測性都納入可觀測性的范疇。

何時重要？

任何實際系統(tǒng)都需要一定程度的可觀測性。系統(tǒng)越復(fù)雜，使用頻率越高，可觀測機制就越復(fù)雜。

我們在做啥權(quán)衡

• 可觀測性增加系統(tǒng)復(fù)雜性
• 根據(jù)可觀測性的程度和部署的機制，它也可能影響應(yīng)用性能
• 成本——實現(xiàn)第三方/現(xiàn)成的解決方案 or 內(nèi)部構(gòu)建
• 可擴展性——可觀測系統(tǒng)需要隨業(yè)務(wù)應(yīng)用擴展。這是一個常見但易被忽視的問題，特別是內(nèi)部/本地部署的可觀測系統(tǒng)

一些實現(xiàn)方式

• 使用云原生或第三方APM（應(yīng)用性能監(jiān)控）和可觀測工具，如Datadog、New Relic、Dynatrace、Honeycomb等
• 確保你的應(yīng)用記錄重要信息
• 對分布式系統(tǒng)（如微服務(wù)）——使用跟蹤來保持跨多個系統(tǒng)的請求的可見性
• 使用AIOps工具（通常作為上述第三方解決方案的一部分）發(fā)現(xiàn)和預(yù)測應(yīng)用行為
• 使用OpenTelemetry等開放標準
• 確保根據(jù)暴露的指標、日志和跟蹤配置警報、儀表板、報告。換句話說，確保有可監(jiān)控和實時操作的有意義的工件。

1.3 可伸縮性/彈性（Scalability/Elasticity）

這是什么？

應(yīng)用程序支持增加的流量/更多請求或用戶的能力。你的系統(tǒng)如何從每秒10次交易（TPS）調(diào)整到每秒1000次交易？當用戶群從1萬增長到100萬時會發(fā)生什么？

在某些情況下，可伸縮性與彈性的概念可以互換使用，而在其他情況下，這兩個概念表示系統(tǒng)的不同方面。準確地說：

• 可伸縮性，指系統(tǒng)整體在較長時間內(nèi)適應(yīng)不斷增長的負載的能力
• 彈性，指系統(tǒng)在特定時間內(nèi)適應(yīng)波動負載/流量的能力

為簡化，這里將這兩個概念合并。

何時重要？

• 如果你的應(yīng)用預(yù)期會隨著時間的推移而增長，需考慮可擴展性。這適用于大多數(shù)部署在生產(chǎn)環(huán)境中面向外部用戶的系統(tǒng)
• 唯一不需要擔心可擴展性的情況是，如果你知道系統(tǒng)使用會被限制在一定范圍內(nèi)（例如內(nèi)部公司應(yīng)用）。這包括用戶群已知非常小且不需要增長的生產(chǎn)應(yīng)用

我們在做啥權(quán)衡

• 系統(tǒng)的復(fù)雜性增加
• 可部署性變得更困難。處理一個容器的部署要比處理1000個容器容易得多——即使你在使用容器編排框架。
• 系統(tǒng)越可擴展，維護可觀測性就越困難，因為需要觀察、跟蹤和調(diào)查的組件更多。
• 可測試性可能更具挑戰(zhàn)性，測試用例需要覆蓋應(yīng)用的分布式特性

一些實現(xiàn)方式

• 使用容器編排系統(tǒng)（如Kubernetes）動態(tài)調(diào)整所需計算水平（容器數(shù)量）
• 利用云環(huán)境中的無服務(wù)器服務(wù)，大部分擴展由云本身負責
• 開發(fā)應(yīng)用使其易于擴展。對于“單線程”運行時（如Node），意味著不要阻塞事件循環(huán)超過必要時間。對于多線程應(yīng)用，意味著以最佳方式利用并發(fā)（避免死鎖，使用非阻塞鎖等）
• 盡可能采用無狀態(tài)范式，只有在必要時才維護和傳遞狀態(tài)。
• 通過頻繁運行負載、壓力和流量測試來識別瓶頸。
• 優(yōu)先擴展橫向伸縮而非縱向伸縮

1.4 響應(yīng)性（Responsiveness）

這是什么？

應(yīng)用程序的響應(yīng)能力是其在合理時間內(nèi)對調(diào)用方提供某種響應(yīng)的能力——即使在應(yīng)用程序負載顯著增加時。換句話說，應(yīng)用能夠處理并響應(yīng)用戶操作，而用戶不會感到延遲。這適用于前端和后端應(yīng)用。

何時重要？

• 當應(yīng)用是面向用戶時——即實際有用戶在等待某些事情發(fā)生。
• 當你的用例對應(yīng)用的響應(yīng)性沒有太多容忍度時。例如，某人在銀行網(wǎng)站申請貸款，可能對延遲的容忍度更高（因為別無選擇），而某人使用服務(wù)獲取實時股票報價進行日間交易時，容忍度則較低。

做啥權(quán)衡

• 通常，響應(yīng)性與可擴展性直接相關(guān)。系統(tǒng)越可擴展，響應(yīng)性越可能越好。然而，應(yīng)用程序還需要通過設(shè)計確保響應(yīng)性。
• 應(yīng)用程序的內(nèi)部設(shè)計復(fù)雜性增加。
• 可測試性變得更復(fù)雜，以覆蓋可能限制響應(yīng)性的潛在用例。
• 在某些情況下，我們需要在響應(yīng)性和正確性之間進行權(quán)衡。例如，考慮從服務(wù)A和服務(wù)B獲取數(shù)據(jù)的情況，但服務(wù)B不可達。你可能希望返回服務(wù)A的數(shù)據(jù)，而不是無限期等待服務(wù)B，因為這會影響系統(tǒng)的響應(yīng)性。這樣做的結(jié)果是，你快速返回數(shù)據(jù)（來自服務(wù)A），但由于沒有服務(wù)B的數(shù)據(jù)，響應(yīng)不完整。

一些實現(xiàn)方式

• 優(yōu)雅降級
• 斷路器
• 異步處理

1.5 容錯性（Fault Tolerance）

這是什么？

系統(tǒng)在其一個或多個組件發(fā)生故障時繼續(xù)運行的能力。

容錯性也與應(yīng)用響應(yīng)性相關(guān)。區(qū)別在于，響應(yīng)性更多是確保終端用戶體驗，而容錯性關(guān)注的是系統(tǒng)在僅有部分組件工作的情況下，仍能繼續(xù)運行并產(chǎn)生結(jié)果。

何時重要？

• 任務(wù)關(guān)鍵系統(tǒng)

做啥權(quán)衡

• 就像響應(yīng)性一樣，我們可能會為了系統(tǒng)整體的運行能力而犧牲系統(tǒng)輸出的正確性。

一些實現(xiàn)方式

• 優(yōu)雅降級
• 備用副本（計算和存儲）
• 主動/主動或主動/被動部署
• 通過架構(gòu)設(shè)計盡量減少關(guān)鍵組件的中斷
• 監(jiān)控故障
• 使用BASE事務(wù)代替ACID事務(wù)

1.6 可擴展性（Extensibility）

這是什么？

輕松向系統(tǒng)添加新功能和新集成的能力。

何時重要？

• 當我們知道應(yīng)用可能會以意想不到的方式增長和轉(zhuǎn)變時
• 當需要添加新組件時

做什么權(quán)衡

• 當可擴展性是我們的目標時，需要提前進行大量規(guī)劃，使系統(tǒng)架構(gòu)易于擴展。

一些實現(xiàn)方式

• 模塊化軟件——創(chuàng)建解耦、高內(nèi)聚、封裝的服務(wù)，彼此之間沒有依賴（包括代碼和架構(gòu)）
• 使用開放標準和最佳實踐。例如，利用REST或流行的消息隊列框架連接微服務(wù)
• 使用清晰的API契約
• 解耦數(shù)據(jù)存儲/數(shù)據(jù)庫，不同的領(lǐng)域數(shù)據(jù)使用不同的數(shù)據(jù)存儲

1.7 可測試性（Testability）

這是什么？

系統(tǒng)能夠輕松地進行手動和自動測試，無論是整體測試還是組件測試。

何時重要？

• 當我們希望測試覆蓋盡可能多的應(yīng)用流程時

做什么權(quán)衡

• 系統(tǒng)復(fù)雜性增加。尤其是對于分布式系統(tǒng)和異步流程，通常很難甚至不可能實現(xiàn)。
• 系統(tǒng)需要設(shè)計和架構(gòu)為允許組件進行隔離測試（包括代碼和基礎(chǔ)設(shè)施）。

一些實現(xiàn)方式

• 可測試的代碼（即模塊化代碼，便于單元測試、集成測試）
• 模塊化，使應(yīng)用功能可以模擬
• 確保盡可能多的測試可以自動化

1.8 性能（Performance）

這是什么？

性能與可擴展性和彈性密切相關(guān)，之間有很多重疊之處。區(qū)別在于，可擴展性和彈性通常指系統(tǒng)適應(yīng)不斷增長的負載的能力。而性能則討論系統(tǒng)在合理時間內(nèi)處理所有負載的能力。

何時重要？

• 大多數(shù)面向用戶的系統(tǒng)需要足夠高的性能以提供積極的用戶體驗。什么是“足夠高的性能”取決于應(yīng)用的上下文。例如，對于大多數(shù)網(wǎng)站來說，超過幾秒鐘的響應(yīng)時間通常被認為是糟糕的用戶體驗（盡管這取決于網(wǎng)站的功能）。

做什么權(quán)衡

確保性能需要系統(tǒng)在設(shè)計上能夠預(yù)見并消除瓶頸。這還需要在關(guān)鍵點進行細致優(yōu)化。這意味著需要投入足夠的精力來設(shè)計系統(tǒng)，持續(xù)監(jiān)控并識別問題區(qū)域。

一些實現(xiàn)方式

• 非阻塞I/O
• 異步編程和架構(gòu)（消息傳遞、事件流）
• 解耦系統(tǒng)
• 優(yōu)化長時間運行的過程和CPU密集型操作
• 優(yōu)化應(yīng)用代碼
• 選擇具有低網(wǎng)絡(luò)開銷的技術(shù)（即那些在堆棧較低協(xié)議上通信的技術(shù)，而不是HTTP）
• 利用具有已知性能保證的云原生服務(wù)（只要這些服務(wù)按規(guī)定使用）