BFE路由轉(zhuǎn)發(fā)模型如下圖所示。

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

那么我們?yōu)槭裁匆貙戇@套路由轉(zhuǎn)發(fā)機制?

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

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

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

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

實現(xiàn)基于注冊機制的轉(zhuǎn)發(fā)邏輯，有利于實現(xiàn)跨區(qū)域流量調(diào)度。我們不需要知道哪個業(yè)務(wù)在哪個大區(qū)部署有服務(wù)，通過跨區(qū)域數(shù)據(jù)同步即可自動發(fā)現(xiàn)就近區(qū)域部署的服務(wù)，將請求通過專線轉(zhuǎn)發(fā)到其它區(qū)域的BFE。也稱南北路由。

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

重寫B(tài)FE的路由轉(zhuǎn)發(fā)機制并非原有實現(xiàn)不好，而是為了兼容原有技術(shù)棧，解決繁瑣配置問題，實現(xiàn)跨區(qū)域流量轉(zhuǎn)發(fā)。很多時候，歷史包袱并不是說丟棄就丟棄，每個迭代都要考慮兼容問題。

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

本文轉(zhuǎn)載自微信公眾號「Java藝術(shù)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Java藝術(shù)公眾號。