背景：
初代的服務器架構往往比較簡單，應用程序、數據庫、文件、代碼等所有資源都放在一臺服務器上，也就是單機結構。隨着企業業務量的增多，一臺服務器已經難以滿足數據處理的需求了，那麼對單機進行“複製粘貼”，就能收穫一個處理能力高出好幾倍的“服務器集羣”。
不過，集羣式擴展很容易到達物理上限，最直接的反映就是無論怎麼增加節點，整個集羣的性能似乎也沒有被提升多少，這時候，就需要分佈式系統登場了。
如果說分佈式系統代表着網絡服務的發展方向，那麼雲計算的社會化，可能是其快速普及的重要推手。
集中式架構、分佈式架構、微服務架構圖解
什麼是分佈式？
所謂分佈式，就是將不同的服務模塊部署在多臺不同的服務器上，然後通過遠程調用協同工作，共同對外提供服務。對於用戶來說，就像是一臺計算機在服務一樣。
在實際業務中，分佈式系統可以將不同的業務功能對應到一個個獨立的子系統中去，比如針對電商平臺，可以將用戶服務、產品服務、店鋪管理、數據分析等不同的數據處理項目部署在不同的計算機集羣上。這些獨立的集羣可能是在不同的機房，甚至是不同的城市中，有的大型數據中心還會分佈在不同的國家和地區。它們之間通過RPC消息傳遞進行通信和協調，再向用戶提供服務。
在分佈式系統的背景下，企業架構也由早期的單體式應用架構漸漸轉爲更加靈活的分佈式應用架構，經歷了單體分層架構、SOA 服務化架構、微服務架構、雲原生架構等不同架構模式的變遷。後端開發不再侷限於單一技術棧，並且爲了應對更加龐大的集羣規模，單純的分佈式系統已經難於駕馭，因此技術圈開啓了一個概念爆發的時代：SOA、DevOps、容器、CI/CD、微服務、Service Mesh 等概念層出不窮，而 Docker、Kubernetes、Mesos、Spring Cloud、gRPC、Istio 等一系列產品的出現，標誌着雲時代已真正到來。
服務端開發與架構全景圖
分佈式缺點
分佈式場景下比較著名的難題就是 CAP 定理。CAP 定理認爲，在分佈式系統中，系統的一致性（Consistency）、可用性（Availability）、分區容忍性（Partition tolerance），三者不可能同時兼顧。在分佈式系統中，由於網絡通信的不穩定性，分區容忍性是必須要保證的，因此在設計應用的時候就需要在一致性和可用性之間權衡選擇。互聯網應用比企業級應用更加偏向保持可用性，因此通常用最終一致性代替傳統事務的 ACID 強一致性。