假設有一次流量高峰，突然發現線上服務的可用率降低了，經過排查發現是有幾台機器比較舊了，當流量達到高峰時，這幾台機器由於負載太高，就扛不住壓力，那怎麼解決這種問題呢？
首先我們可能會想到，在治理平台上調低這幾台機器的權重，這樣的話，流量自然就減少了。
但是這樣會導致服務可用率降低，業務請求受到影響，那 rpc 框架有沒有什麼智慧型負載的機制？能及時地控**務節點接收到的訪問量？
當乙個服務節點無法支撐現有的訪問量時，會部署多個節點，組成乙個集群，然後通過負載均衡，將請求分發給這個集群下的每個服務節點，從而達到多個服務節點共同分擔請求的壓力的目的。
負載均衡只要分為軟負載和硬負載，軟負載就是在一台或多台伺服器上安裝負載均衡的軟體，如lvs，nginx等。硬負載就是通過硬體裝置來實現的負載均衡，如 f5 伺服器等。負載均衡的主要演算法有隨機法，輪詢法，最小連線法等。
那 rpc 框架中的負載均衡和上面的負載均衡是一樣的嗎？為什麼不新增負載均衡裝置或者 tcp/ip 四層**，網域名稱繫結負載均衡裝置的 ip 或者四層** ip 的方式。
因為可能會遇到下面的這樣幾個問題：
rpc 的負載均衡完全由 rpc 框架自身實現，rpc 的服務呼叫者會與「註冊中心「下發的所有服務節點建立長連線，在每次發起rpc呼叫時，服務呼叫者都會通過配置的負載均衡外掛程式，自主選擇乙個服務節點，發起 rpc 請求呼叫。
rpc 負載均衡策略一般包括隨機權重，hash、輪詢。這主要還是看rpc框架自身的實現。還可以通過控制節點權重的方式，來進行流量控制。
rpc 的負載均衡完全由 rpc 框架自身實現，服務呼叫者發起請求的時候，會通過配置的負載均衡外掛程式，自主的選擇服務節點，那是不是只要呼叫者知道每個服務節點處理請求的能力，再根據服務處理節點處理請求的能力來判斷要打給他多少流量就可以了？當乙個服務節點負載過高或響應過慢時，就少給他傳送請求，反之則多個它傳送請求。
那服務節點又該如何判定乙個服務節點的處理能力呢?
我們可以採用一種打分的策略，服務呼叫者收集與之建立長連線的每個服務節點的指標資料，如服務節點的負載指標，如服務節點指標、cpu核數、記憶體大小、請求處理的指標（如請求平均耗時、tp99、tp999）、服務節點的狀態指標（如正常、亞健康）。通過這些指標根據計算策略計算出乙個分數。我們可以為上面的指標都設定乙個指標權重佔比，然後再根據這些指標資料，計算分數。
服務呼叫者給每個服務節點都打完分之後，會傳送請求，那這時候我們又該如何根據分數去控制給每個服務節點傳送多少流量呢？
可與配置隨機權重的負載均衡策略去控制，通過最終的指標分數修改服務節點最終的權重。服務呼叫者傳送請求的時，會通過隨機權重的策略來選擇服務節點，那麼這個節點收到的流量就是其他正常節點的權重比。
示意圖如下：
關鍵步驟：
rpc之負載均衡
使用集群，比如zk來控制註冊中心，當乙個服務有多個請求位址的時候，會返回多個位址。那麼就需要負載均衡來控制我們要請求哪台機器來得到請求。方案一 隨機 傳入key值和key所包含的ip位址值，該位址值存入treeset中 有序儲存 獲得treeset的長度，然後隨機得到其索引，挑出隨機的乙個。publ...
負載均衡之LVS詳解
負載均衡 四層負載均衡 lvs 之前也寫過相關的文章，但是寫的太爛了。自己都不也敢直視。現在有空決定重新全面學習了下lvs.總結出本部落格。好了，其他的不多說了，我們開始吧。一 負載均衡 負載均衡包括如下 1 硬體負載均衡 f5,big ip citrix,netscaler a102 軟體負載均衡...
負載均衡之LVS詳解
負載均衡 四層負載均衡 lvs 之前也寫過相關的文章，但是寫的太爛了。自己都不也敢直視。現在有空決定重新全面學習了下lvs.總結出本部落格。好了，其他的不多說了，我們開始吧。一 負載均衡 負載均衡包括如下 1 硬體負載均衡 f5,big ip citrix,netscaler a102 軟體負載均衡...