將應用從單機擴展到分佈式
計算機一共由5部分組成，探究從單機變化到分佈式時，構成計算機的這5個要素的變化。
一、輸入設備的變化
分佈式系統由通過網絡連接的多個節點組成，那麼，輸入設備其實可以分爲兩類：
1、互相連接的多個節點，在接收其他節點傳來的信息時，該節點可以看做是輸入設備；
2、傳統意義的人機交互的輸入設備了。
二、輸出設備的變化
輸出設備和輸入設備相仿， 也可以看做有兩種：
1、系統中的節點在向其他節點傳遞信息時， 該節點可以看做是輸出設備；
2、傳統意義的人機交互的輸出設備， 例如終端用戶的屏幕等。
三、控制器的變化
在單機系統中， 控制器指的就是CPU中的控制器。在分佈式系統中， 控制器不是像CPU中的控制器那樣的具體電子元件， 而是分佈式系統中的控制方式。
分佈式系統是由多個節點通過網絡連接在一起並通過消息的傳遞進行協調的系統。
控制器主要的作用就是協調或控制節點之間的動作和行爲。
【使用硬件負載均衡的請求調用】
這是一個進行遠程服務調用的場景， 其實也就是一個遠程的通信過程。在這個場景中， 請求發起方需要確定誰來處理這個請求， 如圖是在請求發起方和請求處理方中間有一個硬件負載均衡設備。所有的請求都要經過這個負載均衡設備來完成請求轉發的控制，這就是一種控制的方式。
【使用LVS 的請求調用】
二者差別僅在於中間的硬件負載均衡設備被更換爲了LVS (當然也可以是其他的軟件負載均衡系統)。這種方式主要的特點是
代價低， 而且可控性較強， 即你可以相對自由地按照自己的需要去增加負載均衡的策略。
我們一般稱上面的方式爲透明代理。在集羣中， 這種方式對於發起請求的一方和處理請求的一方來說， 都是透明的。
發起請求的一方會以爲是中間的代理提供了服務， 而處理請求的一方會以爲是中間的代理請求的服務。發起請求一方不用關心
有多少臺機器提供服務， 也不需要直接知道這些提供服務的機器的地址， 只需要知道中間透明代理的地址就行了。
這種方式存在兩個不足：
1、會增加網絡的開銷，這個開銷一方面指的是流量，另外一方面指的是延遲。如果使用LVS的TUN或者DR模式，那麼從處理請求服務器上的返回結果會直接到請求服務的機器，不會再通過中間的代理， 只有請求的數據包在過程中多了一次代理的轉發。在發送請求的數據包小而返回結果的數據包大的場景下， 使用代理的模式與不使用代理的模式相比只有很小的流量增加， 但是如果發送請求的數據包很大， 那麼流量增加還是比較明顯的。 而延時方面， 這裏只是根據這個結構提出了該問題， 實際的影響很小。
2、這個透明代理處於請求的必經路徑上， 如果代理出現問題， 那麼所有的請求都會受到影響。 我們需要要考慮代理服務器的熱備份。 不過， 在切換時，當時未完成的請求還是會受到影響。 當總體來說， 這是一種非常方便、 直觀的控制方式。
【採用名稱服務的直連方式的請求調用】
如上圖所示，同樣是完成請求發起到請求處理的請求派發工作，與透明代理方式最大的區別是， 在請求發起方和請求處理方這兩個集羣中間沒有代理服務器這樣的設備存在， 而是請求發起方和請求處理方的直接連接。
在請求發起方和請求處理方的直接連接外部， 有一個“名稱服務” 的角色， 它的作用主要有兩個：
1、收集提供請求處理的服務器的地址信息；
2、提供這些地址信息給請求發起方。 名稱服務只是起到了一個地址交換的作用， 在發起請求的機器上， 需要根據從名稱服務得到的地址進行負載均衡的工作。也就是說， 原來在透明代理上做的工作被拆分到了名稱服務和發起請求的機器上了。
優勢和不足：
1、這個名稱服務不是在請求的必經路徑上， 如果這個名稱服務出現問題， 在很多時候或者說我們有不少辦法可以保證請求處理的正常。
2、 發起請求的一方和提供請求的一方是直連的方式， 也減少了中間的路徑以及可能的額外帶寬的消耗。 而不方便的地方主要是代碼的升級較複雜。
【採用規則服務器控制路由的請求直連調用】
上圖這種方式與前面的名稱服務的方式很像， 只是這裏採用的是規則服務器的方式。
首先， 和前面的名稱服務的方式一樣， 在這種控制下，請求發起和請求處理的機器也是直接連接的， 請求發起的一方選擇請求處理的機器就要靠規則服務器給的規則了。
所以， 在請求發起的機器上， 會有對規則進行處理從而進行請求處理服務機器選擇的代碼邏輯。這個方式與名稱服務方式的不同在於：名稱服務是通過跟請求處理的機器交互來獲得這些機器的地址的，而規則服務器的方式中， 規則服務器本身並不和請求處理的機器進行交互， 只負責把規則提供給請求發起的機器。
【Master+ Worker的方式】
上圖控制方式是：存在一個Master 節點來管理任務， 由Master把任務分配給不同的Worker 去進行處理。
這種方式使用的場景和前面的幾種不太一樣。這裏沒有像前面介紹的那種請求發起和請求處理， 這個方式更多的是任務的分配和管理。
四、運算器的變化
在單機系統中， 運算器是具體的電子元件， 而在分佈式系統中， 運算器是由多個節點來組成的。單機的計算能力有上限， 而分佈式系統中的運算器是運用多個節點的計算能力來協同完成整體的計算任務。
用戶訪問單臺服務器網站的場景， 如下圖所示：
【單臺服務器的網站】
可以看到， 這是隻有單臺機器支撐的網站的情況。如果隨着壓力增大， 我們需要變爲多臺服務器，例如從一臺變爲兩臺，如圖1
【兩臺服務器的網站】
兩臺服務器一起完成工作， 用戶應該去訪問哪個服務器呢？我們有兩種做法來解決， 第一種做法如下圖所示：
【用戶訪問兩臺服務器的網站】
這種辦法是通過DNS服務器進行了調度和控制， 在用戶解析DNS的時候， 就會被給予一個服務器的地址。這樣的方式看起來就像我們在控制器部分提到的名稱服務或者規則服務器的方式， 中間沒有代理設備， 用戶能直接知道提供服務的服務器的地址。
【用戶訪問有負載均衡的網站】
和前面的方案不同， 我們在用戶和網站服務器中間增加了負載均衡設備（純硬件或者LVS等軟件都可以）。DNS返回的永遠是負載均衡的地址， 而用戶的訪問都是通過負載均衡到達後面的網站服務器。
總結起來， 構成運算器的多個節點在控制器的配合下對外提供服務， 構成了分佈式系統中的運算器。
我們再看另外一個場景， 也是一個很經典的場景－日誌的處理， 如圖所示
【單日誌處理服務器的日誌處理】
我們用一臺日誌處理服務器從多臺（例子中是3 臺）服務器上收集日誌並處理。隨着應用服務器的增多， 單臺日志處理服務器一定會遇到問題。那麼， 我們可以通過增加日誌處理服務器的數量來提升處理日誌的能力。
一種方案如下圖所示， 就是把前面看到的Master+Worker 方式的控制器運用到了這個日誌處理的場景。
【Master控制的多日誌處理服務器的日誌處理】
除了使用Master 控制日誌處理服務器集羣方式外， 我們也可以採用規則服務器的方式來協調日誌處理服務器的動作， 如圖
【規則服務器管理的多日誌處理服務器的日誌處理】
使用規則服務器來分配任務可能存在的最大問題是任務分配不均衡；
用Master節點的方式會對任務的分配做得更好些， 不容易導致處理不均衡的問題。
五、存儲器的變化
在單機系統， 我們一般把存儲器分爲內存和外存， 內存的數據在機器斷電、重啓或OS崩潰的情況下會丟失， 而外存是用於長久
保存數據的。
在分佈式系統中， 我們需要把承擔存儲功能的多個節點組織在一起， 使之看起來是“一個“ 存儲器。在存儲器中， 我們也需要通過控制器的配合來完成工作。下面使用最基礎的Key-Value場景來介紹：
【單機的 Key-Value 服務】
上圖中的場景是多個應用服務器使用單個KV存儲服務器的場景。隨着數據量的發展，我們需要把圖中的一臺KV存儲服務器擴展到兩臺來提供服務。
如何完成這個擴展呢？
方案一：在應用服務器與KV存儲服務器之間加一個代理服務器。這個代理服務器作爲控制器轉發來自於應用服務器的請求。而
轉發請求使用的策略與具體業務有非常密切的關係。一般可以根據請求的Key進行劃分(Sharding)。
【使用代理的多機Key-Value服務】
方案二：採用了名稱服務的方案。名稱服務用於管理在線的KV存儲服務器，並且把地址傳到應用服務器這邊。應用服務器會和KV存儲服務器直接聯繫。讓應用服務器與KV 存儲服務器直接連接， 那麼KV 服務器的選擇邏輯就放在了應用服務器上完成。
在實踐中我們根據不同場景有兩種實施經驗：
1、通過規則服務器的配合， 完成固定的Sharding 策略；
2、對等看待多臺KV 存儲服務器，能夠靈活地適應KV 存儲服務器的增加和減少。
【使用名稱服務的Key-Value服務】
方案三：使用了規則服務器的方案。省去了名稱服務，其實在這個場景中， 規則服務器的規則不僅寫明瞭如何對數據做Sharding, 還包含了具體的目標KV 存儲服務器的地址。
【使用規則服務器的Key-Value服務】
方案四：通過 Master 控制的 Key-Value 服務的方案。 這個結構同樣是應用服務器直接訪問KV存儲服務器的。 不同的是，Master 是根據請求返回目標KV存儲服務器地址，然後由應用服務器直接去訪問對應的KV 存儲服務器。相比名稱服務的方式， Master是根據請求返回對應的KV存儲服務器地址， 而不是返回所有地址， 所以具體的KV存儲服務器選擇工作在Master 上就 成了， 應用服務器上不需要有更多的邏輯；相比規則服務器的方式， Master並不是把規則傳給具體應用服務器， 再由應用服務器去解析並完成規則下的路由選擇， 而是Master自身完成了這個事情後把結果傳給應用服務器， 應用服務器只需要根據返回的結果去訪問這個KV存儲服務器就可以了。
【通過Master 控制的Key-Value 服務】
————————————————————————————————————————————