1.6 可擴展性與架構的權衡

可擴展性是非功能性需求，它只是眾多質量屬性之一——“非功能性需求”是軟件架構領域的通用語。軟件架構的長遠復雜性問題之一是如何在質量屬性之間做權衡。通常來說，有利于一種質量屬性的設計可能會對其他質量屬性產生負面或正面的影響。例如，我們可能希望在服務中發生某些事件時寫入日志消息，以便取證和調試代碼。但是，我們需要注意捕獲了多少事件，因為寫入日志記錄會引入開銷，對性能和成本產生負面影響。

經驗豐富的軟件架構師非常注意分寸，他們精心設計系統來滿足高優先級的質量屬性，同時盡量減少對其他質量屬性的負面影響。

系統可擴展性也不例外。當我們將焦點放在系統的擴展能力上時，我們必須仔細考慮自己的設計如何影響其他非常理想的屬性，例如性能、可用性、安全性以及經常被忽視的可管理性。我將在接下來的內容中簡要討論其中一些質量屬性內在的權衡。

1.6.1 性能

有一種簡單的方法可以體現系統性能和可擴展性之間的差異。當我們以性能為目標時，我們會嘗試達到個別請求的一些期望指標，可能是平均響應時間小于2 s，或者是最壞情況下的性能目標，例如第99百分位響應時間小于3 s。

提高性能對可擴展性來說通常是一件好事。如果我們提高單個請求的性能，那么它會占用系統更少的容量，這有助于提高可擴展性，因為我們可以將用未使用的容量來處理更多請求。

然而，事情并不總是那么簡單。我們可以通過多種方式縮短響應時間。我們可能會仔細優化代碼，例如，刪除不必要的對象復制，使用更快的JSON序列化庫，甚至用更快的編程語言重寫代碼。這些方法能在不增加資源使用的情況下優化性能。

另一種方法可能是將經常訪問的狀態保留在內存中，避免每個請求都寫入數據庫，從而優化單個請求。消除數據庫訪問幾乎總能加快速度。但是，如果我們的系統內存中長時間維護著大量狀態，我們可能要（在訪問量較多的系統中必須）仔細管理系統可以處理的請求數量。這可能會降低可擴展性，因為我們針對單個請求的優化方法比原始解決方案使用的資源（在本例中為內存）更多，從而降低了系統容量。

在本書中，我們將再次看到性能和可擴展性之間的這種緊張關系。事實上，有時讓個別請求稍微慢一些是明智的，這樣我們就可以利用額外的系統容量。我在下一章討論負載均衡時，將提供一個很好的例子。

1.6.2 可用性

可用性和可擴展性通常是高度兼容的“合作伙伴”。當我們復制資源來擴展自己的系統時，我們創建了多個服務實例，可用于處理來自任何用戶的請求。如果一個實例出現故障，則其他實例仍然可用。系統容量減少的原因只是應用程序出現故障或資源不可用。類似的想法也適用于復制網絡鏈接、網絡路由器、磁盤以及計算系統中的幾乎所有資源。

涉及狀態時，可擴展性和可用性會變得復雜。例如數據庫，如果單個數據庫服務器過載，我們可以復制它并向任一實例發送請求。這也提高了可用性，因為我們可以容忍一個實例的故障。如果數據庫是只讀的，則此方案非常有效。但是，一旦更新了一個實例，我們就必須弄清楚如何以及何時更新另一個實例。這是副本在一致性問題上影響很大的地方。

事實上，每當為了可擴展性和可用性而復制狀態時，我們都必須處理一致性問題。在本書的第三部分討論分布式數據庫時，這是一個關鍵話題。

1.6.3 安全性

安全性是一個復雜的、技術性很強的話題，值得用一本書來探討。沒有人愿意使用不安全的系統，系統被黑客入侵和泄露用戶數據都會導致CTO辭職，在極端情況下，公司甚至會倒閉。

安全系統的基本要素是身份驗證、授權和數據完整性。我們需要確保數據不會在網絡傳輸的過程中被截獲，并且任何無權訪問數據的人都無法訪問靜態數據（持久存儲）。基本上，當我的信用卡號在系統之間進行傳輸或存儲在公司的數據庫中時，我不希望任何人看到它。

因此，安全性是所有面向互聯網的系統的必要質量屬性。構建安全系統的成本是不可避免的，讓我們簡要地研究一下這些成本是如何影響性能和可擴展性的。

在網絡層，系統通常會采用運行在TCP/IP之上的TLS協議[傳輸層安全協議（https://oreil.ly/pG2eg），參見第3章]。TLS使用非對稱加密（https://oreil.ly/FqPSm）提供加密、身份驗證和數據完整性能力。在建立安全連接過程中，由于雙方都需要生成和交換密鑰，所以會產生性能成本。TLS連接建立還包括交換證書來驗證服務器（以及可選的客戶端）的身份，以及選擇一種算法來檢查數據在傳輸過程中是否被篡改。建立連接后，傳輸中的數據將使用對稱加密技術進行加密，由于現代CPU具有專用的加密硬件，因此這部分的性能損失可以忽略不計。建立連接通常需要在客戶端和服務器之間進行兩次消息交換，因此速度較慢。盡可能重用連接可以最大限度地減少性能開銷。

保護靜態數據有多種選擇。SQL Server和Oracle等流行數據庫引擎具有透明數據加密（TDE）等功能，可提供高效的文件級加密。金融等受監管行業越來越需要細粒度的加密機制，直至字段級別。云提供商也提供各種功能，確保數據存儲在云數據存儲服務中是安全的。靜態安全數據的開銷是實現安全性必須承擔的成本——研究表明開銷在5%～10%的范圍內。

另一個關于安全的觀點是CIA triad（https://oreil.ly/building-secure），它代表保密性（Confidentiality）、完整性（Integrity）和可用性（Availability）。前兩個和我上面描述的差不多?？捎眯允侵赶到y即使在對手的攻擊下也仍然保持可靠運行的能力。來自對手的攻擊可能是試圖利用系統設計弱點使系統癱瘓。另一種攻擊則是經典的分布式拒絕服務（DDoS），在這種攻擊中，對手獲得了對眾多系統和設備的控制權，并協同大量請求，使得受害系統不可用。

一般來說，安全性和可擴展性是對立的力量。安全必然會導致性能下降。系統包含的安全層越多，性能和可擴展性的負擔就越大。這最終會影響成本底線——需要更強大和更昂貴的資源來實現系統的性能和可擴展性要求。

1.6.4 可管理性

隨著我們構建的系統在交互中變得更加分散和復雜，對它們的管理和運營也變得越發重要。我們需要確保每個組件都按預期運行，同時性能繼續達到預期。

我們用于構建系統的平臺和技術提供了大量標準的專有監控工具，可用于實現上述目標。監控儀表板可用于檢查每個系統組件的持續運行狀況和行為。這些儀表板使用高度可定制和開放的工具構建（例如Grafana，https://oreil.ly/PNaBs），可以顯示系統指標，在系統出現需要操作員注意的各種閾值或事件時發送警報。用于描述這種復雜監控功能的術語是可觀測性（https://oreil.ly/xcuLd）。

工程師可以使用各種API來捕獲系統的自定義指標，例如Java的MBean（https://oreil.ly/vtTUT）、AWS CloudWatch（https://oreil.ly/cvviZ）和Python的AppMetrics（https://oreil.ly/oa9MT）——一個典型的例子是捕獲請求響應時間。使用這些API收集的指標，可以定制監控儀表板來顯示實時圖表和圖形，從而深入了解系統的行為。指標對于洞察系統是非常寶貴的，它有助于確保持續運營，以及凸顯系統中可能需要優化或復制的部分。

擴展系統總是意味著添加新的系統組件——硬件和軟件。隨著組件數量的增加，我們需要監控和管理更多活動部分。這絕不輕松，它增加了系統操作的復雜性和監控成本，這需要開發更多的監控代碼來調整可觀測平臺，確保其監控了新的系統組件。

在擴展時，控制成本和可管理性的復雜性的唯一方法是自動化。這就是DevOps閃亮登場的時刻了。DevOps（https://oreil.ly/effective-devops）是一套集成軟件開發與系統操作的實踐和工具。DevOps自動執行系統的持續測試、部署、管理、升級和監控，縮短了新功能的開發生命周期。它是所有成功的可擴展系統的組成部分。