今天開始寫一個新的系列的文章，就是圍繞著分散式系統說說它的技術棧、實現思路和問題挑戰等等。這個內容不是很好寫，太大太廣，而且在技術日新月異的今天它也在不斷髮展探索更好的實現。我只能盡我所知，儘可能把這部分內容整理彙總在這裡。我也不清楚什麼時候可以整理完，但是會盡快。

發展歷程

在一個網站發展初期，訪問量和資料量還沒有上升到一定的量級之前，系統都是以一個單體應用(比如一個war包)形式部署在tomcat的。據說在2003年淘寶最初上線的時候，就是以一套以當時十分風靡的LAMP架構(Linux+Apache+MySQL+PHP)實現並部署的。單體應用架構的特點就是功能和程式碼集中、一個釋出包部署後執行在一個程序內的應用程式。

需要注意的一點時，單體應用內部可能也實現了我們常說的分層的概念，比如MVC(Modal-View-Controllor)。此時其實分層的概念只是實現了邏輯上的分層，也就是說不論是web層、service層還是dao層，程式碼依然是部署在一起的。所以說分層只是說是對於一個系統來說只是一種邏輯上的水平劃分。

後期當業務發展，網站的訪問量上升後，由於單個應用上的併發訪問瓶頸，可能會導致系統響應速度下降甚至無響應。此時就需要對系統做一些升級以支撐高訪問量，此時有兩種方案可考慮：

1.垂直拓展

砸錢上更NB的伺服器，提升效能；

2.水平拓展

將單體應用部署更改為叢集部署，並根據情況增減節點；

一般情況下都會選擇第二個方案進行拓展，但注意此時的叢集還是單體應用的叢集。而單體應用說穿了，仍然是一個單程序的應用，也就是說應用內所有的業務操作(可以理解為執行緒)都共享這個程序的資源和記憶體空間，如果業務量進一步急劇上升，那麼單純地靠叢集擴容也將很難去解決問題。

這個時候，我們就需要將這個單體應用拆分成多個應用，多個應用(叢集)協同提供服務。系統拆分的維度有如下的總結：第一是系統維度，也就是簡單地按業務邊界去拆分；第二是功能維度，對一個業務內的不同功能進行拆分；第三是讀寫維度，進行讀寫的分離；第四是模組維度，對已經拆分的模組再按MVC分層部署。

以上的拆分維度不一定需要完全實現，可以根據具體業務量和實際情況進行處理。當系統走到這一步的時候，我們可以說這已經是一個分散式系統了。可以總結出，所謂分散式就是將不同模組部署在不同的伺服器上，通過遠端呼叫協同工作。

繼續優化

以上是我們將一個單體應用逐漸去拆分成了一個分散式應用的過程，也是我們隊應用部署層面的一個優化。那麼當業務不斷髮展，使用者量上升到新的一個層級的時候，為了解決高併發訪問、海量資料儲存、高可靠執行等問題，我們可能還需要進一步從如下方面進行優化：

動靜分離

對於業務載入需要的一些不經常改變的靜態資料，可考慮將其快取到CDN伺服器上而不是每次都到我們的應用伺服器進行獲取，這樣可以減少伺服器的壓力。CDN(內容分發網路) 是運營商提供的服務，伺服器部署在機房，可以根據使用者訪問的鏈路直接選擇最近的CDN伺服器將已快取的靜態資料返回，加快靜態資料載入速度。

負載均衡

體現在兩個方面，一是使用者對伺服器的請求均衡，二是伺服器與伺服器之間的呼叫請求均衡。可通過輪詢、加權或指定規則將請求平均地分散到每臺伺服器上。

分庫分表

資料量進一步增多，當單庫已經成為資料訪問或操作的效能瓶頸的時候，我們就需要對資料進行分庫分表操作。分庫就是依據不同業務，將不同的業務資料儲存到不同的業務資料庫中；分表就是，當統一業務資料表(比如訂單表)資料量巨大單標無法承受的時候，就將其按照一定規則拆分為多個同構的表分散儲存。

快取

對於一些經常訪問的熱點資料(讀多寫少)，就不適合每次都從資料庫進行獲取，一來是速度慢，二來是消耗資料庫連結資源。進行讀寫快取後，可顯著提升資料讀寫速度。快取可以分為本機快取和分散式快取。

非同步

將一個複雜的業務操作轉換為多個階段操作，每個階段的操作通過訊息佇列進行非同步處理。可以理解為生產者-消費者模式，好處是加快系統響應速度和消除併發高峰(消峰)。

冗餘

為抵抗一些不可控因素，如自然災害(火災、地震)等因素導致系統不可用，應考慮異地建立容災中心，資料實時備份，可參考阿里提出的“兩地三中心”概念。

自動化

讓系統在無人值守的情況下仍可以正常執行。自動化包括監控、告警、失效轉移恢復、降級等功能。

分散式系統的優點

效能提升

相比單體應用而言可以支撐更高的併發訪問

技術異構

每個服務的技術實現可以不同，只要約定好相互的呼叫介面即可；

彈性擴充套件

根據業務需要可以靈活地上線下線叢集內的節點；

簡化部署

節點間部署互不影響

當然，凡事有利也有弊，我們使用分散式系統也會引入一些單體系統沒有的問題，下文中我們將詳細探討。

系列文章：