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

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

那么我們?yōu)槭裁匆貙?xiě)這套路由轉(zhuǎn)發(fā)機(jī)制?

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

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

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

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

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

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

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

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

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