線上SpringCloud網(wǎng)關調(diào)用微服務跨機房了,咋整?

1、前言

公司內(nèi)考慮到服務器資源成本的問題,目前業(yè)務上還在進行服務的容器化改造和遷移,計劃將容器化后的服務,以及一些中間件(MQ、DB、ES、Redis等)盡量都遷移到其他機房。

那你們?yōu)槭裁床挥冒⒗镌瓢。v訊云啊,還用自己的機房?

的確是這樣,公司內(nèi)部目前還是有專門的運維團隊。也是因為歷史原因,當時業(yè)務發(fā)展比較迅猛,考慮到數(shù)據(jù)的安全性也是自建機房的。對于中小型公司這樣做,顯然成本太高了,所以一般都用阿里云。對于中大型企業(yè)或者對數(shù)據(jù)安全性要求高的公司,自建機房維護的也不再少數(shù)。

對于中間件來說,比如 Redis 緩存,有的業(yè)務也是因為歷史原因,當時上線后都是單獨申請,并部署的一套集群,但是量并不是很大,所以類似這種情況的,可以考慮跟其他項目使用的集群合并為一個,這樣就可能節(jié)省了一部分服務器資源。

現(xiàn)在大多數(shù)企業(yè)都已經(jīng)微服務化,容器化了。

所以,將非容器化的業(yè)務要求都遷移到容器中,這里的容器基本都是指 Kubernetes 平臺了,通過容器發(fā)布調(diào)度服務,對于運維來說,維護變得更加便捷,高效。

對于研發(fā)來說,業(yè)務需要部署服務,不再需要重新提 JIRA 工單,走一系列審核流程,最后給到你的可能還是一臺虛擬機,依賴的軟件單獨安裝部署。用了容器,只要在 集裝箱 中提前安裝好所需軟件環(huán)境,按照發(fā)布規(guī)范打好鏡像,發(fā)布服務的過程一路就是 點點點...

docker集裝箱

2、線上業(yè)務場景介紹

繼續(xù)來說今天的主題。

有一個項目是 SpringCloud 架構的,其中使用到了 網(wǎng)關 Zuul,并且也使用了到了 Eureka 作為注冊中心。

因為該項目提前已經(jīng)遷移到北京機房節(jié)點部署的容器環(huán)境,我們最終目標是遷移到其他機房(如:天津機房)。

北京有兩個機房:A機房、B機房,因為都在北京,所以兩個機房之間的 網(wǎng)絡延時 是可以接受的。

微服務也同樣在這兩個機房之間都有部署。

北京A-B機房

此時,如果只是將微服務部署到 天津機房,會變成如下圖所示的關系:

微服務部署到天津

問題很明顯,就是網(wǎng)關服務只有北京的,而微服務新增了天津機房的,此時會導致 跨機房調(diào)用,即北京網(wǎng)關調(diào)用到了天津微服務。

盡管北京到天津 ping 的網(wǎng)絡延時僅有 3 毫秒 之差,但是服務與服務之間的調(diào)用,可就不止這 3 毫秒了。

其中包括服務器與服務器之間 TCP連接的建立、數(shù)據(jù)傳輸?shù)木W(wǎng)絡開銷,如果數(shù)據(jù)包過大,跨機房訪問耗時就會很明顯了。

所以呢,盡量避免跨機房訪問,當然要將網(wǎng)關也要遷移到天津機房。

網(wǎng)關部署到天津

但是,大家看 粉紅色粗體 的線條,仍然存在跨機房調(diào)用,天津網(wǎng)關調(diào)用到北京微服務。

對于線上并發(fā)訪問量稍微大點,或者有些接口響應體大的,又或者網(wǎng)絡抖動等場景下,可能就會導致接口響應時間變長了。

如何解決呢?

因大部分業(yè)務都部署到天津,可以將天津機房的服務權重調(diào)高

SLB配置 (類Nginx):

upstream {
    server 北京機房網(wǎng)關IP  20;
    server 天津機房網(wǎng)關IP  80;
}

網(wǎng)關與微服務之間,都是通過 Eureka 注冊中心媒介來溝通,即 注冊服務 拉取服務

僅僅在網(wǎng)關層配置好權重還不夠,此時還會存在天津網(wǎng)關路由到北京微服務上。

Eureka 內(nèi)部是基于 Ribbon 實現(xiàn)負載均衡的,自行實現(xiàn)按權重的負載均衡策略,Eureka做一點改造,界面上支持權重的修改。

下圖截圖了部分示例:

file

IP后面的就是權重值,可以在界面上輸入權重值進行調(diào)整。

我們可以將北京微服務權重調(diào)低,天津微服務權重調(diào)高。

相當于網(wǎng)關以及微服務兩側都是通過基于 權重 的負載均衡算法來盡量減少跨機房調(diào)用的,但是無法避免跨機房調(diào)用。

使用 Eureka 的分區(qū)改進

上面描述的方案對于 20% 的流量仍然存在跨機房訪問,我們能不能做到先訪問同一機房的服務,如果同一機房的服務都不可用了,再訪問其他機房的呢?

答案是 可以的

我們可以借助于 Eureka 注冊中心里提供了 regionzone 的概念來實現(xiàn)。

regionzone 兩個概念均來自亞馬遜的 AWS:

region:簡單理解為地理上的分區(qū),比如亞洲地區(qū),或者華北地區(qū)等等,沒有具體大小的限制。根據(jù)項目情況,自行合理劃分 region。

zone:簡單理解為 region 內(nèi)的具體機房,比如說 zone 劃分為北京、天津,且北京有兩個機房,就可以在 region 內(nèi)劃分為三個zone,北京劃分為zone1、zone2,天津為zone3。

結合上面的示例,假設僅設置一個 region 為京津地區(qū)。

然后我們給這個區(qū)域下的網(wǎng)關服務、微服務打上 zone 機房標簽,在系統(tǒng)運維上將機房也稱作 IDC 數(shù)據(jù)中心。

網(wǎng)關服務打上zone標簽:

網(wǎng)關zone

微服務打上zone標簽:

微服務zone

這個功能都是在 Eureka注冊中心 上實現(xiàn)的,在給服務配置 zone 前,調(diào)用路徑如下所示:

微服務架構

給服務配置 zone 之后,框架內(nèi)部的路由機制的實現(xiàn)下,調(diào)用路徑如下所示:

微服務架構zone

當前使用的 Eureka 是部署在北京,如果想讓服務在注冊續(xù)約拉取 動作時也能實現(xiàn) 就近機房訪問,部署架構就變成如下這個樣子:

微服務架構改進zone

北京區(qū)域不同機房假設認為網(wǎng)絡延時小,所以北京兩個機房可以使用同一個 Eureka 集群;天津可以單獨再部署一套 Eureka 集群,這樣就可以實現(xiàn)優(yōu)先路由到同機房訪問。

服務注冊的關鍵配置

基本原理就是這樣,貼上一段 Eureka 使用 regionzone 的配置供大家參考:

spring:
  application:
    name: mananger
 
server:
  port: ${EUREKA_SERVER_PORT:8011}
 
eureka:
  instance: 
    # 全網(wǎng)服務實例唯一標識
    instance-id: ${EUREKA_SERVER_IP:127.0.0.1}:${server.port}
    # 服務實例的meta數(shù)據(jù)鍵值對集合,可由注冊中心進行服務實例間傳遞
    metadata-map:
      # [HA-P配置]-當前服務實例的zone
      zone: ${EUREKA_SERVER_ZONE:tz-1}
      profiles: ${spring.profiles.active}
    # 開啟ip,默認為false=》hostname
    prefer-ip-address: true
    ip-address: ${EUREKA_SERVER_IP:127.0.0.1}
    # [HA-P配置]-當前服務實例的region
client:
    region: ${EUREKA_SERVER_REGION:cn-bj}
    # [HA-P配置]-開啟當前服務實例優(yōu)先發(fā)現(xiàn)同zone的注冊中心,默認為true
    prefer-same-zone-eureka: true
    # [服務注冊]-允許當前服務實例注冊,默認為true
    register-with-eureka: true
    # [服務續(xù)約]-允許當前服務實例獲取注冊信息,默認為true
    fetch-registry: true
    # [HA-P配置]-可用region下zone集合
        availability-zones:
      cn-bj: ${eureka.instance.metadata-map.zone},zone-bj,zone-tj
   service-url:  
      # [HA-P配置]-各zone下注冊中心地址列表
       zone-bj: http://BJIP1:8011/eureka,http://BJIP2:8012/eureka
       zone-tj: http://TJIP1:8013/eureka,http://TJIP2:8014/eureka

prefer-same-zone-eureka :

默認就為true,首先會通過 region 找到 availability-zones 內(nèi)的第一個 zone,然后通過這個 zone 找到 service-url 對應該機房的注冊中心地址列表,并向該列表內(nèi)的 第一個URL 地址發(fā)起注冊和心跳,不會再向其它的URL地址發(fā)起操作。只有當?shù)谝粋€URL地址注冊失敗的情況下,才會依次向其它的URL發(fā)起操作,重試一定次數(shù)仍然失敗,會間隔一段心跳時間繼續(xù)重試。

eureka.instance.metadata-map.zone:

服務提供者和消費者都要配置該參數(shù),表示自己屬于哪一個機房的。網(wǎng)關服務也屬于消費者,從注冊中心拉取到注冊表之后會根據(jù)這個參數(shù)中指定的 zone 進行過濾,過濾后向同 zone 內(nèi)的服務會有多個實例 ,通過 Ribbon 來實現(xiàn)負載均衡調(diào)用。如果同一 zone 內(nèi)的所有服務都不可用時,會其他 zone 的服務發(fā)起調(diào)用。

另外注意一點 availability-zones 下 region 的配置是 ${eureka.instance.metadata-map.zone},... 這樣配置的好處是,你只要指定好了 eureka.instance.metadata-map.zone,優(yōu)先會將這個參數(shù)放到可用分區(qū)下作為第一個 zone 來訪問。

Zuul 網(wǎng)關路由分區(qū)源碼分析

網(wǎng)關使用的 zuul,其內(nèi)部也是通過 ribboneureka 的結合來實現(xiàn)服務之間的調(diào)用,因為網(wǎng)關實際也是個服務消費者,同樣會注冊到 eureka 上,被網(wǎng)關拉取過來的注冊表里的服務,作為服務提供者,同樣會注冊到eureka上。

通過一張圖把控整個請求的大致脈絡:

網(wǎng)關請求源碼脈絡

上述圖示中部分核心源碼如下所示:

PollServerListUpdater#start(final UpdateAction action) 啟動后會每隔30秒(默認)去Eureka注冊中心拉取一次注冊表信息,更新本地緩存的數(shù)據(jù)結構。

PollServerListUpdater#start

調(diào)用到了DyamicServerListLoadBalancer匿名實現(xiàn)類中。

DyamicServerListLoadBalancer

通過DyamicServerListLoadBalancer類調(diào)用了 updateListOfServer() 方法更新服務列表,serverListImpl的實現(xiàn)是DiscoveryEnabledNIWSServerList類

DyamicServerListLoadBalancer#updateListOfServers

在DiscoveryEnabledNIWSServerList類內(nèi)部會調(diào)用 obtainServersViaDiscovery() 方法,其內(nèi)部通過 EurekaClient 來實現(xiàn)從 Eureka 注冊中心拉取服務列表。

DiscoveryEnabledNIWSServerList#getUpdatedListOfServers

過濾器內(nèi)部獲取同一機房(zone)的服務列表,先后會調(diào)用 ZonePreferenceServerListFilterZoneAffinityServerListFilter 兩個過濾器實現(xiàn) zone 的過濾。

ZoneAffinityServerListFilter#getFilteredListOfServers

最開始獲取的Servers一共是有4條記錄,根據(jù)調(diào)試的代碼看,我們是為了獲取 zone 為2的服務,所以得到的結果是一條,即 zone = "2",說明找到了同 zone 服務。

請求接口后會調(diào)用到 LoadBalancerContext#getServerFromLoadBalancer(...),內(nèi)部會調(diào)用到ILoadBalancer 具體實現(xiàn)的 chooseServer() 方法,最終會獲取到 zone="2" 里的一個Server。

LoadBalancerContext#getServerFromLoadBalancer

那么這里是如何選擇的Server呢?

本地調(diào)試時,只配置了已給可用的zone,所以這里條件滿足會直接調(diào)用 super.chooseServer(key) 父類的方法:

file

BaseLoadBalancer#chooseServer(...) 父類的選擇Server的方法,其內(nèi)部通過 IRule#choose(key) 會調(diào)用到具體的負載均衡器的實現(xiàn):

file

上述截圖中,能看到 MetadataWeightedRule ,這個類是我們自行基于權重負載均衡實現(xiàn)。

file

該實現(xiàn)類是繼承了 ZoneAviodanceRule ,目的就是利用了 zone 的概念,所重寫的 choose(Object key) 方法,調(diào)用了 this.getPredicate().getEligibleServers(...) 會走同樣的過濾規(guī)則獲取到同一機房(zone)下的所有服務列表,然后在基于每個服務配置的權重篩選一個Server。

獲取到 Server 后,拼接接口的URI請求地址 http://IP:PORT/api/.../xxx.json ,通過底層的 OkHttp 實現(xiàn)完成 Http 接口的調(diào)用過程。

底層Http請求

好了,到此基本就分析完了,從網(wǎng)關請求,通過 ribbon 組件從 eureka 注冊中心拉取服務列表,如何基于 zone 分區(qū)來實現(xiàn)多數(shù)據(jù)中心的訪問。

對于 服務注冊,要保證服務能注冊到同一個 zone 內(nèi)的注冊中心,如果跨 zone 注冊,會導致網(wǎng)絡延時較大,出現(xiàn)拉取注冊表,心跳超時等問題。

對于 服務調(diào)用,要保證優(yōu)先調(diào)用同一個 zone 內(nèi)的服務,當無法找到同 zone 或者 同 zone 內(nèi)的服務不可用時,才會轉向調(diào)用其他 zone 里的服務。

本文提到的只是網(wǎng)關到微服務之間的調(diào)用,實際項目中,微服務還會調(diào)用其他第三方的服務,也要同時考慮到跨機房調(diào)用的問題,盡量都讓各服務之間在同機房調(diào)用,減少網(wǎng)絡延時,提高服務的穩(wěn)定性。

最后編輯于
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容