# 虎年行大運 ~ SpringCloud - 負載平衡架構的歷史

## 【前言】
要進到分散式架構以前，首先聊聊過往為了處理負載平衡的系統架構設計類型。

為什麼會需要負載平衡這種服務存在呢?

那是因為在日益成長的用戶使用量上，就算是硬體擴充，也有其負擔的極限。秉著工程師們引以為傲的演算法設計概念，這種事情也一定有可以解的方法，為此良好的服務分流概念便逐步被人設計了出來，不論是現在常用的負載平衡甚至後續的微服務架構，其目標都是為了減輕流量負擔的作法。

在這裡要介紹的負載平衡架構大致分成了兩類：**Server 端負載平衡**和 **Client 端負載平衡**
一如其名，指的就是在哪一端去執行平衡的動作。

下面用簡單的發展圖示說明~

## 【Server 端負載平衡】
搭配下圖說明整個結構的發展由來~

* Step_1
一台正常規格的伺服器，面對數十人、數百人的使用量還算是負擔的起

* Step_2
達到數千、數萬人開始便顯得吃力

* Step_3
我們想加入一台新的伺服器(81)，但透過 Host 的方式，使用者們只會連到 80 那台而已

* Step_4
此時我們針對 Host 的部分，加入了負載平衡器(80)，讓他去分配使用者連線時該去哪一台伺服器

* Step_5
但又有問題了，因為連線是由負載平衡決定的，因此當一個使用者的資料存於 A 伺服器，但下一次想要提取的時候卻連線到 B 伺服器，便會出現沒有資料可以提取的狀況

* Step_6
在資料的部分增加了快取伺服器，讓所有伺服器統一到一個地方提取資料，避免有誤。此作法同樣適用於 DB 設計。

至此完成了最基本款的 Server 端負載平衡！


## 【Client 端負載平衡】
搭配下圖說明~

* Step_1~3 與 Server 端一樣，不多加說明
* Step_4
針對 Host 的部分，加入了註冊中心(80)，讓他去紀錄有哪些伺服器註冊其中

* Step_5
使用者們後續會與註冊中心連線，與負載平衡器的不同點在於: 每個硬體設備會有其極限，負載平衡器也不例外，因此不可能為了負載平衡器又做出了一個負載平衡 **負載平衡器** 的架構出來

* Step_6
使用者們與註冊中心連線後，註冊中心返回目前的註冊清單

* Step_7
取得清單後，由使用者們自己的電腦去進行輪巡，去連結各個伺服器，減輕伺服端的負擔

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `SpringCloud`