線上SpringCloud網關調用微服務跨機房了，咋整？

一、前言

公司內考慮到服務器資源成本的問題，目前業務上還在進行服務的容器化改造和遷移，計劃將容器化後的服務，以及一些中間件（MQ、DB、ES、Redis等）儘可能都遷移到其餘機房。

那大家爲何不用阿里雲啊，騰訊雲啊，還用本身的機房？

的確是這樣，公司內部目前仍是有專門的運維團隊。也是由於歷史緣由，當時業務發展比較迅猛，考慮到數據的安全性也是自建機房的。對於中小型公司這樣作，顯然成本過高了，因此通常都用阿里雲。對於中大型企業或者對數據安全性要求高的公司，自建機房維護的也再也不少數。

對於中間件來講，好比 Redis 緩存，有的業務也是由於歷史緣由，當時上線後都是單獨申請，並部署的一套集羣，可是量並非很大，因此相似這種狀況的，能夠考慮跟其餘項目使用的集羣合併爲一個，這樣就可能節省了一部分服務器資源。

如今大多數企業都已經微服務化，容器化了。

因此，將非容器化的業務要求都遷移到容器中，這裏的容器基本都是指 Kubernetes 平臺了，經過容器發佈調度服務，對於運維來講，維護變得更加便捷，高效。

對於研發來講，業務須要部署服務，再也不須要從新提 JIRA 工單，走一系列審覈流程，最後給到你的可能仍是一臺虛擬機，依賴的軟件單獨安裝部署。用了容器，只要在 集裝箱 中提早安裝好所需軟件環境，按照發布規範打好鏡像，發佈服務的過程一路就是 點點點...。

二、線上業務場景介紹

繼續來講今天的主題。

有一個項目是 SpringCloud 架構的，其中使用到了 網關 Zuul，而且也使用了到了 Eureka 做爲註冊中心。

由於該項目提早已經遷移到北京機房節點部署的容器環境，咱們最終目標是遷移到其餘機房(如：天津機房)。

北京有兩個機房：A機房、B機房，由於都在北京，因此兩個機房之間的 網絡延時 是能夠接受的。

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

此時，若是隻是將微服務部署到 天津機房，會變成以下圖所示的關係：

問題很明顯，就是網關服務只有北京的，而微服務新增了天津機房的，此時會致使 跨機房調用，即北京網關調用到了天津微服務。

儘管北京到天津 ping 的網絡延時僅有 3 毫秒 之差，可是服務與服務之間的調用，可就不止這 3 毫秒了。

其中包括服務器與服務器之間 TCP鏈接的創建、數據傳輸的網絡開銷，若是數據包過大，跨機房訪問耗時就會很明顯了。

因此呢，儘可能避免跨機房訪問，固然要將網關也要遷移到天津機房。

可是，你們看 粉紅色粗體 的線條，仍然存在跨機房調用，天津網關調用到北京微服務。

對於線上併發訪問量稍微大點，或者有些接口響應體大的，又或者網絡抖動等場景下，可能就會致使接口響應時間變長了。

如何解決呢？

因大部分業務都部署到天津，能夠將天津機房的服務權重調高

SLB配置 (類Nginx)：

upstream {
    server 北京機房網關IP  20；
    server 天津機房網關IP  80；
}

網關與微服務之間，都是經過 Eureka 註冊中心媒介來溝通，即 註冊服務 拉取服務。

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

Eureka 內部是基於 Ribbon 實現負載均衡的，自行實現按權重的負載均衡策略，Eureka作一點改造，界面上支持權重的修改。

下圖截圖了部分示例：

IP後面的就是權重值，能夠在界面上輸入權重值進行調整。

咱們能夠將北京微服務權重調低，天津微服務權重調高。

至關於網關以及微服務兩側都是經過基於 權重 的負載均衡算法來儘可能減小跨機房調用的，可是沒法避免跨機房調用。

使用 Eureka 的分區改進

上面描述的方案對於 20% 的流量仍然存在跨機房訪問，咱們能不能作到先訪問同一機房的服務，若是同一機房的服務都不可用了，再訪問其餘機房的呢？

答案是 能夠的。

咱們能夠藉助於 Eureka 註冊中內心提供了 region 和 zone 的概念來實現。

region 和 zone 兩個概念均來自亞馬遜的 AWS：

region：簡單理解爲地理上的分區，好比亞洲地區，或者華北地區等等，沒有具體大小的限制。根據項目狀況，自行合理劃分 region。

zone：簡單理解爲 region 內的具體機房，好比說 zone 劃分爲北京、天津，且北京有兩個機房，就能夠在 region 內劃分爲三個zone，北京劃分爲zone一、zone2，天津爲zone3。

結合上面的示例，假設僅設置一個 region 爲京津地區。

而後咱們給這個區域下的網關服務、微服務打上 zone 機房標籤，在系統運維上將機房也稱做 IDC 數據中心。

網關服務打上zone標籤：

微服務打上zone標籤：

這個功能都是在 Eureka註冊中心 上實現的，在給服務配置 zone 前，調用路徑以下所示：

給服務配置 zone 以後，框架內部的路由機制的實現下，調用路徑以下所示：

當前使用的 Eureka 是部署在北京，若是想讓服務在註冊、續約、拉取 動做時也能實現 就近機房訪問，部署架構就變成以下這個樣子：

北京區域不一樣機房假設認爲網絡延時小，因此北京兩個機房可使用同一個 Eureka 集羣；天津能夠單獨再部署一套 Eureka 集羣，這樣就能夠實現優先路由到同機房訪問。

服務註冊的關鍵配置

基本原理就是這樣，貼上一段 Eureka 使用 region 和 zone 的配置供你們參考：

spring:
  application:
    name: mananger
 
server:
  port: ${EUREKA_SERVER_PORT:8011}
 
eureka:
  instance: 
    # 全網服務實例惟一標識
    instance-id: ${EUREKA_SERVER_IP:127.0.0.1}:${server.port}
    # 服務實例的meta數據鍵值對集合，可由註冊中心進行服務實例間傳遞
    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配置]-開啓當前服務實例優先發現同zone的註冊中心，默認爲true
    prefer-same-zone-eureka: true
    # [服務註冊]-容許當前服務實例註冊，默認爲true
    register-with-eureka: true
    # [服務續約]-容許當前服務實例獲取註冊信息，默認爲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 內的第一個 zone，而後經過這個 zone 找到 service-url 對應該機房的註冊中心地址列表，並向該列表內的 第一個URL 地址發起註冊和心跳，不會再向其它的URL地址發起操做。只有當第一個URL地址註冊失敗的狀況下，纔會依次向其它的URL發起操做，重試必定次數仍然失敗，會間隔一段心跳時間繼續重試。

eureka.instance.metadata-map.zone:

服務提供者和消費者都要配置該參數，表示本身屬於哪個機房的。網關服務也屬於消費者，從註冊中心拉取到註冊表以後會根據這個參數中指定的 zone 進行過濾，過濾後向同 zone 內的服務會有多個實例 ，經過 Ribbon 來實現負載均衡調用。若是同一 zone 內的全部服務都不可用時，會其餘 zone 的服務發起調用。

另外注意一點 availability-zones 下 region 的配置是 ${eureka.instance.metadata-map.zone},... 這樣配置的好處是，你只要指定好了 eureka.instance.metadata-map.zone，優先會將這個參數放到可用分區下做爲第一個 zone 來訪問。

Zuul 網關路由分區源碼分析

網關使用的 zuul，其內部也是經過 ribbon 和 eureka 的結合來實現服務之間的調用，由於網關實際也是個服務消費者，一樣會註冊到 eureka 上，被網關拉取過來的註冊表裏的服務，做爲服務提供者，一樣會註冊到eureka上。

經過一張圖把控整個請求的大體脈絡：

上述圖示中部分核心源碼以下所示：

PollServerListUpdater#start(final UpdateAction action) 啓動後會每隔30秒（默認）去Eureka註冊中心拉取一次註冊表信息，更新本地緩存的數據結構。

調用到了DyamicServerListLoadBalancer匿名實現類中。

經過DyamicServerListLoadBalancer類調用了 updateListOfServer() 方法更新服務列表，serverListImpl的實現是DiscoveryEnabledNIWSServerList類

在DiscoveryEnabledNIWSServerList類內部會調用 obtainServersViaDiscovery() 方法，其內部經過 EurekaClient 來實現從 Eureka 註冊中心拉取服務列表。

過濾器內部獲取同一機房（zone）的服務列表，前後會調用 ZonePreferenceServerListFilter 和 ZoneAffinityServerListFilter 兩個過濾器實現 zone 的過濾。

最開始獲取的Servers一共是有4條記錄，根據調試的代碼看，咱們是爲了獲取 zone 爲2的服務，因此獲得的結果是一條，即 zone = "2" ，說明找到了同 zone 服務。

請求接口後會調用到 LoadBalancerContext#getServerFromLoadBalancer(...)，內部會調用到ILoadBalancer 具體實現的 chooseServer() 方法，最終會獲取到 zone="2" 裏的一個Server。

那麼這裏是如何選擇的Server呢？

本地調試時，只配置了已給可用的zone，因此這裏條件知足會直接調用 super.chooseServer(key) 父類的方法：

BaseLoadBalancer#chooseServer(...) 父類的選擇Server的方法，其內部經過 IRule#choose(key) 會調用到具體的負載均衡器的實現：

上述截圖中，能看到 MetadataWeightedRule ，這個類是咱們自行基於權重負載均衡實現。

該實現類是繼承了 ZoneAviodanceRule ，目的就是利用了 zone 的概念，所重寫的 choose(Object key) 方法，調用了 this.getPredicate().getEligibleServers(...) 會走一樣的過濾規則獲取到同一機房（zone）下的全部服務列表，而後在基於每一個服務配置的權重篩選一個Server。

獲取到 Server 後，拼接接口的URI請求地址 http://IP:PORT/api/.../xxx.json ，經過底層的 OkHttp 實現完成 Http 接口的調用過程。

好了，到此基本就分析完了，從網關請求，經過 ribbon 組件從 eureka 註冊中心拉取服務列表，如何基於 zone 分區來實現多數據中心的訪問。

對於 服務註冊，要保證服務能註冊到同一個 zone 內的註冊中心，若是跨 zone 註冊，會致使網絡延時較大，出現拉取註冊表，心跳超時等問題。

對於 服務調用，要保證優先調用同一個 zone 內的服務，當沒法找到同 zone 或者 同 zone 內的服務不可用時，纔會轉向調用其餘 zone 裏的服務。

本文提到的只是網關到微服務之間的調用，實際項目中，微服務還會調用其餘第三方的服務，也要同時考慮到跨機房調用的問題，儘可能都讓各服務之間在同機房調用，減小網絡延時，提升服務的穩定性。

歡迎關注個人公衆號，掃二維碼關注得到更多精彩原創文章，與你一同成長~