5種主流API網(wǎng)關(guān)技術(shù)選型

前 言

微服務(wù)近幾年非?；?，圍繞微服務(wù)的技術(shù)生態(tài)也比較多，比如微服務(wù)網(wǎng)關(guān)、Docker、Kubernetes等。

我是于2019年開(kāi)始接觸微服務(wù)網(wǎng)關(guān)，當(dāng)時(shí)和公司的一位同事一起開(kāi)發(fā)，由于技術(shù)能力有限，我只負(fù)責(zé)網(wǎng)關(guān)后臺(tái)，后續(xù)微服務(wù)網(wǎng)關(guān)的迭代，我其實(shí)沒(méi)有參與，不過(guò)后來(lái)抽空看了微服務(wù)網(wǎng)關(guān)前臺(tái)的代碼，所以對(duì)這套微服務(wù)網(wǎng)關(guān)的實(shí)現(xiàn)原理算是基本掌握。

最近在寫(xiě)技術(shù)棧相關(guān)的文章，剛好寫(xiě)到微服務(wù)網(wǎng)關(guān)，就把之前學(xué)習(xí)的知識(shí)進(jìn)行簡(jiǎn)單總結(jié)，同時(shí)也把市面上常用的微服務(wù)網(wǎng)關(guān)進(jìn)行梳理，一方面便于后續(xù)技術(shù)選型，另一方面也算是給自己一個(gè)交代。下面是文章目錄：

API網(wǎng)關(guān)基礎(chǔ)

什么是API網(wǎng)關(guān)

API網(wǎng)關(guān)是一個(gè)服務(wù)器，是系統(tǒng)的唯一入口。 從面向?qū)ο笤O(shè)計(jì)的角度看，它與外觀模式類似。

API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶端提供一個(gè)定制的API。它可能還具有其它職責(zé)，如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存、協(xié)議轉(zhuǎn)換、限流熔斷、靜態(tài)響應(yīng)處理。

API網(wǎng)關(guān)方式的核心要點(diǎn)是，所有的客戶端和消費(fèi)端都通過(guò)統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)， 在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問(wèn)API。

網(wǎng)關(guān)的主要功能

微服務(wù)網(wǎng)關(guān)作為微服務(wù)后端服務(wù)的統(tǒng)一入口，它可以統(tǒng)籌管理后端服務(wù)，主要分為數(shù)據(jù)平面和控制平面：

數(shù)據(jù)平面主要功能是接入用戶的HTTP請(qǐng)求和微服務(wù)被拆分后的聚合。使用微服務(wù)網(wǎng)關(guān)統(tǒng)一對(duì)外暴露后端服務(wù)的API和契約，路由和過(guò)濾功能正是網(wǎng)關(guān)的核心能力模塊。另外，微服務(wù)網(wǎng)關(guān)可以實(shí)現(xiàn)攔截機(jī)制和專注跨橫切面的功能，包括協(xié)議轉(zhuǎn)換、安全認(rèn)證、熔斷限流、灰度發(fā)布、日志管理、流量監(jiān)控等。

控制平面主要功能是對(duì)后端服務(wù)做統(tǒng)一的管控和配置管理。例如，可以控制網(wǎng)關(guān)的彈性伸縮；可以統(tǒng)一下發(fā)配置；可以對(duì)網(wǎng)關(guān)服務(wù)添加標(biāo)簽；可以在微服務(wù)網(wǎng)關(guān)上通過(guò)配置Swagger功能統(tǒng)一將后端服務(wù)的API契約暴露給使用方，完成文檔服務(wù)，提高工作效率和降低溝通成本。

路由功能： 路由是微服務(wù)網(wǎng)關(guān)的核心能力。通過(guò)路由功能微服務(wù)網(wǎng)關(guān)可以將請(qǐng)求轉(zhuǎn)發(fā)到目標(biāo)微服務(wù)。在微服務(wù)架構(gòu)中，網(wǎng)關(guān)可以結(jié)合注冊(cè)中心的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)，實(shí)現(xiàn)對(duì)后端服務(wù)的發(fā)現(xiàn)，調(diào)用方只需要知道網(wǎng)關(guān)對(duì)外暴露的服務(wù)API就可以透明地訪問(wèn)后端微服務(wù)。

負(fù)載均衡： API網(wǎng)關(guān)結(jié)合負(fù)載均衡技術(shù)，利用Eureka或者Consul等服務(wù)發(fā)現(xiàn)工具，通過(guò)輪詢、指定權(quán)重、IP地址哈希等機(jī)制實(shí)現(xiàn)下游服務(wù)的負(fù)載均衡。

統(tǒng)一鑒權(quán)： 一般而言，無(wú)論對(duì)內(nèi)網(wǎng)還是外網(wǎng)的接口都需要做用戶身份認(rèn)證，而用戶認(rèn)證在一些規(guī)模較大的系統(tǒng)中都會(huì)采用統(tǒng)一的單點(diǎn)登錄（Single Sign On）系統(tǒng)，如果每個(gè)微服務(wù)都要對(duì)接單點(diǎn)登錄系統(tǒng)，那么顯然比較浪費(fèi)資源且開(kāi)發(fā)效率低。API網(wǎng)關(guān)是統(tǒng)一管理安全性的絕佳場(chǎng)所，可以將認(rèn)證的部分抽取到網(wǎng)關(guān)層，微服務(wù)系統(tǒng)無(wú)須關(guān)注認(rèn)證的邏輯，只關(guān)注自身業(yè)務(wù)即可。

協(xié)議轉(zhuǎn)換： API網(wǎng)關(guān)的一大作用在于構(gòu)建異構(gòu)系統(tǒng)，API網(wǎng)關(guān)作為單一入口，通過(guò)協(xié)議轉(zhuǎn)換整合后臺(tái)基于REST、AMQP、Dubbo等不同風(fēng)格和實(shí)現(xiàn)技術(shù)的微服務(wù)，面向Web Mobile、開(kāi)放平臺(tái)等特定客戶端提供統(tǒng)一服務(wù)。

指標(biāo)監(jiān)控： 網(wǎng)關(guān)可以統(tǒng)計(jì)后端服務(wù)的請(qǐng)求次數(shù)，并且可以實(shí)時(shí)地更新當(dāng)前的流量健康狀態(tài)，可以對(duì)URL粒度的服務(wù)進(jìn)行延遲統(tǒng)計(jì)，也可以使用Hystrix Dashboard查看后端服務(wù)的流量狀態(tài)及是否有熔斷發(fā)生。

限流熔斷 ： 在某些場(chǎng)景下需要控制客戶端的訪問(wèn)次數(shù)和訪問(wèn)頻率，一些高并發(fā)系統(tǒng)有時(shí)還會(huì)有限流的需求。在網(wǎng)關(guān)上可以配置一個(gè)閾值，當(dāng)請(qǐng)求數(shù)超過(guò)閾值時(shí)就直接返回錯(cuò)誤而不繼續(xù)訪問(wèn)后臺(tái)服務(wù)。當(dāng)出現(xiàn)流量洪峰或者后端服務(wù)出現(xiàn)延遲或故障時(shí)，網(wǎng)關(guān)能夠主動(dòng)進(jìn)行熔斷，保護(hù)后端服務(wù)，并保持前端用戶體驗(yàn)良好。

黑白名單： 微服務(wù)網(wǎng)關(guān)可以使用系統(tǒng)黑名單，過(guò)濾HTTP請(qǐng)求特征，攔截異常客戶端的請(qǐng)求，例如DDoS攻擊等侵蝕帶寬或資源迫使服務(wù)中斷等行為，可以在網(wǎng)關(guān)層面進(jìn)行攔截過(guò)濾。比較常見(jiàn)的攔截策略是根據(jù)IP地址增加黑名單。在存在鑒權(quán)管理的路由服務(wù)中可以通過(guò)設(shè)置白名單跳過(guò)鑒權(quán)管理而直接訪問(wèn)后端服務(wù)資源。

灰度發(fā)布： 微服務(wù)網(wǎng)關(guān)可以根據(jù)HTTP請(qǐng)求中的特殊標(biāo)記和后端服務(wù)列表元數(shù)據(jù)標(biāo)識(shí)進(jìn)行流量控制，實(shí)現(xiàn)在用戶無(wú)感知的情況下完成灰度發(fā)布。

流量染色： 和灰度發(fā)布的原理相似，網(wǎng)關(guān)可以根據(jù)HTTP請(qǐng)求的Host、Head、Agent等標(biāo)識(shí)對(duì)請(qǐng)求進(jìn)行染色，有了網(wǎng)關(guān)的流量染色功能，我們可以對(duì)服務(wù)后續(xù)的調(diào)用鏈路進(jìn)行跟蹤，對(duì)服務(wù)延遲及服務(wù)運(yùn)行狀況進(jìn)行進(jìn)一步的鏈路分析。

文檔中心： 網(wǎng)關(guān)結(jié)合Swagger，可以將后端的微服務(wù)暴露給網(wǎng)關(guān)，網(wǎng)關(guān)作為統(tǒng)一的入口給接口的使用方提供查看后端服務(wù)的API規(guī)范，不需要知道每一個(gè)后端微服務(wù)的Swagger地址，這樣網(wǎng)關(guān)起到了對(duì)后端API聚合的效果。

日志審計(jì)： 微服務(wù)網(wǎng)關(guān)可以作為統(tǒng)一的日志記錄和收集器，對(duì)服務(wù)URL粒度的日志請(qǐng)求信息和響應(yīng)信息進(jìn)行攔截。

API網(wǎng)關(guān)選型

常用API網(wǎng)關(guān)

先簡(jiǎn)單看一下市面上常用的API網(wǎng)關(guān)：

Nginx

Nginx是一個(gè)高性能的HTTP和反向代理服務(wù)器。Nginx一方面可以做反向代理，另外一方面可以做靜態(tài)資源服務(wù)器，接口使用Lua動(dòng)態(tài)語(yǔ)言可以完成靈活的定制功能 。

Nginx 在啟動(dòng)后，會(huì)有一個(gè) Master 進(jìn)程和多個(gè) Worker 進(jìn)程，Master 進(jìn)程和 Worker 進(jìn)程之間是通過(guò)進(jìn)程間通信進(jìn)行交互的，如圖所示。Worker 工作進(jìn)程的阻塞點(diǎn)是在像 select()、epoll_wait() 等這樣的 I/O 多路復(fù)用函數(shù)調(diào)用處，以等待發(fā)生數(shù)據(jù)可讀 / 寫(xiě)事件。Nginx 采用了異步非阻塞的方式來(lái)處理請(qǐng)求，也就是說(shuō)，Nginx 是可以同時(shí)處理成千上萬(wàn)個(gè)請(qǐng)求的。

Zuul

Zuul 是 Netflix 開(kāi)源的一個(gè)API網(wǎng)關(guān)組件，它可以和 Eureka、Ribbon、Hystrix 等組件配合使用。社區(qū)活躍，融合于 SpringCloud 完整生態(tài)，是構(gòu)建微服務(wù)體系前置網(wǎng)關(guān)服務(wù)的最佳選型之一。

Zuul 的核心是一系列的過(guò)濾器，這些過(guò)濾器可以完成以下功能：

統(tǒng)一鑒權(quán) + 動(dòng)態(tài)路由 + 負(fù)載均衡 + 壓力測(cè)試

審查與監(jiān)控： 與邊緣位置追蹤有意義的數(shù)據(jù)和統(tǒng)計(jì)結(jié)果，從而帶來(lái)精確的生產(chǎn)視圖。

多區(qū)域彈性： 跨越 AWS Region 進(jìn)行請(qǐng)求路由，旨在實(shí)現(xiàn) ELB（Elastic Load Balancing，彈性負(fù)載均衡）使用的多樣化，以及讓系統(tǒng)的邊緣更貼近系統(tǒng)的使用者。

Zuul 目前有兩個(gè)大的版本：Zuul1 和 Zuul2

Zuul1 是基于 Servlet 框架構(gòu)建，如圖所示，采用的是阻塞和多線程方式，即一個(gè)線程處理一次連接請(qǐng)求，這種方式在內(nèi)部延遲嚴(yán)重、設(shè)備故障較多情況下會(huì)引起存活的連接增多和線程增加的情況發(fā)生。

Netflix 發(fā)布的 Zuul2 有重大的更新，它運(yùn)行在異步和無(wú)阻塞框架上，每個(gè) CPU 核一個(gè)線程，處理所有的請(qǐng)求和響應(yīng)，請(qǐng)求和響應(yīng)的生命周期是通過(guò)事件和回調(diào)來(lái)處理的，這種方式減少了線程數(shù)量，因此開(kāi)銷較小。

Spring Cloud GetWay

Spring Cloud Gateway 是Spring Cloud的一個(gè)全新的API網(wǎng)關(guān)項(xiàng)目，目的是為了替換掉Zuul1，它基于Spring5.0 + SpringBoot2.0 + WebFlux（基于?性能的Reactor模式響應(yīng)式通信框架Netty，異步?阻塞模型）等技術(shù)開(kāi)發(fā)，性能?于Zuul，官?測(cè)試，Spring Cloud GateWay是Zuul的1.6倍 ，旨在為微服務(wù)架構(gòu)提供?種簡(jiǎn)單有效的統(tǒng)?的API路由管理?式。

Spring Cloud Gateway可以與Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等組件配合使用，實(shí)現(xiàn)路由轉(zhuǎn)發(fā)、負(fù)載均衡、熔斷、鑒權(quán)、路徑重寫(xiě)、?志監(jiān)控等，并且Gateway還內(nèi)置了限流過(guò)濾器，實(shí)現(xiàn)了限流的功能 。

Kong

Kong是一款基于OpenResty（Nginx + Lua模塊）編寫(xiě)的高可用、易擴(kuò)展的，由Mashape公司開(kāi)源的API Gateway項(xiàng)目。Kong是基于NGINX和Apache Cassandra或PostgreSQL構(gòu)建的 ，能提供易于使用的RESTful API來(lái)操作和配置API管理系統(tǒng)，所以它可以水平擴(kuò)展多個(gè)Kong服務(wù)器，通過(guò)前置的負(fù)載均衡配置把請(qǐng)求均勻地分發(fā)到各個(gè)Server，來(lái)應(yīng)對(duì)大批量的網(wǎng)絡(luò)請(qǐng)求。

Kong主要有三個(gè)組件：

Kong Server ： 基于Nginx的服務(wù)器，用來(lái)接收API請(qǐng)求。

Apache Cassandra/PostgreSQL ： 用來(lái)存儲(chǔ)操作數(shù)據(jù)。

Kong dashboard： 官方推薦UI管理工具，也可以使用 restfull 方式管理admin api。

Kong采用插件機(jī)制進(jìn)行功能定制，插件集（可以是0或N個(gè)）在API請(qǐng)求響應(yīng)循環(huán)的生命周期中被執(zhí)行。插件使用Lua編寫(xiě)，目前已有幾個(gè)基礎(chǔ)功能：HTTP基本認(rèn)證、密鑰認(rèn)證、CORS（Cross-Origin Resource Sharing，跨域資源共享）、TCP、UDP、文件日志、API請(qǐng)求限流、請(qǐng)求轉(zhuǎn)發(fā)以及Nginx監(jiān)控。

Kong網(wǎng)關(guān)具有以下的特性：

可擴(kuò)展性: 通過(guò)簡(jiǎn)單地添加更多的服務(wù)器，可以輕松地進(jìn)行橫向擴(kuò)展，這意味著您的平臺(tái)可以在一個(gè)較低負(fù)載的情況下處理任何請(qǐng)求；

模塊化: 可以通過(guò)添加新的插件進(jìn)行擴(kuò)展，這些插件可以通過(guò)RESTful Admin API輕松配置；

在任何基礎(chǔ)架構(gòu)上運(yùn)行: Kong網(wǎng)關(guān)可以在任何地方都能運(yùn)行。您可以在云或內(nèi)部網(wǎng)絡(luò)環(huán)境中部署Kong，包括單個(gè)或多個(gè)數(shù)據(jù)中心設(shè)置，以及public，private 或invite-only APIs。

Traefik

Tr?f?k 是一個(gè)為了讓部署微服務(wù)更加便捷而誕生的現(xiàn)代HTTP反向代理、負(fù)載均衡工具。它支持多種后臺(tái) (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 來(lái)自動(dòng)化、動(dòng)態(tài)的應(yīng)用它的配置文件設(shè)置。

重要特性：

它非常快，無(wú)需安裝其他依賴，通過(guò)Go語(yǔ)言編寫(xiě)的單一可執(zhí)行文件；

多種后臺(tái)支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd；

支持支持Rest API、Websocket、HTTP/2、Docker鏡像；

監(jiān)聽(tīng)后臺(tái)變化進(jìn)而自動(dòng)化應(yīng)用新的配置文件設(shè)置；

配置文件熱更新，無(wú)需重啟進(jìn)程；

后端斷路器、負(fù)載均衡、容錯(cuò)機(jī)制；

清爽的前端頁(yè)面，可監(jiān)控服務(wù)指標(biāo)。

API網(wǎng)關(guān)對(duì)比

上面是網(wǎng)關(guān)對(duì)比截圖，偷個(gè)懶，大家主要關(guān)注Kong、Traefik和Zuul即可：

從開(kāi)源社區(qū)活躍度 來(lái)看，無(wú)疑是Kong和Traefik較好；

從成熟度 來(lái)看，較好的是Kong、Tyk、Traefik；

從性能 來(lái)看，Kong要比其他幾個(gè)領(lǐng)先一些；

從架構(gòu)優(yōu)勢(shì) 的擴(kuò)展性來(lái)看，Kong、Tyk有豐富的插件，Ambassador也有插件但不多，而Zuul是完全需要自研，但Zuul由于與Spring Cloud深度集成，使用度也很高，近年來(lái)Istio服務(wù)網(wǎng)格的流行，Ambassador因?yàn)槟軌蚝虸stio無(wú)縫集成也是相當(dāng)大的優(yōu)勢(shì)。

下面是其它網(wǎng)友的思考結(jié)論，可供參考：

性能： Nginx+Lua形式必然是高于Java語(yǔ)言實(shí)現(xiàn)的網(wǎng)關(guān)的，Java技術(shù)棧里面Zuul1.0是基于Servlet實(shí)現(xiàn)的，剩下都是基于webflux實(shí)現(xiàn)，性能是高于基于Servlet實(shí)現(xiàn)的。在性能方面我覺(jué)得選擇網(wǎng)關(guān)可能不算那么重要，多加幾臺(tái)機(jī)器就可以搞定。

可維護(hù)性和擴(kuò)展性： Nginx+Lua這個(gè)組合掌握的人不算多，如果團(tuán)隊(duì)有大神，大佬們就隨意了，當(dāng)沒(méi)看到這段話，對(duì)于一般團(tuán)隊(duì)來(lái)說(shuō)的話，選擇自己團(tuán)隊(duì)擅長(zhǎng)的語(yǔ)言更重要。Java技術(shù)棧下的3種網(wǎng)關(guān)，對(duì)于Zuul和Spring Cloud Getway需要或多或少要搞一些集成和配置頁(yè)面來(lái)維護(hù)，但是對(duì)于Soul我就無(wú)腦看看文章，需要哪個(gè)搬哪個(gè)好了，尤其是可以無(wú)腦對(duì)接Dubbo美滋滋，此外Soul2.0以后版本可以擺脫ZK，在我心里再無(wú)詬病，我就喜歡無(wú)腦操作。

高可用： 對(duì)于網(wǎng)關(guān)高可用基本都是統(tǒng)一的策略都是采用多機(jī)器部署的方式，前面掛一個(gè)負(fù)載，對(duì)于而外需要用的一些組件大家注意一下。

基于Traefik自研的微服務(wù)網(wǎng)關(guān)

技術(shù)棧選型

Traefik： 一款開(kāi)源的反向代理與負(fù)載均衡工具，它最大的優(yōu)點(diǎn)是能夠與常見(jiàn)的微服務(wù)系統(tǒng)直接整合，可以實(shí)現(xiàn)自動(dòng)化動(dòng)態(tài)配置。traefik較為輕量，非常易于使用和設(shè)置，性能比較好，已在全球范圍內(nèi)用于生產(chǎn)環(huán)境。

Etcd： 一個(gè)Go言編寫(xiě)的分布式、高可用的一致性鍵值存儲(chǔ)系統(tǒng)，用于提供可靠的分布式鍵值存儲(chǔ)、配置共享和服務(wù)發(fā)現(xiàn)等功能。

Go： 并發(fā)能力強(qiáng)，性能媲美C，處理能力是PHP的4倍，效率高，語(yǔ)法簡(jiǎn)單，易上手，開(kāi)發(fā)效率接近PHP。

網(wǎng)關(guān)框架

整個(gè)網(wǎng)關(guān)框架分為3塊：

網(wǎng)關(guān)后臺(tái)（hal-fe和hal-admin）： 用于應(yīng)用、服務(wù)和插件的配置，然后將配置信息發(fā)布到ETCD；

Traefik： 讀取ETCD配置，根據(jù)配置信息對(duì)請(qǐng)求進(jìn)行路由分發(fā)，如果需要鑒權(quán)，會(huì)直接通過(guò)hal-agent模塊進(jìn)行統(tǒng)一鑒權(quán)。鑒權(quán)完畢后，如果是Http請(qǐng)求，直接打到下游服務(wù)，如果是Grpc和Thrift協(xié)議，會(huì)通過(guò)hal-proxy模塊進(jìn)行協(xié)議轉(zhuǎn)換。

協(xié)議轉(zhuǎn)換模塊： 讀取ETCD配置，對(duì)Traefik分發(fā)過(guò)來(lái)的請(qǐng)求，進(jìn)行Grpc和Thrift協(xié)議轉(zhuǎn)換，并通過(guò)服務(wù)發(fā)現(xiàn)機(jī)制，獲取服務(wù)下游機(jī)器，并通過(guò)負(fù)載均衡，將轉(zhuǎn)換后的數(shù)據(jù)打到下游服務(wù)機(jī)器。

網(wǎng)關(guān)后臺(tái)

主要由3大模塊組成：

應(yīng)用： 主要包括應(yīng)用名、域名、路徑前綴、所屬組、狀態(tài)等，比如印度海外商城、印度社區(qū)；

服務(wù)： 主要包括服務(wù)名、注冊(cè)方式、協(xié)議類型、所屬組、狀態(tài)等，比如評(píng)論服務(wù)、地址服務(wù)、搜索服務(wù)。

插件： 主要包括插件名稱、插件類型、插件屬性配置等，比如路徑前綴替換插件、鑒權(quán)插件。

一個(gè)應(yīng)用只能綁定一個(gè)服務(wù)，但是可以綁定多個(gè)插件。 通過(guò)后臺(tái)完成網(wǎng)關(guān)配置后，將這些配置信息生成Config文件，發(fā)布到ETCD中，Config文件需要遵循嚴(yán)格的數(shù)據(jù)格式，比如Traefix配置需要遵循官方的文件配置格式，才能被Traefik識(shí)別。

協(xié)議轉(zhuǎn)換模塊

hal-proxy模塊是整個(gè)微服務(wù)網(wǎng)關(guān)最復(fù)雜，也是技術(shù)含量最高的模塊，所以給大家詳細(xì)講解一下。

問(wèn)題引入

在講這個(gè)模塊前，我們先看下面幾個(gè)問(wèn)題：

當(dāng)請(qǐng)求從上游的trafik過(guò)來(lái)時(shí)，需要知道訪問(wèn)下游的機(jī)器IP和端口，才能將請(qǐng)求發(fā)送給下游，這些機(jī)器如何獲取呢？

有了機(jī)器后，我們需要和下游機(jī)器建立連接，如果連接用一次就直接釋放，肯定對(duì)服務(wù)會(huì)造成很大的壓力，這就需要引入Client緩存池，那這個(gè)Client緩存池我們又該如何實(shí)現(xiàn)呢？

最后就是需要對(duì)協(xié)議進(jìn)行轉(zhuǎn)換，因?yàn)椴煌南掠畏?wù)，支持的協(xié)議類型是不一樣的，這個(gè)網(wǎng)關(guān)又是如何動(dòng)態(tài)支持的呢？

實(shí)現(xiàn)原理

我們還是先看一下hal-proxy內(nèi)部有哪些模塊，首先是Resolver模塊，這個(gè)模塊的是什么作用呢？這里我簡(jiǎn)單介紹一下，目前公司內(nèi)部通過(guò)服務(wù)獲取到機(jī)器列表的方式有多種，比如MIS平臺(tái)、服務(wù)樹(shù)等，也就是有的是通過(guò)平臺(tái)配置的，有的是直接掛在服務(wù)樹(shù)下，無(wú)論哪種方式，我們都通過(guò)服務(wù)名，通過(guò)一定的方式，找到該服務(wù)下面所有的主機(jī)。

所以Resolver模塊的作用，其實(shí)就是通過(guò)服務(wù)名，找到該服務(wù)下的所有機(jī)器的IP和服務(wù)端口，然后持久化到內(nèi)存中，并定時(shí)更新。

協(xié)議模塊就是支持不同的協(xié)議轉(zhuǎn)換，每個(gè)協(xié)議類型的轉(zhuǎn)換，都需要單獨(dú)實(shí)現(xiàn)，這些協(xié)議轉(zhuǎn)換，無(wú)非就是先通過(guò)機(jī)器IP和端口初始化Client，然后再將數(shù)據(jù)進(jìn)行轉(zhuǎn)換后，直接發(fā)送到下游的機(jī)器。

最后就是連接池，之前我們其實(shí)也用到go自帶的pool來(lái)做，但是當(dāng)對(duì)pool數(shù)據(jù)進(jìn)行更新時(shí)，需要加鎖，所以性能一直起不來(lái)，后來(lái)改成了環(huán)形隊(duì)列，然后對(duì)數(shù)據(jù)的操作全部通過(guò)原子操作方式，就實(shí)現(xiàn)了無(wú)鎖操作，大大提高的并發(fā)性能 。

實(shí)現(xiàn)邏輯

這個(gè)是hal-proxy的邏輯實(shí)現(xiàn)圖，畫(huà)了2天，包含所有核心對(duì)象的交互方式，這里就不去細(xì)講，能掌握多少，靠大家自己領(lǐng)悟，如果有任何疑問(wèn)(或者看不清圖片)，可以關(guān)注我公眾號(hào)，加我微信溝通。

審核編輯：劉清