作者：個(gè)推應(yīng)用平臺基礎(chǔ)架構(gòu)高級研發(fā)工程師 阿飛

站在用戶的角度思考問題，與客戶深入溝通，找到新興網(wǎng)站設(shè)計(jì)與新興網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：做網(wǎng)站、網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋新興地區(qū)。

在微服務(wù)架構(gòu)中，不同的微服務(wù)可以有不同的網(wǎng)絡(luò)地址，各個(gè)微服務(wù)之間通過互相調(diào)用完成用戶請求，客戶端可能通過調(diào)用N個(gè)微服務(wù)的接口完成一個(gè)用戶請求。因此，在客戶端和服務(wù)端之間增加一個(gè)API網(wǎng)關(guān)成為多數(shù)微服務(wù)架構(gòu)的必然選擇。

在個(gè)推的微服務(wù)實(shí)踐中，API網(wǎng)關(guān)也起著至關(guān)重要的作用。一方面，API網(wǎng)關(guān)是個(gè)推微服務(wù)體系對外的唯一入口；另一方面，API網(wǎng)關(guān)中實(shí)現(xiàn)了很多后端服務(wù)的共性需求，避免了重復(fù)建設(shè)。

個(gè)推微服務(wù)網(wǎng)關(guān)的設(shè)計(jì)與實(shí)現(xiàn)

個(gè)推微服務(wù)主要是基于Docker和Kubernetes進(jìn)行實(shí)踐的。在整個(gè)微服務(wù)架構(gòu)中，最底層的是個(gè)推私有部署的Kubernetes集群，在集群之上，部署了應(yīng)用服務(wù)。

個(gè)推的應(yīng)用服務(wù)體系共分為三層，最上一層是網(wǎng)關(guān)層，接著是業(yè)務(wù)層，最下面是基礎(chǔ)層服務(wù)。在部署應(yīng)用服務(wù)時(shí)，我們使用了Kubernetes的命名空間對不同產(chǎn)品線的產(chǎn)品進(jìn)行隔離。除了應(yīng)用服務(wù)外， Kubernetes集群上還部署了Consul來實(shí)現(xiàn)配置的管理、Kube-DNS實(shí)現(xiàn)服務(wù)注冊與發(fā)現(xiàn)，以及一些輔助系統(tǒng)來進(jìn)行應(yīng)用和集群的管理。

下圖是個(gè)推微服務(wù)體系的架構(gòu)圖。

個(gè)推對API網(wǎng)關(guān)的功能需求主要有以下幾方面：

1. 要支持配置多個(gè)產(chǎn)品，為不同的產(chǎn)品提供不同的端口；

2. 動(dòng)態(tài)路由；

3. URI的重寫；

4. 服務(wù)的注冊與發(fā)現(xiàn)；

5. 負(fù)載均衡；

6. 安全相關(guān)的需求，如session校驗(yàn)等；

7. 流量控制；

8. 鏈路追蹤；

9. A/B Testing。

在對市面上已有的網(wǎng)關(guān)產(chǎn)品進(jìn)行調(diào)研后，我們的技術(shù)團(tuán)隊(duì)發(fā)現(xiàn)，它們并不太適合應(yīng)用于個(gè)推的微服務(wù)體系。第一，個(gè)推配置的管理都是基于Consul實(shí)現(xiàn)的，而大部分網(wǎng)關(guān)產(chǎn)品都需要基于一些DB存儲，來進(jìn)行配置的管理；第二，大部分的網(wǎng)關(guān)產(chǎn)品提供的功能比較通用，也比較完善，這同時(shí)也降低了配置的復(fù)雜度以及靈活性；第三，大部分的網(wǎng)關(guān)產(chǎn)品很難直接融入到個(gè)推的微服務(wù)架構(gòu)體系中。

最終，個(gè)推選擇使用了OperResty和Lua進(jìn)行自研網(wǎng)關(guān)，在自研的過程中，我們也借鑒了其他網(wǎng)關(guān)產(chǎn)品的一些設(shè)計(jì)，如Kong和Orange的插件機(jī)制等。

個(gè)推的API網(wǎng)關(guān)的插件設(shè)計(jì)如下圖所示。

OpenResty對請求的處理分為多個(gè)階段。個(gè)推API網(wǎng)關(guān)的插件主要是在Set、Rewrite、Access、Header_filter、Body_filter、Log這六個(gè)階段做相應(yīng)的處理，其中，每一個(gè)插件都可以在一個(gè)或多個(gè)階段起到相應(yīng)的作用。在一個(gè)請求到達(dá)API網(wǎng)關(guān)之后，網(wǎng)關(guān)會根據(jù)配置為該請求選擇插件，然后根據(jù)每個(gè)插件的規(guī)則，進(jìn)一步過濾出匹配規(guī)則的插件，最后對插件進(jìn)行實(shí)例化，對流量進(jìn)行相應(yīng)的處理。

我們可以通過舉例來理解這個(gè)過程，如上圖所示，localhost:8080/api/demo/test/hello這個(gè)請求到達(dá)網(wǎng)關(guān)后，網(wǎng)關(guān)會根據(jù)host和端口確定產(chǎn)品信息，并提取出URI(/api/demo/test/hello)，然后根據(jù)產(chǎn)品的具體配置，篩選出需要使用的插件——Rewrite_URI、Dyups和Auth，接下來根據(jù)每個(gè)插件的規(guī)則配置進(jìn)行過濾，過濾后，只有Rewrite_URI和Dyups兩個(gè)插件被選中。之后實(shí)例化這兩個(gè)插件，在各個(gè)階段對請求進(jìn)行處理。請求被轉(zhuǎn)發(fā)到后端服務(wù)時(shí)，URI就被rewrite為“/demo/test/hello”，upstream也被設(shè)置為“prod1-svc1”。請求由后端服務(wù)處理之后，響應(yīng)會經(jīng)網(wǎng)關(guān)返回給客戶端，這就是整個(gè)插件的設(shè)計(jì)和工作的流程。為了優(yōu)化性能，我們將插件的實(shí)例化延緩到了請求真正開始處理時(shí)，在此之前，網(wǎng)關(guān)會通過產(chǎn)品配置和規(guī)則，過濾掉不需要執(zhí)行的插件。從圖中也可以看出，每個(gè)插件的規(guī)則配置都很簡單，并且沒有統(tǒng)一的格式，這也確保了插件配置的簡單靈活。

網(wǎng)關(guān)的配置均為熱更新，通過Consul和Consul-Template來實(shí)現(xiàn)，配置在Consul上進(jìn)行更新后，Consul-Template會將其實(shí)時(shí)地拉取下來，然后通過以下兩種方式進(jìn)行更新。

（1）通過調(diào)用Update API，將配置更新到shared-dict中。

（2）更新配置文件，利用Reload OpenResty實(shí)現(xiàn)配置文件的更新。

個(gè)推微服務(wù)網(wǎng)關(guān)提供的主要功能

1.動(dòng)態(tài)路由

動(dòng)態(tài)路由主要涉及到三個(gè)方面：服務(wù)注冊、服務(wù)發(fā)現(xiàn)和請求轉(zhuǎn)發(fā)。

如下圖所示，服務(wù)的注冊和發(fā)現(xiàn)是基于Kubernetes的Service和Kube-DNS實(shí)現(xiàn)的，在Consul中，會維持一個(gè)服務(wù)的映射表，應(yīng)用的每一個(gè)微服務(wù)都對應(yīng)Kubernetes上的一個(gè)Service，每創(chuàng)建一個(gè)Service都會在Consul上的服務(wù)映射表中添加一項(xiàng)（會被實(shí)時(shí)更新到網(wǎng)關(guān)的共享內(nèi)存中）。網(wǎng)關(guān)每收到一個(gè)請求都會從服務(wù)映射表中查詢到具體的后端服務(wù)（即Kubernetes中的Service名），并進(jìn)行動(dòng)態(tài)路由。Kube-DNS可以將Service的域名解析成Kubernetes內(nèi)部的ClusterIP，而Service代理了多個(gè)Pod，會將流量均衡地轉(zhuǎn)發(fā)到不同的Pod上。

2.流量控制

流量控制主要是通過一個(gè)名為“Counter”的后端服務(wù)和網(wǎng)關(guān)中的流控插件實(shí)現(xiàn)的。Counter負(fù)責(zé)存儲請求的訪問次數(shù)和限值，并且支持按時(shí)間維度進(jìn)行計(jì)數(shù)。流控插件負(fù)責(zé)攔截流量，調(diào)用Counter的接口進(jìn)行超限查詢，如果Counter返回請求超限，網(wǎng)關(guān)就會直接拒絕訪問，實(shí)現(xiàn)限次的功能，再結(jié)合時(shí)間維度就可以實(shí)現(xiàn)限頻的需求。同時(shí)流控插件通過輸出日志信息到fluent-bit，由fluent-bit聚合計(jì)次來更新Counter中的計(jì)數(shù)。

3.鏈路追蹤

整個(gè)微服務(wù)體系的鏈路追蹤是基于分布式的鏈路追蹤系統(tǒng)Zipkin來實(shí)現(xiàn)的。通過在網(wǎng)關(guān)安裝Zipkin插件和在后端服務(wù)中引入Zipkin中間件，實(shí)現(xiàn)最終的鏈路追蹤功能。具體架構(gòu)如下圖所示。

4. A/B測試

在A/B測試的實(shí)現(xiàn)中，有以下幾個(gè)關(guān)鍵點(diǎn)：

（1）所有的策略信息都配置在Consul上，并通過Consul-Template實(shí)時(shí)生效到各個(gè)微服務(wù)的內(nèi)存中；

（2）每條策略均有指明，調(diào)用一個(gè)微服務(wù)時(shí)應(yīng)調(diào)用A還是B（默認(rèn)為A）；

（3）網(wǎng)關(guān)中實(shí)現(xiàn)A/B插件，在請求到達(dá)網(wǎng)關(guān)時(shí)，通過A/B插件配置的規(guī)則，即可確定請求適用的A/B策略；

（4）網(wǎng)關(guān)會將請求適用的A/B策略通過URL參數(shù)傳遞下去；

（5）每個(gè)微服務(wù)通過傳遞下來的策略，選擇正確的服務(wù)進(jìn)行訪問。

下圖給出了兩種場景下的調(diào)用鏈路。

總結(jié)

以上就是個(gè)推微服務(wù)網(wǎng)關(guān)的設(shè)計(jì)和主要功能的實(shí)現(xiàn)。之后，個(gè)推的技術(shù)團(tuán)隊(duì)會不斷提升API網(wǎng)關(guān)的彈性設(shè)計(jì)，使其能夠在故障出現(xiàn)時(shí)，縮小故障的影響范圍；同時(shí)，我們也會繼續(xù)將網(wǎng)關(guān)與DevOps平臺做進(jìn)一步地結(jié)合，以確保網(wǎng)關(guān)在迭代更新時(shí)，能夠有更多的自動(dòng)化測試來保證質(zhì)量，實(shí)現(xiàn)更快速地部署。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

標(biāo)題名稱：個(gè)推微服務(wù)網(wǎng)關(guān)架構(gòu)實(shí)踐-創(chuàng)新互聯(lián)
文章網(wǎng)址：http://jinyejixie.com/article8/gpgip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、企業(yè)建站、網(wǎng)站排名、標(biāo)簽優(yōu)化、ChatGPT、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)