分布式服務呼叫策略：
1. lvs
中間**，負載均衡系統做**
優點：代價低，可控性強
缺點：流量壓力大+必由之路，雞蛋不在乙個籃子裡
應用：面向c端
2. 名稱服務
各呼叫方機器：自己根據策略進行負載均衡
優點：名稱服務不會直接影響功能+減少了中間的頻寬消耗
缺點：**公升級較複雜 - > 當拉起一台伺服器，需要把新的ip賦值給所有的請求發起方。而且需要有一定的節奏。
應用：內部服務註冊服務
3. 規則伺服器（一般不會用在無狀態的服務場景）
不與請求處理的機器互動只負責把規則提供給請求發起的機器
優缺點：與名稱服務類似
小結：
a. 公司的服務治理工具採用的是方案二（推測依據：請求發起方有檔案儲存了所有的被呼叫方的ip，而且實時在改變）
b.這裡面突然發現以前辛辛苦苦看的tomcat伺服器原始碼並不是沒有作用：
對於被呼叫方，在方案二和方案三的情況下都需要對某埠進行監聽，然後對於請求進行 解析->呼叫->返回。這不就是乙個完整的服務監聽與相應的流程麼？ 無非就是請求的解析和返回編碼不太一樣，核心流程還是差不多的。
nio監聽->解析請求->執行緒池反射呼叫方法->處理返回值
分布式架構服務呼叫
和傳統的單體架構相比，分布式多了乙個遠端服務之間的通訊，不管是 soa 還是微服務，他們本 質上都是對於業務服務的提煉和復用。那麼遠端服務之間的呼叫才是實現分布式的關鍵因素 j a 原生 httpurlconnection是基於http協議的，支援get，post，put，delete等各種請求方 ...
分布式服務呼叫問題處理總結
面試 你懂什麼是分布式系統嗎？redis分布式鎖都不會？業務特點 運營push傳送數量較大，傳送時間密集，同一時間段呼叫baixin傳送push的數量幾十萬上百萬不等。問題描述 之前我們的push傳送使用兩個專案實現，分別是 在運營push業務裡，push專案使用執行緒數量為200的固定執行緒池傳送...
分布式之遠端呼叫服務open feign
1.feign是乙個宣告式的web service客戶端。它的出現使開發web service客戶端變得很簡單。使用feign只需要建立乙個介面加上對應的註解，比如 feignclient註解。feign有可插拔的註解，包括feign註解和jax rs註解。feign也支援編碼器和解碼器，sprin...