java B2B2C Springcloud電子商務平臺原始碼-RIBBON 核心設計和原理分析

小兵2147775633發表於2019-01-29

Ribbon, Netflix 公司開源的用於程式通訊場景的經過實戰檢驗的客戶端專案。它提供了遠端呼叫的負載均衡,網路狀態檢查和容錯等功能。Ribbon 基於軟體的負載均衡方式與目標叢集中的機器進行通訊。這裡忽略狀態統計部分,健康檢查的邏輯部分,重點分析負載均衡部分。

需要JAVA Spring Cloud大型企業分散式微服務雲構建的B2B2C電子商務平臺原始碼 一零三八七七四六二六

下面是個典型的使用方式開始,先指定一些目標伺服器地址,

sample-client.ribbon.listOfServers=www.taobao.com:80,www.baidu.com:80,www.sina.com:80
複製程式碼

然後藉助ribbon 封裝的 httpClient 來傳送請求(訪問站點首頁),迴圈20次是希望列印出負載均衡的效果。

RestClient client = (RestClient) ClientFactory.getNamedClient("sample-client");  
HttpRequest request = HttpRequest.newBuilder().setUri(new URI("/")).build();
for (int i = 0; i < 20; i++)  {
  HttpResponse response = client.executeWithLoadBalancer(request);
  System.out.println("Status code for " + response.getRequestedURI() + "  :" + response.getStatus());
}
複製程式碼

下面按 Ribbon 的主要模組進行設計分析,並在最後部分分析上述程式碼的效果。

Ribbon-core 模組 這一模組中,主要定義通用的呼叫抽象。ribbon 的 client 處理請求並返回響應。

public interface IClient<S extends ClientRequest, T extends IResponse> {
    public T execute(S request, IClientConfig requestConfig) throws Exception;
}
複製程式碼

ClientRequest, 是獨立於所以具體實現的通訊協議的抽象。它主要包括:uri(遠端資源的定位符),loadBalancerKey(Object型別,這是決定請求呼叫到目標伺服器的關鍵資訊),isRetriable; 當然它的具體實現類,可能還有請求headers,body等資訊。

IResponse, 是服務端響應的抽象,主要包括: body(payload),isSuccess(響應狀態的簡化),響應headers,請求url;

VipAddress 術語,是一個地址的邏輯名,該邏輯名代表一系列目標伺服器。比如“apple.bar:80”。

RetryHandler,用來決定哪些異常(比如:ConnectException,SocketTimeoutException)發生時要做重試,哪些異常(SocketException,SocketTimeoutException)發生時表示應該熔斷掉(對應伺服器)的呼叫,預設的是不重試。

Ribbon-loadbalancer 模組

負載均衡,巨集觀上效果是希望將請求的流量均衡(不是簡單意義上的平均)的負載到提供服務的伺服器之上。而對於每次請求而言,是通過計算拿到一個目標伺服器地址的。

ILoadBalancer

ILoadBalancer, 負載均衡器的介面。它的核心方法是 public Server chooseServer(Object key); 每次請求發生時根據引數傳入的 loadBalancerKey物件,決定出一個目標的伺服器地址。Server 表示一個伺服器(包括:主機地址,埠號以及一些後設資料標識資訊)。 那麼服務均衡器應該需要有一批可供選擇的目標服務集合吧,所以它還有個重要方法 addServers(List newServers),一般在啟動階段就要完成初始化地呼叫。

BaseLoadBalancer

BaseLoadBalancer(實現 ILoadBalancer),這裡宣告瞭一個基礎lb,應該關聯個 IRule(負載均衡的規則)預設是輪詢規則:RoundRobinRule)。 它還預設支援一個Ping檢查功能(可以幫忙我們定時檢查目標伺服器是否可通訊)的定時任務,開發者可以在構造例項時明確指定 Iping(判斷一個服務是否還是活的),IPingStrateg 預設是序列地檢查策略,但如果目標服務地址過多,或者IPing執行過慢就不太合適。

IRule 路由規則,Rule 和 LoadBalancer 是一對一的相互關聯關係,Rule 是具體的負責均衡策略。常見的規則包括: 輪詢,隨機,基於響應的延遲等; public Server choose(Object key)核心方法的輸入輸出基本一致,區別是 Rule 拿取目標 server list 是通過藉助對應依賴的 LoadBalancer 拿到的。

DynamicServerListLoadBalancer

DynamicServerListLoadBalancer(繼承 BaseLoadBalancer),事實上從啟動後一直不變的 ServerList 場景一般不太多,尤其在微服務場景:服務掛了,擴容,縮容等都會需要對服務消費方的客戶端的服務列表做出實時調整(通常藉助服務發現產品:eureka,consul,zk...),DynamicServerListLoadBalancer 顧名思義就是針對該類場景的。要做到執行時實時更新,既要保證更新的實時可見,也要保證更新操作本身的同步。

ServerListUpdater,是動態服務列表的更新器。現實場景中一般有個專門提供釋出和查詢/訂閱服務列表服務的角色,這裡暫時簡稱為”遠端登錄檔服務”。更新 ServerList 常見的有兩種實現模式:push 或者 pull。 push 機制就是客戶端保持對“遠端登錄檔服務”觀察就行,伺服器發生變化時會,客戶端就會及時得到通知。 還有一種 pull 機制,一般是頻繁的發請求進行詢問“遠端登錄檔服務”是否有變化發生。這個一般建議基於常見的服務發現產品進行實現。

ServerListFilter,是DynamicServerListLoadBalancer的可選構造引數之一。作用是在發生 ServerList 更新時篩選過濾出符合條件的一個子集。 因為 ServerList 可能比較大,包含成百上千臺機器地址,如果都嘗試去呼叫,那麼客戶端的連線數就會非常多,這也會造成必要的消耗。

Ribbon-httpclient 模組

ribbon-loadbalancer 模組中有個 ClientFactory 靜態工具類,可以生成和管理多個名字唯一的 IClient 具體例項。ClientFactory.getNamedClient("sample-client");,這裡因為未特殊配置(指定具體的 IClient 的實現類),所以選擇的是預設的Client實現類 com.netflix.niws.client.http.RestClient。

RestClient

RestClient,是 ribbon-httpclient 模組中針對 IClient 的具體實現,通過使用 Jesery Client (實際依賴 apacheHttpClient4 傳送 http),同樣 HttpRequest 實現 ClientRequest,而HttpResponse 實現了 ClientResponse。

client.executeWithLoadBalancer(request),是client的父類 AbstractLoadBalancerAwareClient 中定義的方法,最終是呼叫 LoadBalancerContext#getServerFromLoadBalancer(URI,loadBalancerKey)方法,該方法主要LB邏輯如下:

Server svc = lb.chooseServer(loadBalancerKey);
if (svc == null){
    throw new ClientException(ClientException.ErrorType.GENERAL,
            "Load balancer does not have available server for client: "
                    + clientName);
}

//... check host not null

logger.debug("{} using LB returned Server: {} for request {}", new Object[]{clientName, svc, original});
return svc;
複製程式碼

java B2B2C Springcloud電子商務平臺原始碼

相關文章