互聯網發展至今，各種互聯網應用以及云計算的普及，使得架構設計和軟件技術的關注點從如何實現復雜的業務邏輯(復雜的CRUD)，轉變為如何滿足大量用戶的高并發訪問請求。
舉個例子：比如一個簡單的計算處理過程，如果一旦面對大量的用戶訪問，整個技術挑戰就會變得完全不同，軟件開發方法、技術團隊組織、軟件的過程管理都會完全不同。
新浪微博剛開始只有兩個開發，一個前端一個后端，他們兩個人一周就把新浪微博開發出來了，但這是都十幾年前的事情了。現在新浪微博的技術團隊有上千人，這些人要應對的挑戰主要有兩個方面：一是復雜的功能，二是用戶量增加帶來的高并發訪問壓力。
這種挑戰和壓力幾乎是每個大型互聯網公司都要面對的。一個應用給幾個人用和給幾億人用是完全不同的。當用戶不斷增加的時候，需要消耗的計算資源也會不斷增加，需要更多的CPU和內存去處理用戶的計算請求，更多的網絡帶寬去傳輸用戶的數據，以及磁盤空間存儲用戶數據。當消耗的資源超過了服務器資源的極限時，服務器就會崩潰，整個系統就無法使用了。
那么我們應該如何解決高并發的用戶請求帶來的問題？
一、垂直伸縮與水平伸縮
為了應對高并發用戶訪問帶來的系統資源消耗，一種解決辦法是垂直伸縮。所謂的垂直伸縮就是提升單臺服務器的處理能力，花錢買更高配置的服務器來應對不斷增加的請求量。
在大型的互聯網出現之前，傳統的行業，比如銀行、電信這些企業的軟件系統，主要是使用垂直伸縮這種手段實現系統能力的提升。但是隨著用戶數量的提升，就需要不斷的去換配置更高的服務器，價格成本也越來越高，而且單臺服務器的配置是有上限的，以目前的互聯網發展狀態來說，這種方式顯然是不合適的，一般都采用水平伸縮。
所謂水平伸縮，就是通過多臺計算機構成集群，通過這個集群對外統一提供服務，以此來提高系統的整體處理能力。這種方式是目前普遍采用的分布式架構方案。
二、互聯網分布式架構演變
分布式架構是互聯網企業在業務快速發展過程中，逐漸發展起來的一種技術架構，包括了一系列的分布式技術方案：分布式緩存、負載均衡、反向代理與 CDN、分布式消息隊列、分布式數據庫、NoSQL 數據庫、分布式文件、搜索引擎、微服務等等，還有將這些分布式技術整合起來的分布式架構方案。
這些分布式技術和架構方案是互聯網應用隨著用戶的不斷增長，為了滿足高并發用戶訪問不斷增長的計算和存儲需求，逐漸演化出來的。可以說，幾乎所有這些技術都是由應用需求直接驅動產生的。
下面我們通過一個典型的互聯網應用的發展歷史，來看互聯網系統是如何一步一步逐漸演化出各種分布式技術，并構成一個復雜龐大的分布式系統的。
發展初期：單機部署
在最早的時候，系統因為用戶量比較少，可能只有幾個用戶，比如剛才提到的微博。一個應用訪問自己服務器上的數據庫，訪問自己服務器的文件系統，構成了一個單機系統，這個系統就可以滿足少量用戶使用了。
首次分離：數據庫與應用獨立部署
如果這個系統在業務上比較有價值，那么用戶就會快速增長。比如像新浪微博引入了一些明星大V開通微博，于是迅速吸引了這些明星們的大批粉絲前來關注。這個時候服務器就不能承受訪問壓力了，需要進行第一次升級，數據庫與應用分離。
前面單機部署的時候，數據庫和應用程序是部署在一起的。進行第一次分離的時候，應用程序、數據庫、文件系統分別部署在不同服務器上，從1臺服務器變成了3臺服務器，相應的處理能力也比之前的單機部署模式要高很多。這種分離基本上不需要花費什么技術成本，只需要把數據庫，文件服務器進行遠程部署，然后改下相應配置即可。
緩存登場：為數據庫遮風擋雨
而隨著用戶進一步增加更多粉絲加入微博，3臺服務器也不能夠承受這樣的壓力了，那么就需要使用緩存改善性能了。
緩存就是將應用程序需要讀取的數據放在緩存中，通過緩存讀取數據，而不是通過數據庫讀取數據。緩存主要有分布式緩存和本地緩存兩種。分布式緩存將多臺服務器共同構成一個集群，存儲更多的緩存數據，共同對應用程序提供緩存服務，提供更強大的緩存能力。
使用緩存，主要有兩方面的好處：
- 一方面應用程序不需要去訪問數據庫，直接訪問緩存，速度較快。
- 另一方面，數據庫中的數據是以原始數據的形式存在的，而緩存中的數據通常是以結果形式存在，比如已經構建成某個對象，緩存的就是這個對象，不需要進行對象的計算，這樣就減少了計算的時間，同時也減少了CPU的壓力。
最主要的，應用通過訪問緩存降低了對數據庫的訪問壓力，而數據庫通常是整個系統的瓶頸所在。降低了數據庫的訪問壓力，就是改善整個系統的處理能力。
業務暴漲：應用服務器集群
隨著用戶的進一步增加，比如微博有更多的明星加入進來，并帶來了更多粉絲。那么應用服務器可能又會成為瓶頸，因為連接大量的并發用戶訪問，這時候就需要對應用服務器進行升級。通過負載均衡服務器，將應用服務器部署為一個集群，添加更多的應用服務器去處理用戶的訪問。
數據庫再減負：讀寫分離
在微博上，我們主要操作是刷微博，也就是讀微博數據。如果只是明星們發微博，粉絲讀微博，那么對數據庫的訪問壓力并不大，因為之前還有緩存。但是粉絲也是會發微博的，發微博就是向數據庫中寫數據，這樣數據庫會再一次成為整個系統的瓶頸點。單一數據庫不能承受這么大的訪問壓力。
這時候的解決方案就是數據庫的讀寫分離，將一個數據庫通過數據復制的方式，分裂為兩個數據庫，主數據庫主要負責寫數據，然后寫后的數據同步到從數據庫上，保證從數據庫和主數據庫的數據一致。從數據庫主要提供數據庫的讀操作。
通過這樣一種手段，將一臺數據庫服務器水平伸縮成兩臺數據庫服務器，可以提供更強大的數據處理能力。
究極進化：完全分布式
對于大多數的互聯網應用而言，目前的分布式架構就已經可以滿足用戶的并發訪問壓力了。但是對于更大規模的互聯網應用而言，比如新浪微博，還需要解決海量數據的存儲與查詢，以及由此產生的網絡帶寬壓力以及訪問延遲等問題。此外隨著業務的不斷復雜化，如何實現系統的低耦合與模塊開發、部署也成為了重要的技術挑戰。
海量數據存儲主要是通過分布式數據庫、分布式文件系統、NoSQL數據庫解決。直接在數據庫上查詢已經無法滿足這些數據的查詢性能要求，還需要部署獨立的搜索引擎提供查詢服務。同時減少數據中心的網絡帶寬壓力，提供更短的訪問延時。使用CDN和反向代理提供前置緩存，盡快返回靜態文件資源給用戶。
為了使各個子系統更靈活易于擴展，則使用分布式消息隊列將相關子系統解耦，通過消息的發布訂閱完成子系統間的協作。使用微服務架構將邏輯上獨立的模塊在物理上也獨立部署，單獨維護，應用系統通過組合多個微服務完成自己的業務邏輯，實現模塊更高級別的復用，從而更快速的開發系統和維護系統。
微服務、消息隊列、NoSQL等這些分布式技術在出現早期的時候，比較有技術難度和使用門檻，只在相對比較大規模的互聯網系統中使用。但是這些年隨著技術的不斷成熟，特別是云計算的普及，使用門檻逐漸降低，許多中小規模的系統，也已經普遍使用這些分布式技術架構設計自己的互聯網系統了。
總結
目前越來越多的企業采用互聯網的方式開展自己的業務。傳統系統的用戶量是有限而確定的，倉儲系統主要面向的是倉庫管理員，企業內部系統主要面向的是企業內部人員。但是如果企業要對外開展業務，而且這個業務很有價值，那么用戶的增長速度會非常快。大量的用戶訪問企業系統，就會產生高并發的壓力，需要消耗大量的計算資源，如何合理并充分的利用增加的計算資源處理業務就是系統架構設計的核心驅動力。主要就是用各種分布式技術去應對高并發量的用戶請求。
但是為了解決高并發問題而采用分布式系統，引入一個集群必然帶來集群所需要處理的問題，比如啟用數據庫集群必然帶來數據如何在集群間分發、主庫讀寫分離如何避免讀庫的同步延遲導致數據不一致性、分布式系統之間的調用如何確保事務性、引入緩存如何避免緩存和數據庫的一致性問題等等
