#96 分散式系統介紹

分散式系統是我念書過程裡最喜歡的課程之一，也是以前我的研究領域．這一門課通常開設在碩博士班的課程裡，因為這門課需要不少基礎的課程，如果開在大學部的話，也一定是屬於大四選修課的內容．它的先修課程包含了作業系統, 演算法, 資料庫理論, 網路理論，網路程式設計等．它有一個兄弟課程叫分散式演算法．這兩門課蠻接近的，對我而言，分散式系統是比較以工程實作導向來討論分散式系統，而分散式演算法是以數學和演算法更嚴謹的電腦理論來談許多分散式系統裡所需要的運作細節. 我剛好都修過這兩門課，所以都清楚這兩個課程的內容．由於這個部落格的目的是將較不好懂的電腦理論用較白話易懂的方式來介紹給大家，所以在分散式系統的文章裡，不會著重在分散式演算法的內容．這是分散式系統系列文章的第一篇，所以會用一個較宏觀的角度來說明什麼是分散式系統.

在 1980 年代以前，電腦科學的理論已經發展的很快了，但實際上的 "商業化產品" 並還沒有大量地出現．然後在 80 年代開始，個人電腦漸漸地普及，並且 Internet 也開始大量地商業化．因此，從這個年代開始漸漸地有商業的分散式系統出現. 我們先簡單定義一下什麼是分散式系統． 用一個不是很精確的定義，分散式系統是由一群電腦一起互相合作然後達成一個共同目標或任務．舉個例子, email．發電子郵件對現在的你來說是幾乎每天都會做的事情．當你在電腦上打開郵件程式，編寫一封 email，寄給在其他位置的使用者．這封信件會從你的電腦傳送到你對應的 email server，然後再從你對應的 email server 一路展轉到目地端的 email server， 最後收件人打開他的郵件程式再把這封 email 下載到他的電腦上．所以, 整個電子郵件就是一種分散式系統，它需要一堆電腦，這些電腦可以連線用來傳送訊息，進而達成讓人們溝通的目的．分散式系統就是在討論這麼多電腦在彼此互相合作達成某個任務或目的時會遇到的問題以及相關的基礎知識和解決方式.

從這樣的定義你可以了解到現在的時代 (2022) 裡有許許多多的分散式系統．例如，WWW 可說是目前全世界最大的分散式系統. 還有許多 online game 也是分散式系統的一種. 像台灣人常用的 LINE 也是分散式系統的一種. 現在因為處理器能力大增加上軟體工具的進步，所以 AI 的應用可以漸漸地在生活上看見．如果那一天你發現某一個計程車行推出了自動駕駛計程車，不需要司機操作，完全由系統自行決定如何運行，從被客人呼叫，載客，到個計程車之間的行程調派等．這也是分散式系統的一種. 再舉另外一個例子，如果某一個國家或公司發展出先進的飛彈系統，這些飛彈能在發射之後，在空中彼此溝通，彼此協調目標，然後把所有的目標都命中． 不在是傳統的一個飛彈飛到一個固定的點或目標．別懷疑，這也是分散式系統的一種．

從這些例子，我相信你可以強烈地感受到什麼是分散式系統．這門學問基本上就是一種討論如何 "打群架" (多台電腦協同運作)，用一台電腦打不過 (達不成目標)，那只好找一堆電腦來一起打．要叫一台電腦做一件事，這是簡單的，但要叫一堆電腦一起做事來達成一個共同目標，這就顯的複雜許多．這也呼應了一開始所說的，分散式系統的先修科目有作業系統, 演算法, 資料庫，網路等等. 

因此，你可以知道，分散式系統是一堆電腦透過網路連線能彼此溝通進而達成一個任務．電腦不局限是電腦，也可以看成是某一個電腦程式．網路不局限於有線或無線，也不局限於區域網路或廣域網路．概念上，分散式系統的定義是可以很廣泛的．不同的任務所需要底層知識會有差別．例如，email 是一種分散式系統，不論你是用那一種電腦系統，不論你的 email 程式是用什麼語言寫的，也不論你的 email server 在世界上的什麼地方，這些都不應該是障礙．所以，為了讓某一個分散式系統能夠商業化地運行下去，必須定義許多 "標準" 好讓不同的軟體廠商可以依這些標準來產生可行的工具，這樣這個分散式系統才能成功．所以，不同分散式系統的應用就能看到不同的標準．例如, email 系統要定義出 email address 的合法格式，要定義出 email 內容的合法規格，要定義出 server 和 server 之間的溝通方式和通訊協定等，也要定義 server 和 mail client 之間的溝通方式等．從 email 系統的例子，你可以看到光是網路通信就有很多標準要完成．有許多的分散式系統不見得需要走向標準化．因為一些商業考量，有些公司喜歡有自己的應用，例如早期的 ICQ, MSN messenger, 到現在的 LINE．這類似的分散式系統是相對較封閉的分散式系統，因為是由某一家公司自己主導與開發，所以每家公司所使用的 "標準" 就不見得是一致的，各家都可能不一樣.

希望這一篇短文能幫助你了解什麼是分散式系統，下一篇文章，我們將介紹分散式系統裡會面臨到的挑戰，而整個系列文章將會圍繞在這些挑戰來介紹相關的解決方案.

閱讀全文

#41 Load Balance 負載平衡

Load Balance 顧名思義就知道是在兩個以上的運算器環境下將每個運算器的運算負載量達成一致的目的．這樣子的概念應該在許多的情境之下，例如大型網站或是大型的資料庫等．這種類型的情境一定都有一個共同的特點，那就是 request 的 client 很多而提供 service 的 server 很少．

我們以大型網站服務為例子．最先開始架設一台網站伺服器來服務某一數量的用戶端，只要用戶端不繼續增加或是服務本身的運算邏輯沒有變的更複雜時，則一切都會相安無事．只要其中一個有增多的現象時，最終總是會面臨到該網站伺服器的資源不用使用的情況．因為每個用戶端連線都需要佔用 CPU/Memory 資源，所以既便是 CPU 再快 Memory 再多，也是會遇到上限．因此，要解決的方法有兩種，一個稱為 scale up，另一個稱為 scale out．Scale up 是指在同一個伺服器內進行硬體的升級以求在同一時間內服務更多的用戶端，例如升級 CPU，記憶體，網路卡等等．Scale out 是指再加入其他的伺服器來服務用戶端．通常來說，scale up的方式比較受限，而且一台伺服器若是要能裝入更多的 CPU 和 Memory，則價錢通常都是非常地高，所以比較經濟的做法就是 scale out．

Scale out 第一個會遇到的問題就是該如何分派工作．既然要達到負載平衡，也就是每台伺服器的運算負載量是接近一致的，那麼首要考慮的事情就是該如何達到一致．如果每個用戶端所要求的工作量都是固定的，很容易就可以做到負載量是一致的．因為只要在這些伺服器前都有一個 dispatcher 來輪流地分配工作，就可以達成負載量一致的效果，就如下圖一樣．

這種方式有一個缺點，dispatcher 將會是 single point of failure，單一失敗點，也就是說它若壞掉了，整個系統便無法運作．這種運作方式也稱為 Round-robin，輪流分配工作．在直實世界中，我們很難要求每一個用戶端都會有相同的運算工作量，因此每個用戶端送過來的需求一定會有不同的運算工作量，因此用 round-robin 的方式是很難達成負載量一致的，只能說是用戶端需求分配數量是一致的，因為很有可能某一個伺服器都會收到運算量很大的工作導致它比別的伺服器來的更加忙碌或是資源更吃緊．Round-robin 的方式算是集中式的管理，因為都是透過 dispatcher 來運作．

另外還有一種比較常見的負載平衡的方法是不需要 dispatcher，而是伺服器之間要互相溝通訊息，把自己的負載量資訊傳給其他的伺服器．所以每個一伺服器都會有一份每個伺服器負載量的資料，而且這分資料是經常地在更新．因此，當新的用戶端需求進來時，這份需求會先被某一個伺服器接收，然後該伺服器會依照這份資料來決定這份工作是要自己做還是傳給其他伺服器來做，這就看系統實作的是什麼樣的演算法．若採用最簡單的，也就是挑選負載量最小的伺服器，那這份工作就會被傳送到負載量最小的伺服器來處理．

這個方式聽起來似乎比較好，因為不會有 single point of failure 的問題，只是這樣的伺服器集合不適合有太多的伺服器在一起．我們簡單地想像一下，如果這個群組有十台伺服器，每一台伺服器在每隔幾秒鐘就要彼此交換負載量的資訊，這似乎不會是一個太麻煩的工作，但如果這群組變成是一百台或是一千台伺服器時，這樣的方法顯然會有問題，因為光是和其他 999 台伺服器完成一輪的負載量資訊交換可能就要花上一段時間和不少的 CPU 與 Memory，顯然不是一個經濟的做法，而且也不見得能儘量達成負載平衡．

其實在許多伺服器之間要對一份資料取得共識，也就是說一號伺服器上收集到的資料和 n 號伺服器上收集到的資料是一樣的，這也是一個很大的學問．往後的主題將會來討論這部份．

閱讀全文