ebay增強可用性的4個原則

你可能聽說過英國《衛報》。有可能從諸如愛德華·斯諾登洩密事件或者2011年與羅伯特·默多克的國際新聞相關的電話竊聽醜聞中聽說過它。你所不知道的是它的線上和技術團隊獲得過數個獎項，被許多圈子視為英國最好的產品團隊。

2008年的情況有些奇怪，《衛報》運營在一套企業級軟體系統上，這套複雜的程式碼又分成數個服務，這些服務與一個單體資料庫耦合在一起。系統執行了相當長的一段時間並且平安無事，但是隨著網際網路的增長，你永遠都不知道未來會發生什麼事情。如果我們推出一篇確實重磅的文章，流量就可能達到一天內以前峰值的一倍以上。問題是當有些部分出現問題時，所有的其他部分都開始出故障。這好像整個產品共享一個巨大的熔絲——當熔絲熔斷時，整個系統都會因此失敗。

“坦尼婭·科德里向其eBay的前同事們求助，作為增長諮詢公司AKF Partners公司，他們現在幫助那些需要這方面指導的客戶。在AKF的幫助下，我們開始重新設計網站，增加故障隔離區或泳道。基本上，相當於把熔絲盒中的單根熔絲變成了多根。在任何時候，如果網站的一部分出現問題，只有那個部分會出故障。這種故障隔離辦法讓軟體和資料庫子系統部署在獨立的泳道里，每個泳道都完全獨立於其他的泳道。網站的不同內容區域由不同的泳道提供服務。如果一個泳道失敗，比如天氣版面，我們可以繼續提供時效性強的新聞。更近一步，我們可以在每個不同泳道的可用性方面投入不同的時間和精力。像新聞之類的泳道可以有比其他重要性低的（如天氣）泳道顯著不同的冗餘解決方案。在過去的解決方案中，每個部分都有同樣的可用性以及相同的成本；現在我們可以讓新聞有更高的可用性而不必大幅度提高成本。

格蘭特說道，“回想2008年，你會看到責任編輯總在關注網站是否能應對大流量新聞。而今，剛剛有1400萬唯一的讀者閱讀了2015年11月恐怖分子襲擊巴黎的報導。現在的責任編輯再也不顧慮線上系統，他們知道該系統有這個能力。”

“受到這種關注的並不僅僅是網站。當在網際網路上使用一款產品時，要依靠一定數量的工具以及獨特的基礎設施。”格蘭特總結說，“現在，我們把相同的概念應用到監控和程式碼釋出等地方。每個關鍵業務都應該有自己的泳道，這樣某個工具的故障就不會導致其他工具和監控的故障”。

對故障隔離和故障控制的需求並不侷限於格蘭特與《衛報》。根據我們的經驗，大多數的技術團隊都非常擅長，並且非常專注於交付能正常工作的系統。此外，大多數工程師都明白不可能研發出完美無缺的解決方案，因此，不可能構建永遠不會故障的系統。即使考慮到了這一點，幾乎沒有工程師願意花費大量時間來勾勒和圈定任何給定故障的“爆炸半徑”。 

在我們的業務中，可用性和可擴充套件性具有同等重要性。可用性不高的產品確實不需要擴充套件，當需求來臨時不能擴充套件的網站也不會是高可用的。因為系統故障無法避免，所以我們不得不花時間來控制故障對系統的影響。本章提供了幾種限制故障影響的方法，總之，減少故障的頻率，提高產品的整體可用性。

規則1——用“泳道”隔離故障

內容：在設計中實現故障隔離區或泳道。

場景：為可擴充套件性開始拆分持久層（例如資料庫）或服務時。

用法：沿Y或Z軸拆分持久層和服務，禁止故障隔離的服務和資料間同步通訊或訪問。

原因：提高可用性和可擴充套件性。減少發現和解決故障的時間。縮短上市時間和成本。

要點：故障隔離包括根除故障隔離域間的同步請求，限制非同步呼叫和處理同步呼叫失敗，以及避免泳道之間的服務和資料共享。

在拆分服務和資料方面的術語豐富而混亂，而且有時候相互矛盾。不同組織經常使用一些詞，如豆莢（pod）、池（pool）、叢集（cluster）和分片（shard）。在同一組織內這些術語經常交替使用加劇了這種困惑。在某個場景，團隊可以使用分片來確定服務和資料的分組，而在另一場景下，它僅意味著在資料庫中分割資料。鑑於現有術語的混淆和差異，在實踐中我們創造了泳道一詞，嘗試打造故障隔離的重要概念。一些客戶開始採用這個詞來表示為實現故障隔離而在生產中按照服務或客戶拆分，它最重要的貢獻是在設計領域。表9-1是常用術語的列表，它包括對這些術語最普通的描述以及何時及如何在實踐中交替使用的說明。

在我們看來，這些術語中最重要的區別是大多數都集中在分工或事務上，但只有一個聚焦在控制故障傳播上。而池、分片、叢集和豆莢指的是如何在生產環境中實施或如何拆分或擴充套件客戶或者服務，遊道是圍繞設立故障隔離域提出的架構概念。故障隔離域是這樣的一個域，當物理或邏輯服務因故障無法正常工作時，無論該故障是響應緩慢還是根本無法響應，唯一受到影響的是那些在故障域中的服務。泳道透過故障域把分片和豆莢的概念擴充到了服務的前門——資料中心的入口。在極端情況下，它意味著按照功能提供獨立的網路、應用和資料庫伺服器（或叫故障隔離區）。在本質上，泳道旨在提高可擴充套件性和可用性，而不僅僅是一個可以擴充套件事務處理的機制。

我們借用CSMA/CD（帶有衝突檢測的載波偵聽多路存取，通常稱為乙太網）中的概念，其中故障隔離域相當於衝突域。在全雙工交換機之前，為了抵消碰撞的影響，乙太網段控制碰撞以確保所有連線的系統感覺不到影響。我們覺得用“泳道”這個術語來描述故障隔離是一個非常好的比喻，泳道是在游泳池中設定的隔離線，有助於游泳選手在游泳過程中避免相互干擾。與此類似，不同組別的客戶或者功能之間存在隔離帶，不允許跨越不同組別進行同步事務處理，有助於確保一條泳道上的故障不會對其他泳道上的使用者操作產生不利的影響。

故障隔離泳道的好處已經超越了透過故障隔離提高可用性的想法。因為泳道把客戶或者把跨客戶共享的功能做了拆分，當出現故障時，可以更快地定位問題來源。從網路伺服器到持久層，如果已經對客戶沿Z軸做了拆分，影響單個客戶的唯一故障將會很快被隔離在那條泳道里的那組客戶。你會對要找的缺陷或問題（由資料或操作觸發）瞭然於胸，因為對於遊道中的客戶它是唯一的。如果已經沿Y軸進行了拆分，而“購物車”泳道出現了問題，你馬上就會知道問題是與構成該泳道的程式碼、資料庫或者伺服器相關。事件檢測與解決以及問題的定位和解決都明顯受益於故障隔離。

故障隔離的其他好處還包括更好的可擴充套件性、更快的上市時間以及更低的成本。因為我們專注於系統分割槽，開始考慮水平擴充套件，所以可擴充套件性提高。如果透過Y軸隔離泳道，那麼我們可以把程式碼庫也進行拆分，這樣可以更有效地使用工程師。因此，我們獲得到了更大的工程吞吐量，每個單位開發的成本也更低。如果吞吐量越來越大，顯然產品推向市場的速度加快。最終所有這些好處使我們能夠處理“預期但意外之外的事情”：那些知道遲早會發生但不清楚其後果的事情。換句話說，我們知道事情將要發生，只是不知道會發生什麼或何時會發生。故障隔離使我們能夠更優雅地處理這些故障。

    討論了為什麼應該為產品建立泳道或設定故障隔離，現在我們把注意力轉向更重要的問題，如何實現故障隔離。依靠四條原則來定義和幫助我們設計泳道。第一個原則是泳道之間什麼都不共享。通常不包括網路元件，如網路入口的邊界路由器和一些核心路由器，但包括為故障隔離服務專用的交換機。經常共享一些其他的裝置，諸如非常大的儲存區域網路或者小網站中的負載均衡器。在任何可能的場合，而且在特定成本範圍內，試著儘量不要共享。永遠不要共享資料庫和伺服器。因為泳道的部分定義不共享，所以伺服器和資料庫共享一直是確定泳道邊界所在的起始點。鑑於網路裝置和儲存子系統的成本問題，有時在系統增長的初期可以考慮跨越不同的泳道。

泳道的第二個原則是在泳道之間不進行同步呼叫。因為同步呼叫會捆綁服務，所以被呼叫服務的失敗會蔓延到所有其他以同步和阻塞方式呼叫的系統。因此，這會違反故障隔離的概念，如果部署在一條泳道里的服務失敗可能會導致部署在另一條泳道里的服務失敗。

第三條原則限制泳道之間的同步呼叫。比起同步呼叫，非同步呼叫失敗蔓延到其他泳道的機會很小，但仍然有機會降低系統可用性。突然激增的請求可能使某些系統變慢，例如拒絕服務攻擊後釋出訊息。這些訊息鋪天蓋地阻塞佇列，開始佔滿TCP埠，如果實施不當甚至導致同步請求的資料庫處理停滯。因此，我們試圖限制跨越泳道界限的事務處理數量。

泳道的最後一個原則是，當絕對必要時如何實現跨越泳道邊界的非同步傳輸。簡單地說，每次要跨越泳道進行非同步通訊時，我們需要對事務處理有“不在乎”的能力。在某些情況下，事務處理可能會超時，可以忽略它。我們可能只是“通知”另一條泳道有些行動，並不在乎是否得到回應。在所有情況下，我們應該實現邏輯以實現在手動自動或兩者兼有的基礎上“斷開”或“關閉”通訊。監控人員透過系統監控發現故障（手動開關）應該有能力關閉通訊，當情況不好時，系統應該能感知並停止（自動開關）通訊。

回想一下本書的前言，還記得裡克·達爾澤爾提到過亞馬遜嗎？亞馬遜的第一次拆分是把商店功能從訂單履行功能中分離出來。如果由於某種原因，亞馬遜店面失敗，亞馬遜可以繼續履行已收到的訂單。如果訂單履行系統出問題，商店可以繼續接收訂單並把它們放入佇列。顯然，兩個子系統需要互相通訊，但從客戶角度來看不是“同步”。工作以履行訂單的形式從前端傳到後端，以訂單狀態更新的形式從後端傳向前端。這種拆分提供了兩個好處，故障隔離和更高水平的可擴充套件性，因為每個子系統都可以獨立擴充套件。

    在我們希望故障隔離，但需要同步通訊或訪問另一個資料來源的情況下怎麼辦？前一種情況下，可以複製需要的服務，然後把它配置在泳道里。支付閘道器就是這種方法的一個例子。如果我們沿著Z軸按客戶劃分泳道，可能不希望每個客戶的泳道為了某個服務（如結賬）而同步（阻塞）呼叫單一的支付閘道器。我們可以簡單地實施N個支付閘道器，其中N是客戶細分度或客戶遊道的數量。

如果有一些共享資訊需要訪問每個泳道，如登入憑據，應該怎麼辦？也許我們已經把認證和登入沿Y軸做了拆分，但我們需要在只讀基礎上從每個客戶（Z軸）的泳道上取得相關的憑據。我們經常使用資料庫的只讀副本來滿足這樣的要求，把只讀副本放在每個泳道中。許多資料庫天然提供這種複製技術，甚至允許把資料切成小片，這意味著我們不需要在每個泳道中複製100%的客戶資料。有些客戶為了只讀目的，把相關的資訊快取在相應泳道的分散式物件快取中。

我們經常遇到的一個問題是如何在虛擬化伺服器世界中實施泳道。虛擬化為故障隔離增加了新的維度——除了物理故障之外的邏輯（或虛擬）維度。如果實現虛擬化主要是為了把較大的機器分解成更小的機器，那麼應該繼續把物理伺服器作為泳道的邊界。換句話說，不要把來自於不同泳道的虛擬伺服器放在同一物理裝置上。然而，我們的一些客戶常年有各種不同需求特性的產品，他們依靠虛擬化作為橫跨所有產品的彈性容量。在這種情況下，我們試圖限制混合在虛擬伺服器上的泳道數量。理想情況下，把整個物理伺服器用在一個遊道上，而不是在該伺服器上混合幾個泳道。

泳道與虛擬化

當使用虛擬化技術將較大的伺服器分割成較小伺服器時，嘗試沿物理伺服器邊界保持泳道。在同個物理伺服器上混合不同泳道的虛擬伺服器抵消了故障隔離泳道的許多好處。

 規則2——拒絕單點故障

內容：永遠不要實施會帶有單點故障的設計，一直要消除單點故障。

場景：在架構審查和新系統設計時。

用法：在架構圖上尋找單個例項。盡最大可能配製成主動/主動模式。

原因：透過多例項配置最大化可用性。

要點：努力實施主動/主動而非主動/被動配置。使用負載均衡器在服務的不同例項之間實現流量平衡。對需要單例的情形，可以在主動/被動模式的例項中採用控制服務。

在數學中，單元素集合是隻有一個元素{A}的集合。按照程式設計的說法，單例模式是模擬數學概念的設計模式，把類的例項化限制在只有一個物件。這種設計模式對於資源協調很有用，但經常被研發人員出於便捷的目的而過度使用。在系統架構中，單例模式（或更恰當地說，反模式的單件情況）稱為單點故障（SPOF）。這是指系統中僅有一個例項，當它失敗時將導致系統範圍的事故。

SPOF可以存在於系統的任何地方，包括單個網路伺服器或單個網路裝置，但最常見的是資料庫系統中。原因是資料庫往往最難跨越多個節點擴充套件，因此成為單例。在圖9-1中，即使有冗餘的登入、搜尋和結賬伺服器，資料庫也是SPOF。更糟糕的是，所有的服務池都依賴於那個單個資料庫。雖然SPOF不好，但是資料庫作為SPOF問題更大，因為如果資料庫減慢或崩潰，所有同步呼叫該資料庫的服務池都會遇到問題。

我們有個與客戶分享的口頭禪：“一切皆可能出故障。”這包括伺服器、儲存系統、網路裝置和資料中心。凡能說出來的，都可能出故障，而且可能我們已經看到了這些故障。雖然大多數人認為資料中心永遠不會出故障，但這些年我們親身經歷了十多次資料中心的服務中斷。這同樣適用於高可用的儲存區域網路。儘管它明顯比舊的SCSI磁碟陣列更可靠，但它仍然會出故障。

大多數SPOF的解決方案是直接部署一個硬體，透過複製X軸刻度所描述的服務確保每個服務至少執行在兩個或者多個例項上。但是，這並不總是那麼容易。讓我們追溯程式設計步驟的單例模式。雖然不是所有的單例類都會阻止服務在多個伺服器上執行，但是有一些實施絕對會避免可怕的後果。舉個簡化的例子，如果在處理從使用者賬戶扣減資金的程式碼中有個類，可能會對此實施一個單例，以防止像使用者賬戶餘額為負數這樣不愉快的事情發生。如果我們將此程式碼放在兩個獨立的伺服器上，而不實施額外的控制或設定訊號量，兩個併發的事務有可能會都從使用者賬戶上扣款，從而導致錯誤或不希望的情況發生。因此，要麼修復程式碼來處理這種情況，要麼依靠外部的控制來防止。最理想的解決方案是修復程式碼，以便在許多不同主機上實施服務，通常我們需要迅速修復程式碼以解除SPOF。作為本規則最後的重點，我們下一步將討論一些快速修復的方法。

第一個和最簡單的解決方案是採用主動/被動配置。將服務部署在主動伺服器上執行，同時也部署在不處理流量的被動伺服器上。熱/冷配置通常用在資料庫上作為去除SPOF的第一步。下一個選擇是使用系統中的另一個元件來控制資料訪問。如果資料庫是SPOF，可以配置成主／從模式，應用可以控制資料訪問，由主資料庫完成寫入／更新，由從資料庫完成閱讀/選擇。除了消除SPOF，引入具有高讀寫比的只讀資料庫副本將減少主資料庫的負載，並可以利用更經濟實用的硬體，如第3章中規則11所討論的那樣。可以解決SPOF問題的最後一種配置是採用負載均衡器。如果網路或應用伺服器上的服務是SPOF而且無法在程式碼中解決，通常可以採用負載均衡器，來解決使用者請求只能由服務池中一臺伺服器來服務的問題。這可以透過設定在使用者瀏覽器中的會話cookie來完成，利用負載均衡器把使用者的每次請求重定向到相同的網路或應用伺服器上，從而確保狀態的一致性。

我們討論了當無法及時透過修改程式碼解決SPOF時，幾種可以快速實施的解決方案。儘管最佳而且最終的解決方案應該是修復程式碼，以允許服務的多個例項執行在不同的物理伺服器上，但是首先是要儘早消除SPOF。記住，“一切皆可以出故障”，所以當修復SPOF的方案失敗時，不要感到驚訝。

規則3——避免系統串聯

內容：減少以串聯方式連線的元件數量。

場景：每次考慮新增元件的時候。

用法：刪除不必要的元件、收起元件或新增多個並行元件以減少影響。

原因：串聯元件受多重失敗乘法效應的影響。

要點：避免向串聯絡統新增元件。如果有必要這樣做，新增多個版本的元件，如果一個出故障，其他元件可以取代它的位置。

電路中的元件有多種連線方式。兩種最簡單的連線方式是串聯和並聯。串聯電路的元件（可能是電容、電阻或其他元件）沿電路連線。在這種型別的電路中，電流流過每個元件，電阻和電壓是在這個基礎上產生的。圖9-2顯示了兩個電路，一個有三個電阻，一個有三節電池，由此產生電阻和電壓。請注意，在此圖中，如果有任何元件出故障，如電阻燒掉，就會造成整個電路出故障。

圖9-3顯示了兩個並聯電路，上面的有三個電阻（和一個電源或電容），下面的有三節電池。在這個電路中，總電阻的倒數等於每個電阻的倒數之和。定義的總電阻必須小於最小電阻。請注意，電壓不改變，但電池只貢獻了一小部分的電流，這有延長其使用壽命的效果。請注意，在這些電路中，元件的故障不會導致故障整個電路出故障。 

    系統架構和電路在許多方面有相似之處。像電路一樣，系統也由不同元件組成，如Web和應用伺服器、負載均衡器、資料庫和網路裝置，而且也可以並聯或串聯。讓我們以一個有大流量的靜態網站為例。你可能把相同的靜態內容配置在10個Web伺服器上以提供網站服務。要麼使用負載均衡器引導流量，要麼利用DNS透過為相關域名指定10個獨立的IP地址。這些Web伺服器像圖9-3中的電池一樣是並聯的。Web伺服器所處理的流量是總量的一小部分，如果一個Web伺服器失敗，該網站仍然可用，因為還有其他9個Web伺服器。

作為一個更典型的串聯架構例子，讓我們新增一些層。如果以一個包括一個網路伺服器、一個應用伺服器和一個資料庫伺服器的標準的三層網站為例，我們會有一個串聯的架構。要滿足請求，Web伺服器必須先接受請求，然後將其傳遞給應用伺服器（它查詢資料庫）。應用伺服器接收並處理資料後，將其傳送回Web伺服器，最終滿足客戶的請求。如果電路或架構中的任何元件發生故障，整個系統將出故障。

回到現實世界的架構。幾乎總是有些元件需要串聯。當考慮到負載均衡、Web和應用層、資料庫、儲存系統等時，為了保持系統執行需要許多元件。當然，新增並聯元件，即使層之間串聯，有助於降低由元件故障引起系統故障的總風險。如果只有一個Web伺服器出故障，多臺Web伺服器可以分散流量負載並避免系統故障。對於網路與應用層，大多數人很容易接受這個概念。資料庫和網路層的這個問題卻被大多數人忽視。如果並聯的Web和應用伺服器都串聯到單個資料庫，就可能會有一個可以導致災難性故障的元件。

關於網路元件，我們經常看到架構對並聯伺服器非常關注，但完全忽略網路裝置，尤其是防火牆。流量透過防火牆、負載均衡器、防火牆、交換機，然後到Web伺服器、應用伺服器、資料庫伺服器，然後再一路返回。這個過程至少有7個串聯的元件。如果已經有6個元件了，那麼再增加一個有什麼大不了的？

串聯元件出故障的風險具有乘法效應。舉個簡單例子，如果我們有兩個串聯的伺服器，各有99.9%的可用性或正常執行時間，那麼該系統的總可用性不能大於99.9%×99.9%=99.8%。如果在串聯中增加可用性為99.9%的第三個元件，我們就得到一個更低的總可用性99.9%×99.9%×99.9%=99.7%。放置的串聯元件越多，系統的總可用性就越低。表9-4列出了一些簡單的計算，來說明可用性降低，那麼每月由此產生的停機時間增加。對串聯的系統，每增加一個元件（可用性99.9%），每月停機時間就增加大約43分鐘。然而，對並聯系統，每增加一對元件（可用性99.9%），每月停機時間就減少大約26分鐘。假如並聯的每個元件有更低的可用性，這種改善效果甚至更加顯著。

就像今天的大多數電路一樣，系統也遠比簡單的串聯和並聯更加複雜，對可用性的精確計算要比簡單的例子複雜得多。然而，可以明確的是，串聯元件顯著增加了系統停機的風險。當然，可以透過減少串聯元件或增加並聯元件來降低風險。

規則4——啟用與禁用功能

內容：搭建一個框架來啟用與禁用產品的功能。

場景：考慮使用上線和下線框架控制新研發的、非關鍵性的或者依賴第三方的功能。

用法：研發共享庫以自動或基於請求的方式控制功能的啟用與禁用，參見表9-5中的推薦。

原因：為了保護對終端使用者很重要的關鍵功能，關閉有問題或非關鍵性的功能。

要點：當實施成本低於風險損失時，實現上線和下線框架。開發可以複用的共享庫以降低未來實施的成本。

在討論故障隔離設計方法時也提過它。最終這些型別的框架有助於確保系統可以優雅地出故障（在事件自診斷框架下）或在透過人為干預禁用某些功能的基礎上繼續提供服務。有時公司將類似的功能稱為“功能切換”或“斷路器”。

過去有幾種方法可以控制功能的上線和下線，每種方法都有一定的優點與缺點。啟用和禁用服務很可能取決於技術團隊和運營團隊的能力，以及出現問題的服務的業務關鍵性。表9-5涵蓋了一些方法。

    表9-5並不是啟用和禁用功能的所有可能性的完整清單。事實上，許多公司融合了一些選項。他們可以在啟動時從資料庫讀取引數或者檔案，以控制應用程式碼顯示或不顯示某組功能。PayPal在第一次實現國際化時所實施的就是這樣的一個例子。有些國家的銀行或資金轉移規定只允許一些有限的支付功能。根據使用者使用網站的地理位置，他可能只看到主網站提供的功能中的一部分。

當考慮功能的上線／下線框架時，要解決的同等重要的問題是，在哪裡和什麼時候應該使用決策。顯然，實施框架意味著額外的工作以及由此帶來的額外業務成本。讓我們以（不太可能而且可能不正確）某些永遠都不會出故障的功能為起點。如果知道哪些功能永遠不會出故障，我們將不想為這些功能實現此控制功能，因為這是沒有回報的投入。以此為起點，我們就可以確定投資在哪裡具有價值或能帶來業務回報。使用率高（高吞吐量）並且其故障會影響網站上其他重要功能的任何功能是合適的選擇。另一個選擇是在給定版本中正在經歷大幅修改的那些功能。選擇這兩類功能的想法是，實施上線/下線的成本小於給業務帶來的風險（風險是失敗機率和失敗影響的函式）。如果開發這些功能花費額外1000美元的成本，該功能無法處理的故障可能造成1萬美元的業務損失，這個成本投入划算嗎？

如果處理得當，技術團隊可以透過實現一組跨功能的共享庫，降低實施上線/下線框架的成本。對新的開發，這種方法不會把實施框架的成本降低為零，但它確實有助於降低未來幾代框架啟用功能的成本。

我們建議實施上線/下線框架有幾個重要的原因。首先，新功能或正在積極開發的功能很有可能有缺陷。有能力關閉有問題的功能非常有價值。其次，如果功能對所提供的服務不重要，有可能想要關閉非關鍵功能。當計算資源成為瓶頸時，也許存在記憶體洩漏，把應用送入垃圾回收過程，關閉非關鍵功能以保護更多關鍵功能是個很好的選擇。第三，呼叫第三方服務經常要以同步方式進行。當供應商的API開始響應緩慢時，能夠關閉功能可以防止它減緩整個應用或服務，是非常可取的。顯然，我們不相信一切都應該能夠啟用/禁用或上線/下線。這種做法成本昂貴而且不建議的，但運轉良好的團隊應該能夠發現風險，為實施合適的保障措施共享元件

總結

我們相信可用性和可擴充套件性緊密相關。可用性不高的產品不需要擴充套件，因為使用者過不了多久就不來了。無法擴充套件的網站不會有高可用性，因為網站會變慢，甚至完全停下來。因此不能顧此失彼。本章提供了四個規則，它們有助於確保網站保持高可用性以及持續擴充套件。不要因為專注於可擴充套件性而使你忘記可用性對客戶多麼重要。

本文選自架構真經：網際網路技術架構的設計原則（原書第2版）一書，由馬丁·阿伯特、邁克爾·費舍爾著，陳斌翻譯。