個推微服務閘道器架構實踐

個推2018發表於2019-03-05

作者：個推應用平臺基礎架構高階研發工程師阿飛

在微服務架構中，不同的微服務可以有不同的網路地址，各個微服務之間通過互相呼叫完成使用者請求，客戶端可能通過呼叫N個微服務的介面完成一個使用者請求。因此，在客戶端和服務端之間增加一個API閘道器成為多數微服務架構的必然選擇。

在個推的微服務實踐中，API閘道器也起著至關重要的作用。一方面，API閘道器是個推微服務體系對外的唯一入口；另一方面，API閘道器中實現了很多後端服務的共性需求，避免了重複建設。

個推微服務閘道器的設計與實現

個推微服務主要是基於Docker和Kubernetes進行實踐的。在整個微服務架構中，最底層的是個推私有部署的Kubernetes叢集，在叢集之上，部署了應用服務。

個推的應用服務體系共分為三層，最上一層是閘道器層，接著是業務層，最下面是基礎層服務。在部署應用服務時，我們使用了Kubernetes的名稱空間對不同產品線的產品進行隔離。除了應用服務外， Kubernetes叢集上還部署了Consul來實現配置的管理、Kube-DNS實現服務註冊與發現，以及一些輔助系統來進行應用和叢集的管理。

下圖是個推微服務體系的架構圖。

個推對API閘道器的功能需求主要有以下幾方面：

1. 要支援配置多個產品，為不同的產品提供不同的埠；

2. 動態路由；

3. URI的重寫；

4. 服務的註冊與發現；

5. 負載均衡；

6. 安全相關的需求，如session校驗等；

7. 流量控制；

8. 鏈路追蹤；

9. A/B Testing。

在對市面上已有的閘道器產品進行調研後，我們的技術團隊發現，它們並不太適合應用於個推的微服務體系。第一，個推配置的管理都是基於Consul實現的，而大部分閘道器產品都需要基於一些DB儲存，來進行配置的管理；第二，大部分的閘道器產品提供的功能比較通用，也比較完善，這同時也降低了配置的複雜度以及靈活性；第三，大部分的閘道器產品很難直接融入到個推的微服務架構體系中。

最終，個推選擇使用了OperResty和Lua進行自研閘道器，在自研的過程中，我們也借鑑了其他閘道器產品的一些設計，如Kong和Orange的外掛機制等。

個推的API閘道器的外掛設計如下圖所示。

OpenResty對請求的處理分為多個階段。個推API閘道器的外掛主要是在Set、Rewrite、Access、Header_filter、Body_filter、Log這六個階段做相應的處理，其中，每一個外掛都可以在一個或多個階段起到相應的作用。在一個請求到達API閘道器之後，閘道器會根據配置為該請求選擇外掛，然後根據每個外掛的規則，進一步過濾出匹配規則的外掛，最後對外掛進行例項化，對流量進行相應的處理。

我們可以通過舉例來理解這個過程，如上圖所示，localhost:8080/api/demo/test/hello這個請求到達閘道器後，閘道器會根據host和埠確定產品資訊，並提取出URI(/api/demo/test/hello)，然後根據產品的具體配置，篩選出需要使用的外掛——Rewrite_URI、Dyups和Auth，接下來根據每個外掛的規則配置進行過濾，過濾後，只有Rewrite_URI和Dyups兩個外掛被選中。之後例項化這兩個外掛，在各個階段對請求進行處理。請求被轉發到後端服務時，URI就被rewrite為“/demo/test/hello”，upstream也被設定為“prod1-svc1”。請求由後端服務處理之後，響應會經閘道器返回給客戶端，這就是整個外掛的設計和工作的流程。為了優化效能，我們將外掛的例項化延緩到了請求真正開始處理時，在此之前，閘道器會通過產品配置和規則，過濾掉不需要執行的外掛。從圖中也可以看出，每個外掛的規則配置都很簡單，並且沒有統一的格式，這也確保了外掛配置的簡單靈活。

閘道器的配置均為熱更新，通過Consul和Consul-Template來實現，配置在Consul上進行更新後，Consul-Template會將其實時地拉取下來，然後通過以下兩種方式進行更新。

（1）通過呼叫Update API，將配置更新到shared-dict中。

（2）更新配置檔案，利用Reload OpenResty實現配置檔案的更新。

個推微服務閘道器提供的主要功能

1.動態路由

動態路由主要涉及到三個方面：服務註冊、服務發現和請求轉發。

如下圖所示，服務的註冊和發現是基於Kubernetes的Service和Kube-DNS實現的，在Consul中，會維持一個服務的對映表，應用的每一個微服務都對應Kubernetes上的一個Service，每建立一個Service都會在Consul上的服務對映表中新增一項（會被實時更新到閘道器的共享記憶體中）。閘道器每收到一個請求都會從服務對映表中查詢到具體的後端服務（即Kubernetes中的Service名），並進行動態路由。Kube-DNS可以將Service的域名解析成Kubernetes內部的ClusterIP，而Service代理了多個Pod，會將流量均衡地轉發到不同的Pod上。

2.流量控制

流量控制主要是通過一個名為“Counter”的後端服務和閘道器中的流控外掛實現的。Counter負責儲存請求的訪問次數和限值，並且支援按時間維度進行計數。流控外掛負責攔截流量，呼叫Counter的介面進行超限查詢，如果Counter返回請求超限，閘道器就會直接拒絕訪問，實現限次的功能，再結合時間維度就可以實現限頻的需求。同時流控外掛通過輸出日誌資訊到fluent-bit，由fluent-bit聚合計次來更新Counter中的計數。