BFE路由轉發模型如下圖所示。

以http請求為例，當請求到達BFE時，BFE首先根據請求域名確定租戶(哪個業務線)，再根據請求的路徑確定集群(服務/微服務)，然后確定子集群(機房)，最后負載均衡選擇實例(服務進程)。

那么我們為什么要重寫這套路由轉發機制?

BFE在路由到集群以及負載均衡選擇實例上，與我們接觸的網關很類似，在做網關時，我們最頭疼的就是配置一堆路由規則。在七層流量代理上，由于多租戶的存在，我們也需要配置一堆規則。

為了解決繁瑣的配置問題，以及兼容歷史遺留問題，我們重寫了BFE的路由轉發機制，讓服務主動的，按“/租戶/服務/機房/實例/接口”的格式注冊到注冊中心，BFE從注冊中心讀取和監聽服務注冊。要實現這一點，需要業務方使用我們提供的框架開發。

當然，這很大程度是由于歷史遺留問題決定的。在使用BFE之前，我們公司使用的是自研的七層流量代理，使用自定義的客戶端與服務端的通信協議。因此，客戶端和服務端都需要依賴七層流量代理提供的SDK開發。

使用BFE后，除兼容舊的邏輯，為實現客戶端與后端的rpc調用，提升開發效率，支持多語言(客戶端ios與Android、h5使用的開發語言不同)生態，我們提供基于idl通用語言的rpc實現方案。

實現基于注冊機制的轉發邏輯，有利于實現跨區域流量調度。我們不需要知道哪個業務在哪個大區部署有服務，通過跨區域數據同步即可自動發現就近區域部署的服務，將請求通過專線轉發到其它區域的BFE。也稱南北路由。

在調整路由轉發機制后，由于去掉了轉發規則的配置，原有限流模塊已經不適用，或者說太重，配置起來太繁瑣，因此，我們也重寫了限流模塊，只保留按租戶限流和按接口限流，并增加按連接數限流和按握手次數限流。

重寫BFE的路由轉發機制并非原有實現不好，而是為了兼容原有技術棧，解決繁瑣配置問題，實現跨區域流量轉發。很多時候，歷史包袱并不是說丟棄就丟棄，每個迭代都要考慮兼容問題。

基于百度開源的BFE二次開發，目前為止，我們幾乎重寫了BFE，只保留BFE的骨干框架。由于要兼容一堆邏輯，BFE也變得越來越重，而這些兼容邏輯，也會是一個長期存在的邏輯。

本文轉載自微信公眾號「Java藝術」，可以通過以下二維碼關注。轉載本文請聯系Java藝術公眾號。