有一種觀點：
- 您不需要分散式系統！如今的計算機速度如此之快，您只需一臺機器即可為所有客戶提供服務
這種論點是愚蠢和簡單化的。
這一論點基於一個事實：
- 現代機器非常強大，每秒可以完成大量工作，甚至可以將一些大型企業的所有資料都放入記憶體中。
- 每秒可以實現數千甚至數百萬個請求。每秒數百 GB。TB 級記憶體，甚至更多儲存空間。
- 每秒 GB 級儲存頻寬。數百萬 IOPS。
現代機器速度超快，能夠利用這種速度的軟體可以實現令人難以置信的事情。
因此：
- 許多系統的分佈都是不加思索的，或者浪費的，或者增加複雜性和降低效率
例如：EC2 提供的單個例項有 32TiB 記憶體和 896 個 vCPU，以及 200Gbps 網路頻寬。
許多非常重要的工作負載可以放在一臺這樣的機器上。
如果我們只關心規模的話，這是可能的。
但是，不僅僅是規模！
Marc Brooker 這篇文章《不僅僅是規模》討論了規模在分散式系統中的重要性，但也強調規模只是使這些系統變得有趣和有用的一小部分。
- 雖然規模至關重要，但它並不是唯一需要考慮的因素。
規模和可擴充套件性只是分散式系統受到關注的總體原因中的一小部分。
其他實際原因包括：
- 可用性。由多個冗餘元件組成的系統可以提供單機系統無法比擬的可用性。分散式系統以線性成本實現了指數級的可用性提升，而且幾乎完全無需干預。單機系統只能透過增加故障時間或減少恢復時間來實現更高的可用性，這既複雜又昂貴。
- 耐久性。在多臺機器上製作多個資料副本是確保線上資料高度耐久的唯一可靠方法。RAID 等單系統方法基於對故障獨立性的根本性錯誤假設。當然，離線資料可以透過離線備份實現耐久性。
- 利用率。多租戶系統透過將多個不同的工作負載打包到相同的資源上來實現更低的成本和更高的利用率。這有兩種方式：它允許不同季節週期的工作負載在短期內共享資源，並允許具有不可預測的負載峰值（或故障恢復峰值）的系統共享備用突發資源。這既可以加快恢復速度，又可以顯著提高峰值與平均比率。在許多實際系統中，透過提高峰值與平均比率獲得的效率超過了調整單機系統以提高效率的機會。
- 延遲。透過將短期負載峰值分散到更大的資源池中，分散式系統可以減少短期系統過載造成的尾部延遲。
- 專業化。由多個元件組成的分散式系統允許這些元件專門用於延遲敏感、吞吐量敏感、位置敏感、計算密集型、記憶體密集型或任何其他不尋常屬性的工作負載。一個很好的例子來自 MemoryDB 論文，我們看到了專用元件的組合如何使整個系統既顯著減少記憶體需求又降低尾部延遲。
- 隔離。使用多個元件構建系統可以最佳化元件的安全屬性。例如，請注意在Firecracker 論文中，Lambda 的架構如何將執行客戶程式碼的強隔離元件與執行簡單資料查詢任務的多租戶元件相結合。
- 變化。系統中最普遍的需求，也是經常被忽視的需求，可能是應對變化的能力。隨著業務的發展部署新程式碼。修補安全問題。對客戶問題做出反應。在分散式系統中，通常會利用系統的高可用性機制來實現安全的零影響修補和部署。單機系統更難改變。
這些屬性使系統實現了一些重要的東西：簡單性。
簡單是一種系統屬性<strong>
我們經常可以看到對簡單性的還原觀點，這種觀點只考慮了系統的部分職責，忽略了重要的要求，或忽視了實現這些要求的實際方式。
讓我們以部署為例。
- 在許多分散式設計中，當需要進行更改時，部署是透過更換或重新映象機器來實現的。通常情況下，這使用的是確保高可用性的相同機制：流量從一臺機器移走，進行更改並驗證，然後流量返回。
- 而單機部署通常較難更改：必須線上對執行中的系統或在停機壓力下進行更改。單機驗證更改也很困難，因為要麼全做，要麼全不做。
在欣賞單機部署的簡單性時，我們很容易忽略這種複雜性：
- 單機部署的問題是可以解決的，但通常要以更高的系統複雜性為代價：複雜的操作程式、熟練的操作員、高度的判斷力、與客戶的協調等。
簡單是系統的屬性，而不是元件的屬性，系統包括人和流程。
簡單性辯論中的另一個陷阱是將簡單與熟悉混為一談：
- 多年使用 Linux 可能會讓人感覺系統管理任務很簡單。
- 多年使用 IaC 框架可能會讓人感覺雲部署很簡單。
實際上，兩者都相當複雜，但我們很容易得出結論：我們更熟悉的那個才是更簡單的。
當然，在實際系統中，規模也有很多方面的影響，其中一種方式就是組織規模。
擴大組織規模
就像計算機系統一樣，組織的擴充套件必須避免協調。
- 組織越是需要不同部分相互協調才能工作，就越無法發展壯大。
- 組織要想在不停滯的情況下發展壯大，就必須精心設計並不斷最佳化，以減少不必要的協調。
組織必須透過避免協調來擴大規模：
- 不必要的協調可能會阻礙其發展能力
- 隨著組織的發展，需要不斷最佳化，減少不必要的協調
微服務和 SoA 等方法是允許技術組織避免協調資料模型、實施選擇、佇列管理、工具選擇等非核心業務的工具。
從根本上說，應用程式介面是一種契約，它將人與人之間的協調轉移到系統與系統之間，並以允許系統高效處理協調的方式對協調進行限制。
您也許可以在一個盒子上執行所有的業務邏輯，但隨著企業的發展，您可能會發現這樣做所需的協調工作會越來越慢。
最後，規模確實很重要。
規模上限
作為一名企業主，沒有什麼比滿載而歸的喜悅和痛苦更讓人難忘的了。
- 喜悅，因為這是生意成功的標誌。
- 痛苦，是因為如果店面更大，就能為更多顧客提供服務。
門外排隊的人把顧客拒之門外，這些人的生意也就沒了。開設第二家分店可能需要幾個月的時間，增加面積也是如此。機會正在溜走。
聰明的企業需要正確的規模。對於墨西哥捲餅車來說，十萬平方英尺的面積實在太大了。所有這些空間都很昂貴，而且會分散注意力。對於超市來說，50 平方英尺太小了。人們幾乎進不了門。人行天橋和火車橋的建造方式不同。規模很重要，無論是向上還是向下。
這個想法並不難。它是工程學領域的靈魂所在。
新工程師所能做的最明智的事情就是關注企業的需求。無論是現在還是將來。
- 瞭解是什麼驅動了企業的成本和可擴充套件性需求。
- 瞭解它是如何賺錢的。
- 瞭解未來的預測以及隨之而來的風險。
- 忽略那些謠言和強烈的意見。
規模確實很重要，但它並不是分散式系統中唯一的考慮因素。