Hyperbahn 是 Uber 開源的一套服務發現和路由系統，專門用於包含大量微服務的大規模系統，可以使服務間的發現和溝通非常簡單和可靠。 目前該庫已經不活躍了，不再更新。與etcd、zookeeper和consul等產品具有相同的作用。

Affinity(親和性策略)

|----------------------------------------------------------------------|
|    ____________            ____________          -------> worker..1 |
|   |           |           |           |         |                    |
|   | Hyperbahn |---------->| relay ring|-------->|-------> worker... |
|   |  server   |           |           |         |                    |
|   |___________|           |___________|         |-------> worker..N |
|                                                                      |
|----------------------------------------------------------------------|

                        Hyperbahn服務與後端服務之間的關係

上面畫的這幅圖，我是在微信開放平臺時瞭解到relay的，微信說是中繼伺服器，用來刷token和託管公眾號的token的，這樣web使用者訪問時，就不需要進行token獲取了。託管業務也就直接可以操作相關微信業務了。

這個Hyperbahn relay應該也是同理，負責處理Hyperbahn與後端服務之間的連線管理。

這樣再翻譯Affinity這篇文章，就是按照這個意思來了。不然比較難理解。

一個服務對應一組服務例項。

對於每個服務，都會有很多例項以防止單個服務負載過高和容錯，以及與Hyperbahn relays建立好的連線集——the affine relays（它是relay ring的子集，負責傳送和響應指定service的請求資料）。這個最小可行的Hyperbahn全連線到service相關的the affinie relays上。然而隨著時間的推移，這些relays可能會超過最大檔案描述符的數量ulimit。下面的策略就是為了解決這個問題。

minPeersPerWorker值是每個服務worker連線數量的最小保證。也就是說一個服務worker至少有三個連線可以供Hyperbahn relay使用。還有一個minPeersPerRelay值，它是Hyperbahn relay至少連線到一個服務的worker數量。

*那麼由此可見一個relay ring至少與一個服務建立的連線數量為：`minPeersPerWorkerminPeersPerRelay`**

relayCount值是指Hyperbahn relay已經與服務workers建立好的連線數量。是這個服務的近似k值

對於每個服務通過gossiping advertisement傳送給relay ring中的每個worker成員。每個Hyperbahn relay知道所關聯服務worker的host:worker， workerCount是這個服務的worker數量，並且被每個相關的relay所知道。

這裡有幾個概念，我感覺有點混：relay ring, Hyperbahn relay，affine relay

這個relay ring可以通過排序所有的workers，並對每個worker給一個合適的位置workerIndex。

在relay ring中的每個位置有一個線性對映位置到每個worker ring。對映relayIndex到workerIndex的計算公式：

ratio = workerCount / relayCount

workerIndex = relayIndex *ratio

每個服務的worker數量應該為：

max(minPeersPerRelay, minPeersPerWorker * ratio)

minPeersPerRelay表示relay至少與服務workers建立的連線數，則至少有minPeersPerRelay個worker，否則這個條件無法滿足。

minPeersPerWorker * ratio = 
minPeersPerWorker * (workerCount/relayCount)  =
minPeersPerWorker * workerCount / relayCount =  

每個relay都應該在worker組內對映對應的位置，然後連線到服務worker上，以確保每個relay和服務worker之間的最小連線數。此範圍從worker ring的相應位置開始，但不包括range的末尾：

workerIndex = round(
    relayIndex * ratio +
    max(
        minPeersPerRelay,
        minPeersPerWorker * ratio,
    )
)

這種方法的一個期望特性是，這個affine relay集或者worker集的小變化應該在很大程度上，與先前的worker集重疊，保留了許多現有的連線。但是小的變化會影響每個relay的邊界，並可能導致整個系統的調整。

請參與affinity.py以獲取驗證一系列方案的對等選擇演算法的靜態屬性模擬