一、網(wǎng)關(guān)概述

網(wǎng)關(guān)的出現(xiàn)可以說是互聯(lián)網(wǎng)產(chǎn)品技術(shù)發(fā)展到一定階段自然演進(jìn)的產(chǎn)物，大體來說，網(wǎng)關(guān)從誕生到形成當(dāng)下大家熟悉的形態(tài)，大體經(jīng)過了下面的幾個發(fā)展階段。

1.1 硬負(fù)載網(wǎng)關(guān)

在早期 web 應(yīng)用中，大多數(shù)互聯(lián)網(wǎng)產(chǎn)品使用遠(yuǎn)未達(dá)到今天的規(guī)模，所以企業(yè)在應(yīng)用部署上對網(wǎng)關(guān)的職能并無太高要求?；旧蟻碇v，只要網(wǎng)關(guān)能滿足從域名解析到 IP 地址背后的服務(wù)代理即可，即所謂服務(wù)代理轉(zhuǎn)發(fā)。有必要的話，還需滿足服務(wù)的負(fù)載均衡。那個時代，諸如 nginx 這類軟負(fù)載均衡軟件的出現(xiàn)時機(jī)尚未成熟，所以很多企業(yè)選擇類似于 F5 這類硬件設(shè)備作為第一選擇，也就是基于 web 應(yīng)用下的硬負(fù)載網(wǎng)關(guān)。這時候網(wǎng)關(guān)職能簡單，從部署到使用的流程也簡單。

1.2 軟載網(wǎng)關(guān)

隨著互聯(lián)網(wǎng)產(chǎn)品的使用規(guī)模越來越大，技術(shù)、網(wǎng)絡(luò)、服務(wù)器等基礎(chǔ)設(shè)施的完備，傳統(tǒng)硬負(fù)載網(wǎng)關(guān)的使用成本，維護(hù)成本越來越高。加上這類硬件設(shè)施在面對層出不窮的新問題時，開始顯得力不從心，以 nginx 為代表的軟負(fù)載均衡軟件開始規(guī)模化應(yīng)用。軟負(fù)載網(wǎng)關(guān)的好處是明顯的，以使用成本低，部署簡單，靈活性強，可移植性好等眾多的優(yōu)勢逐漸替代傳統(tǒng)的 F5 這類硬負(fù)載網(wǎng)關(guān)。

同時，nginx 網(wǎng)關(guān)在面對更加復(fù)雜的互聯(lián)網(wǎng)場景時，也逐步開始支持集成更多外部的插件提供快速易用的解決方案，從而逐漸取代傳統(tǒng)的硬負(fù)載網(wǎng)關(guān)。更重要的是，nginx 代表的新型網(wǎng)關(guān)開始在微服務(wù)化的架構(gòu)體系下逐漸呈現(xiàn)出新的優(yōu)勢，比如可以對 API 資源可做定向的路由規(guī)則配置，輕量化的負(fù)載均衡等。

1.3 微服務(wù)網(wǎng)關(guān)

移動互聯(lián)網(wǎng)時代讓眾多的互聯(lián)網(wǎng)產(chǎn)品被推上流量的風(fēng)口，這種情況下，以微服務(wù)架構(gòu)為主流的形態(tài)流行起來。一個對外提供服務(wù)的應(yīng)用系統(tǒng)來說，背后是少則幾個，多則幾十個甚至上百個微服務(wù)的共同協(xié)作，其實就是不同微服務(wù)之間 API 資源的復(fù)雜的調(diào)用，通過 API 傳送不同業(yè)務(wù)數(shù)據(jù)促使一個業(yè)務(wù)流程的正常運轉(zhuǎn)。

面對越來越復(fù)雜的業(yè)務(wù)場景，微服務(wù)架構(gòu)面臨的一個新問題就是對 API 的治理，而 API 治理中的一個比較大的痛點就是如何對 API 納入統(tǒng)一的管控，這包括：服務(wù)發(fā)現(xiàn)，服務(wù)治理，認(rèn)證鑒權(quán)，灰度發(fā)布，流量監(jiān)控，限流降級等，說到底，API 作為互聯(lián)網(wǎng)企業(yè)最寶貴的服務(wù)資源，企業(yè)需要積累起統(tǒng)一管理這些分散的 API 資源能力從而讓 API 更好的輸出自身的價值，在這種情況下，微服務(wù)網(wǎng)關(guān)就應(yīng)運而生。

1.4 云原生網(wǎng)關(guān)

從 2016 年開始，容器化技術(shù)開始走進(jìn)互聯(lián)網(wǎng)技術(shù)圈，容器化這個名詞以 docker 為代表的出現(xiàn)開始在不少互聯(lián)網(wǎng)公司嘗試并加以運用。而經(jīng)歷了移動互聯(lián)網(wǎng)的高速發(fā)展，容器化技術(shù)的深度使用讓人們看到了它的優(yōu)勢，以及為企業(yè)的生產(chǎn)帶來的價值增長，于是以 k8s 為代表的新一代云原生技術(shù)架構(gòu)開始統(tǒng)治市場，成為一種既定的行業(yè)標(biāo)準(zhǔn)。

在這種情況下，微服務(wù)架構(gòu)模式下的應(yīng)用亟需開始布局產(chǎn)品從傳統(tǒng)的微服務(wù)部署模式到支持云原生部署模式的轉(zhuǎn)變。而微服務(wù)網(wǎng)關(guān)作為整個微服務(wù)架構(gòu)下非常重要的基石服務(wù)，可以說是打頭陣，慶幸的是，為了解決很多企業(yè)對于網(wǎng)關(guān)適配云原生下的部署架構(gòu)，開始陸續(xù)出現(xiàn)很多新型的支持云原生部署模式下的網(wǎng)關(guān)，以 k8s 中 ingressController 為代表的云原生網(wǎng)關(guān)，事實上逐漸成為一種標(biāo)準(zhǔn)和接入規(guī)范。云原生網(wǎng)關(guān)以面臨的場景更復(fù)雜，需求更加多樣，定制程度更高，且對流量的管控更苛刻為特點，逐漸為人們認(rèn)識，作為接下來微服務(wù)架構(gòu)的治理轉(zhuǎn)型和部署演進(jìn)趨勢，不少互聯(lián)網(wǎng)公司對此進(jìn)行提前的布局。

二、API 網(wǎng)關(guān)演進(jìn)歷史

通過上面的介紹，對網(wǎng)關(guān)的作用有了基本的認(rèn)識，在產(chǎn)品的部署架構(gòu)上，不管是哪種網(wǎng)關(guān)，說到底都是為了解決對底層 API 資源的訪問做到精細(xì)化，透明化，合理化的訪問控制，接下來聊聊作為應(yīng)用服務(wù)最重要的資源入口，API 網(wǎng)關(guān)的發(fā)展歷史。

2.1 API 網(wǎng)關(guān)來源

網(wǎng)關(guān)對于任何一個互聯(lián)網(wǎng)產(chǎn)品來說都必不可少，作為系統(tǒng)架構(gòu)最底層也是最寶貴的 API 資源，在面臨復(fù)雜的外部環(huán)境時，對 API 資源的保護(hù)也成了架構(gòu)規(guī)劃和治理中的重中之重，通常來說，對于一個生產(chǎn)系統(tǒng)的 API 來說，常用的保護(hù)措施如下：

• 反向代理，隱藏真實的 API 路徑；
• 對入口的熱點請求 API 統(tǒng)一限流；
• 防刷監(jiān)控告警；
• API 訪問授信，訪問鑒權(quán)；
• ...

經(jīng)歷過互聯(lián)網(wǎng)項目早期開發(fā)的同學(xué)，比較快捷且簡單的辦法是在項目中寫一段公共程序，在這段代碼中對過來的請求 URL 進(jìn)行鑒權(quán)，鑒權(quán)通過，才允許對 API 進(jìn)行訪問，對 API 的限流保護(hù)也是做類似的操作，但是這樣的做法問題也是明顯的，

• 鑒權(quán)或限流的業(yè)務(wù)與主線業(yè)務(wù)耦合嚴(yán)重，給后續(xù)的拆分埋下了技術(shù)難點；
• 難以對 API 資源的統(tǒng)一管控做精細(xì)化管理；
• 架構(gòu)擴(kuò)展困難，當(dāng)系統(tǒng)流量上去之后，鑒權(quán)或限流邏輯容易成為系統(tǒng)瓶頸；
• 支撐的后續(xù)業(yè)務(wù)場景容易受到制約；
• ...

舉個簡單的例子來說，假如說一開始能夠預(yù)知某個 API 后期被調(diào)用的頻率很高，提前對該 API 做限流，但是隨著業(yè)務(wù)的增長，更多的 API 需要限流，這就需要項目代碼中不斷做調(diào)整，設(shè)想如果有一個公共的可以實現(xiàn)流量管控的地方統(tǒng)一管理，這個問題豈不就迎刃而解了嗎？這就是所謂 API 集中治理的痛點?；谶@個痛點，API 網(wǎng)關(guān)就產(chǎn)生了。

2.2 nginx 統(tǒng)一 API 路由

nginx 的出現(xiàn)和大規(guī)模生產(chǎn)實踐可以說為 API 資源的統(tǒng)一治理奠定了重要的基礎(chǔ)。在大多數(shù)場景下，nginx 主要作為服務(wù)端 API 的反向代理服務(wù)器，統(tǒng)一管控服務(wù)端的路由地址列表，相當(dāng)于是 API 服務(wù)網(wǎng)關(guān)。

如下為一段使用 nginx 配置后端服務(wù)的反向代理路由配置，相信稍有經(jīng)驗的同學(xué)應(yīng)該不陌生，這樣做帶來的好處也是明顯的，不僅對外隱藏了真實的 API 地址，起到了一定的安全保護(hù)作用，同時也提供了一個統(tǒng)一的對外流量訪問入口，從這個角度來看，nginx 在這里，承載了一個作為 API 網(wǎng)關(guān)的角色。

server {
    listen       9001;
    server_name  www.abc.com;
 
    location /user {
        proxy_pass http://platform_user/user/;
    }

         location /manage {
        proxy_pass http://platform_manage/manage/;
    }
  }

2.3 微服務(wù)可編程式網(wǎng)關(guān)

盡管 nginx 功能很強，可以發(fā)揮系統(tǒng)對外的網(wǎng)關(guān)作用，但是不難發(fā)現(xiàn)，在微服務(wù)架構(gòu)體系下，nginx 能夠發(fā)揮的作用依然是有限的，具體來說，當(dāng)出現(xiàn)如下場景時，使用 nginx 網(wǎng)關(guān)就很難處理：

• 對請求來源的身份進(jìn)行識別，即請求的認(rèn)證鑒權(quán)；
• 對平臺內(nèi)部應(yīng)用的請求頻率做定向定量的分析；
• 對不同來源的請求進(jìn)行日志審計，并接入告警監(jiān)控；
• ...

類似的場景還有很多，此時像傳統(tǒng)網(wǎng)關(guān) F5 或 nginx，在應(yīng)對這類場景問題的解決上就顯得力不從心了。究其原因，微服務(wù)架構(gòu)下看似眾多的服務(wù)模塊屬于一種松散的“耦合”聚在在一起，服務(wù)之間大多數(shù)情況下是處于一種相對“無狀態(tài)”的模式下，這種情況下，要解決上面這些場景的痛點，無疑需要在整個微服務(wù)架構(gòu)之前，架設(shè)一道應(yīng)用級的 API 網(wǎng)關(guān)，即所謂的可編程式的 API 網(wǎng)關(guān)，比如在微服務(wù)技術(shù)解決方案中，出現(xiàn)了很多可編程式的網(wǎng)關(guān)，像 springcloud 中 zuul，gateway 等優(yōu)秀的可編程式網(wǎng)關(guān)，可編程網(wǎng)關(guān)的優(yōu)勢更加突出，主要具備如下特點：

2.3.1 路由配置規(guī)則更豐富

相比 nginx，可編程式網(wǎng)關(guān)在路由規(guī)則的配置上靈活性更高，動態(tài)性更好，支持的場景也更豐富，學(xué)習(xí)成本更低等特性。

2.3.2 支持編程式擴(kuò)展

可編程式網(wǎng)關(guān)相比傳統(tǒng) nginx 等網(wǎng)關(guān)最靈活的一點，莫過于可根據(jù)業(yè)務(wù)的需求通過編程的方式實現(xiàn)功能的快速擴(kuò)展。比如說，現(xiàn)在需要對某一類的請求進(jìn)行風(fēng)險識別，如果是 nginx，盡管現(xiàn)在可以通過集成其他插件進(jìn)行編碼，但這個成本是相當(dāng)巨大，而且給后續(xù)的運維帶來了高昂的代價，而這個需求在編程式網(wǎng)關(guān)中可以說是非常簡單了，支持主流的編程語言，只需簡單的幾行代碼，不管是開發(fā)，運維，測試等人員，都可以快速的做到。

2.3.3 支持高度定制化

一種技術(shù)在選型階段時，一個重要的考量指標(biāo)就是這種技術(shù)是否能滿足很多復(fù)雜的定制化場景，以限流來說，nginx 能夠提供的限流解決方案是很有限的，譬如對來源 IP，網(wǎng)段，黑白名單中特定 IP 源，或請求參數(shù)等場景，但涉及到更高級的限流，比如對熱點請求限流、特定應(yīng)用限流，甚至具體到 API 級別的限流場景時，nginx 這類網(wǎng)關(guān)就顯得力不從心了，而這些帶有定制化場景下的限流解決方案，是需要通過定制化的編程才可能完成。

2.3.4 支持API的動態(tài)治理

服務(wù)治理說到底具體表現(xiàn)就是對服務(wù)的 API 治理，利用可編程式網(wǎng)關(guān)的能力，架設(shè) API 網(wǎng)關(guān)服務(wù)，在網(wǎng)關(guān)服務(wù)中，可以對 API 資源做更加豐富的場景化，模塊化，定制化，生態(tài)化的治理，比如在分布式 API 鏈路追蹤與監(jiān)控還不夠成熟的情況下，通過接入 API 網(wǎng)關(guān)，在 API 網(wǎng)關(guān)中通過編碼的方式監(jiān)控所有的入口請求，就可以做到對 API 調(diào)用的實時監(jiān)控，甚至對惡意請求進(jìn)行風(fēng)控、告警，為后續(xù) API 級別的熱點請求做限流提供數(shù)據(jù)的可觀測性支持。

三、云原生網(wǎng)關(guān)

從云基礎(chǔ)設(shè)施的逐漸完善，到云原生技術(shù)的規(guī)模化實踐，越來越多的廠商開始擁抱云技術(shù)帶來的變更。以 k8s 生態(tài)為代表的云原生技術(shù)被越來越多的人接受，并在自身的產(chǎn)品中進(jìn)行嘗鮮探索。這其中，作為流量的入口，云原生網(wǎng)關(guān)的出現(xiàn)逐漸彌補并充實了云原生技術(shù)生態(tài)在統(tǒng)一流量治理方面的難題。如下為近些年比較流行的云原生網(wǎng)關(guān) apisix 的典型應(yīng)用場景圖。從圖中可以看到，云原生網(wǎng)關(guān)深耕于當(dāng)下流行的 k8s 云原生技術(shù)，利用自身的產(chǎn)品化優(yōu)勢為微服務(wù)進(jìn)行 k8s 的生產(chǎn)實踐擴(kuò)展新的配置使用入口，這也是典型的云原生網(wǎng)關(guān)的特點。

而隨著云原生技術(shù)的不斷演進(jìn)和需求的增長，現(xiàn)在陸續(xù)出現(xiàn)了很多不同的網(wǎng)關(guān)產(chǎn)品，有基于 NGINX 的，有基于 Envoy 的，還有很多新的基于 Golang 的網(wǎng)關(guān)產(chǎn)品，云原生的發(fā)展給網(wǎng)關(guān)提出了新的要求，具體來說，作為云原生網(wǎng)關(guān)，至少需要具備下面的特點：

3.1 能夠?qū)崿F(xiàn)配置規(guī)則的熱加載

使用過 nginx 的同學(xué)應(yīng)該不陌生，如果需要給 nginx 配置新的路由訪問規(guī)則，配置完成后，需要重啟 nginx，規(guī)則才能生效，這在大規(guī)模生產(chǎn)環(huán)境下可以說是一個長久以來一直沒有很好解決的難題，隨著微服務(wù)應(yīng)用的增多，服務(wù)的配置變更可能非常頻繁，每秒甚至都有幾十甚至上百個配置規(guī)則需要配置，在這種情況下，重啟 NGINX 將不可避免的帶來服務(wù)的短暫性不可用的尷尬情形。所以，云原生網(wǎng)關(guān)需要解決的首要問題就是如何實現(xiàn)配置規(guī)則的熱加載生效。

3.2 能夠?qū)崿F(xiàn)集群化管理

我們知道，nginx 集群的搭建需要借助其他的中間組件，而且在實際運維過程中，nginx 集群并不是很友好，其實是具備相當(dāng)?shù)娜肆Τ杀镜模绕涫窃趯?nginx 集群的管理中，一個讓人頭疼的地方就是同樣的配置規(guī)則需要在多處進(jìn)行修改。假如說，能夠方便地修改一個地方，然后所有的控制流量 API 網(wǎng)關(guān)都能夠生效的話，這就大大解放了人力，所以云原生網(wǎng)關(guān)需要具備這樣的能力，方便開發(fā)和運維人員能夠方便的通過網(wǎng)關(guān)實現(xiàn)集群化管理。

3.3 能夠支持二次定制化場景開發(fā)

作為 API 流量的入口，控制著所有入口的流量，不管是傳統(tǒng)的 API 網(wǎng)關(guān)，還是云原生網(wǎng)關(guān)，都應(yīng)該具備流量治理能力，流量治理說到底就是網(wǎng)關(guān)需要能夠結(jié)合實際業(yè)務(wù)的需要，比如針對不同的語言，不同的協(xié)議，能夠快速的進(jìn)行簡單的二次開發(fā)，以滿足眾多的個性化場景，像 Apisix，Kong，Higress 等云原生網(wǎng)關(guān)產(chǎn)品，都已經(jīng)初步具備二次開發(fā)能力。

3.4 具備優(yōu)良的性能

盡管 nginx 在云原生網(wǎng)關(guān)的場景下看起來有些不合時宜了，但是 nginx 作為一款經(jīng)久不衰的反向代理和負(fù)載均衡服務(wù)，性能方面可以說是很高的，而云原生網(wǎng)關(guān)的出現(xiàn)，盡管彌補了 nginx 在其他方面的不足，但歸結(jié)到現(xiàn)實的產(chǎn)品落地使用時，性能是否足夠優(yōu)秀仍然是考驗網(wǎng)關(guān)的第一標(biāo)準(zhǔn)，如果犧牲了網(wǎng)關(guān)的性能，最終也很難經(jīng)受住市場的考驗。

3.5 支持插件化擴(kuò)展

不管是從開發(fā)還是運維的視角，一款優(yōu)秀的軟件之所以能夠保持長久的生命力，一個不可忽視的因素就是該軟件的生態(tài)圈是否足夠大。以編輯器 vsocde 來說，從早期的文本編輯功能，到如今集成并支持成百上千個內(nèi)置可擴(kuò)展的插件單元，讓 vscode 在行業(yè)內(nèi)始終保持很高的競爭力，類似的 Jenkins 也不例外。

隨著微服務(wù)技術(shù)生態(tài)的擴(kuò)展，各種與微服務(wù)相關(guān)的中間件層出不窮，以服務(wù)注冊中心來說，大家熟悉的 zookeeper，eureka，consul，nacos 等，眾多的中間件讓微服務(wù)技術(shù)架構(gòu)在選型時有了更寬的視角，說到網(wǎng)關(guān)，試想如果一款云原生網(wǎng)關(guān)無法兼容對市場主流的 API 鑒權(quán)組件，API 限流組件，服務(wù)注冊組件等，那么在未來注定被拋棄，而插件化的模式也逐漸被很多云原生網(wǎng)關(guān)產(chǎn)品所吸收并使用，利用插件化的技術(shù)，開發(fā)運維人員可以很方便的根據(jù)場景的需要，快速接入新的外部組件到網(wǎng)關(guān)中，適配個性化的場景。

四、微服務(wù)網(wǎng)關(guān)發(fā)展趨勢

4.1 趨勢一：支撐豐富的插件化生態(tài)

插件化趨勢已經(jīng)在不少應(yīng)用軟件領(lǐng)域取得了卓有成效的效果，插件化模式的好處是顯而易見的，為了讓更多的技術(shù)開發(fā)者，開源生態(tài)技術(shù)快速融入你的應(yīng)用，插件化是一個快速、高效的體驗?zāi)Ｊ剑热绠?dāng)你需要在 jenkins 上快速體驗?zāi)硞€新功能時，無需多想，去應(yīng)用市場中搜一把再說，幾個點擊的動作就可以完成技術(shù)的嘗鮮。

對于網(wǎng)關(guān)來說，技術(shù)選型階段，拋開那些必備的功能性技術(shù)點，是否具備快速接入接入市場主流的技術(shù)棧，滿足用戶復(fù)雜多樣的使用場景，也是一個極其重要的考慮因素。以云原生網(wǎng)關(guān) apisix 來說，經(jīng)歷了市場多年的沉淀，從部署上，支撐裸機(jī)部署，容器化部署，k8s 部署，從使用上，支撐 api 規(guī)則配置，可視化界面配置，在與微服務(wù)架構(gòu)的對接使用中，apisix 與 springcloud-alibaba 等眾多開源的組件進(jìn)行無縫融合，這樣一來，使用 apisix 對微服務(wù)在進(jìn)行云原生的部署中也可以很好的實現(xiàn)無障礙跨域，這對技術(shù)架構(gòu)選型無疑是一大亮點。

4.2 趨勢二：統(tǒng)一 API 標(biāo)準(zhǔn)，向云原生微服務(wù)架構(gòu)演進(jìn)

隨著云原生技術(shù)的迅猛發(fā)展，云原生網(wǎng)關(guān)大有統(tǒng)一并取代微服務(wù)網(wǎng)關(guān)的趨勢，眾多的互聯(lián)網(wǎng)廠商也是看到了這一點，開始布局云原生網(wǎng)關(guān)，以期在云原生技術(shù)的實施落地中搶占制高點。

前面提到，作為微服務(wù)架構(gòu)中最底層也是最核心的 API 資源，可以說是整個云原生架構(gòu)的基石，不管未來云原生的商業(yè)化運用以何種技術(shù)呈現(xiàn)，API 的標(biāo)準(zhǔn)實現(xiàn)規(guī)范仍舊是最根本的?；谝惶?API 可以有不同的實現(xiàn)，既讓用戶不被具體實現(xiàn)鎖定，又可以橋接技術(shù)演進(jìn)的鴻溝。或許有一天 K8s 會消失，docker也不復(fù)存在，但面向抽象的 API 標(biāo)準(zhǔn)定會長存。

在流量網(wǎng)關(guān)領(lǐng)域，盡管發(fā)展到今天，Ingress API 已經(jīng)成為標(biāo)準(zhǔn)，但是對于微服務(wù)網(wǎng)關(guān)等更復(fù)雜的使用場景，Ingress 受限于其簡單的協(xié)議字段，需要通過 Ingress 注解等方式進(jìn)行能力擴(kuò)展，現(xiàn)階段來說還很難被標(biāo)準(zhǔn)化。因此諸如 Contour、Emissary、Kong、APISIX 等都開始定義自己的 HTTP 路由等 CRD，這就是說，從當(dāng)前的現(xiàn)狀來看，微服務(wù)網(wǎng)關(guān)的 API 定義開始呈現(xiàn)碎片化的模式。

這一背景之下，Gateway API 標(biāo)準(zhǔn)應(yīng)運而生，并且在過去的一年里已經(jīng)從 alpha 演進(jìn)到了 beta 階段。雖然目前 Gateway API 還未最終定稿，涉及到的標(biāo)準(zhǔn)協(xié)議仍會發(fā)生變動，不建議用于生產(chǎn)，但 API 統(tǒng)一趨勢已經(jīng)不可阻擋，不過是時間問題了。

下圖是使用Gateway API 的一個用例場景，不同于 Ingress API，將集群運維和業(yè)務(wù)運維的職責(zé)進(jìn)行了劃分，這樣業(yè)務(wù)開發(fā)人員不再需要關(guān)心網(wǎng)站證書等集群級的細(xì)節(jié)，只需專注業(yè)務(wù)本身的 DevOps，集群運維任務(wù)可以交給 SRE 人員進(jìn)行統(tǒng)一處理。

而采用三合一的架構(gòu)后（下圖所示），可以顯著降低成本，同時提高系統(tǒng)整體可用性，水平動態(tài)擴(kuò)展性。這也符合 DevSecOps 的微服務(wù)演進(jìn)趨勢，微服務(wù)開發(fā)者可以更多地從業(yè)務(wù)接口視角關(guān)注安全性，而不是在每一層做過于繁瑣的安全防護(hù)措施以增加系統(tǒng)的復(fù)雜性。

五、寫在文末

網(wǎng)關(guān)作為應(yīng)用系統(tǒng)的流量防衛(wèi)兵，可以說在保障整個系統(tǒng)的穩(wěn)定運轉(zhuǎn)過程中發(fā)揮著不可或缺的作用。不管未來的技術(shù)形態(tài)如何演進(jìn)，不管是否能出現(xiàn)云原生架構(gòu)全面取代傳統(tǒng)的部署模式，可以確定的是，微服務(wù)網(wǎng)關(guān)的持續(xù)性規(guī)劃和建設(shè)對于一個互聯(lián)網(wǎng)公司來說，都是一項值得長期投入的工作，可以預(yù)見的是，在不久的未來，網(wǎng)關(guān)將以特殊的角色扮演，在企業(yè)系統(tǒng)對外提供產(chǎn)品服務(wù)價值的基礎(chǔ)上發(fā)揮不可估量的作用。