對(duì)標(biāo)蘋果的靈動(dòng)島 華為帶來(lái)實(shí)況窗功能
繼蘋果的靈動(dòng)島之后，華為也在今天正式推出了“實(shí)況窗”功能。據(jù)今天鴻蒙OS 4.0的現(xiàn)場(chǎng)演示顯示，華為的實(shí)況窗可以更高效的展現(xiàn)出實(shí)時(shí)通知，比如鎖屏上就能看到外賣、打車、銀行
網(wǎng)關(guān)的出現(xiàn)可以說(shuō)是互聯(lián)網(wǎng)產(chǎn)品技術(shù)發(fā)展到一定階段自然演進(jìn)的產(chǎn)物，大體來(lái)說(shuō)，網(wǎng)關(guān)從誕生到形成當(dāng)下大家熟悉的形態(tài)，大體經(jīng)過(guò)了下面的幾個(gè)發(fā)展階段。
在早期 web 應(yīng)用中，大多數(shù)互聯(lián)網(wǎng)產(chǎn)品使用遠(yuǎn)未達(dá)到今天的規(guī)模，所以企業(yè)在應(yīng)用部署上對(duì)網(wǎng)關(guān)的職能并無(wú)太高要求。基本上來(lái)講，只要網(wǎng)關(guān)能滿足從域名解析到 IP 地址背后的服務(wù)代理即可，即所謂服務(wù)代理轉(zhuǎn)發(fā)。有必要的話，還需滿足服務(wù)的負(fù)載均衡。那個(gè)時(shí)代，諸如 nginx 這類軟負(fù)載均衡軟件的出現(xiàn)時(shí)機(jī)尚未成熟，所以很多企業(yè)選擇類似于 F5 這類硬件設(shè)備作為第一選擇，也就是基于 web 應(yīng)用下的硬負(fù)載網(wǎng)關(guān)。這時(shí)候網(wǎng)關(guān)職能簡(jiǎn)單，從部署到使用的流程也簡(jiǎn)單。
隨著互聯(lián)網(wǎng)產(chǎn)品的使用規(guī)模越來(lái)越大，技術(shù)、網(wǎng)絡(luò)、服務(wù)器等基礎(chǔ)設(shè)施的完備，傳統(tǒng)硬負(fù)載網(wǎng)關(guān)的使用成本，維護(hù)成本越來(lái)越高。加上這類硬件設(shè)施在面對(duì)層出不窮的新問(wèn)題時(shí)，開(kāi)始顯得力不從心，以 nginx 為代表的軟負(fù)載均衡軟件開(kāi)始規(guī)?；瘧?yīng)用。軟負(fù)載網(wǎng)關(guān)的好處是明顯的，以使用成本低，部署簡(jiǎn)單，靈活性強(qiáng)，可移植性好等眾多的優(yōu)勢(shì)逐漸替代傳統(tǒng)的 F5 這類硬負(fù)載網(wǎng)關(guān)。
同時(shí)，nginx 網(wǎng)關(guān)在面對(duì)更加復(fù)雜的互聯(lián)網(wǎng)場(chǎng)景時(shí)，也逐步開(kāi)始支持集成更多外部的插件提供快速易用的解決方案，從而逐漸取代傳統(tǒng)的硬負(fù)載網(wǎng)關(guān)。更重要的是，nginx 代表的新型網(wǎng)關(guān)開(kāi)始在微服務(wù)化的架構(gòu)體系下逐漸呈現(xiàn)出新的優(yōu)勢(shì)，比如可以對(duì) API 資源可做定向的路由規(guī)則配置，輕量化的負(fù)載均衡等。
從 2016 年開(kāi)始，容器化技術(shù)開(kāi)始走進(jìn)互聯(lián)網(wǎng)技術(shù)圈，容器化這個(gè)名詞以 docker 為代表的出現(xiàn)開(kāi)始在不少互聯(lián)網(wǎng)公司嘗試并加以運(yùn)用。而經(jīng)歷了移動(dòng)互聯(lián)網(wǎng)的高速發(fā)展，容器化技術(shù)的深度使用讓人們看到了它的優(yōu)勢(shì)，以及為企業(yè)的生產(chǎn)帶來(lái)的價(jià)值增長(zhǎng)，于是以 k8s 為代表的新一代云原生技術(shù)架構(gòu)開(kāi)始統(tǒng)治市場(chǎng)，成為一種既定的行業(yè)標(biāo)準(zhǔn)。
在這種情況下，微服務(wù)架構(gòu)模式下的應(yīng)用亟需開(kāi)始布局產(chǎn)品從傳統(tǒng)的微服務(wù)部署模式到支持云原生部署模式的轉(zhuǎn)變。而微服務(wù)網(wǎng)關(guān)作為整個(gè)微服務(wù)架構(gòu)下非常重要的基石服務(wù)，可以說(shuō)是打頭陣，慶幸的是，為了解決很多企業(yè)對(duì)于網(wǎng)關(guān)適配云原生下的部署架構(gòu)，開(kāi)始陸續(xù)出現(xiàn)很多新型的支持云原生部署模式下的網(wǎng)關(guān)，以 k8s 中 ingressController 為代表的云原生網(wǎng)關(guān)，事實(shí)上逐漸成為一種標(biāo)準(zhǔn)和接入規(guī)范。云原生網(wǎng)關(guān)以面臨的場(chǎng)景更復(fù)雜，需求更加多樣，定制程度更高，且對(duì)流量的管控更苛刻為特點(diǎn)，逐漸為人們認(rèn)識(shí)，作為接下來(lái)微服務(wù)架構(gòu)的治理轉(zhuǎn)型和部署演進(jìn)趨勢(shì)，不少互聯(lián)網(wǎng)公司對(duì)此進(jìn)行提前的布局。
通過(guò)上面的介紹，對(duì)網(wǎng)關(guān)的作用有了基本的認(rèn)識(shí)，在產(chǎn)品的部署架構(gòu)上，不管是哪種網(wǎng)關(guān)，說(shuō)到底都是為了解決對(duì)底層 API 資源的訪問(wèn)做到精細(xì)化，透明化，合理化的訪問(wèn)控制，接下來(lái)聊聊作為應(yīng)用服務(wù)最重要的資源入口，API 網(wǎng)關(guān)的發(fā)展歷史。
網(wǎng)關(guān)對(duì)于任何一個(gè)互聯(lián)網(wǎng)產(chǎn)品來(lái)說(shuō)都必不可少，作為系統(tǒng)架構(gòu)最底層也是最寶貴的 API 資源，在面臨復(fù)雜的外部環(huán)境時(shí)，對(duì) API 資源的保護(hù)也成了架構(gòu)規(guī)劃和治理中的重中之重，通常來(lái)說(shuō)，對(duì)于一個(gè)生產(chǎn)系統(tǒng)的 API 來(lái)說(shuō)，常用的保護(hù)措施如下：
經(jīng)歷過(guò)互聯(lián)網(wǎng)項(xiàng)目早期開(kāi)發(fā)的同學(xué)，比較快捷且簡(jiǎn)單的辦法是在項(xiàng)目中寫一段公共程序，在這段代碼中對(duì)過(guò)來(lái)的請(qǐng)求 URL 進(jìn)行鑒權(quán)，鑒權(quán)通過(guò)，才允許對(duì) API 進(jìn)行訪問(wèn)，對(duì) API 的限流保護(hù)也是做類似的操作，但是這樣的做法問(wèn)題也是明顯的，
舉個(gè)簡(jiǎn)單的例子來(lái)說(shuō)，假如說(shuō)一開(kāi)始能夠預(yù)知某個(gè) API 后期被調(diào)用的頻率很高，提前對(duì)該 API 做限流，但是隨著業(yè)務(wù)的增長(zhǎng)，更多的 API 需要限流，這就需要項(xiàng)目代碼中不斷做調(diào)整，設(shè)想如果有一個(gè)公共的可以實(shí)現(xiàn)流量管控的地方統(tǒng)一管理，這個(gè)問(wèn)題豈不就迎刃而解了嗎？這就是所謂 API 集中治理的痛點(diǎn)?；谶@個(gè)痛點(diǎn)，API 網(wǎng)關(guān)就產(chǎn)生了。
nginx 的出現(xiàn)和大規(guī)模生產(chǎn)實(shí)踐可以說(shuō)為 API 資源的統(tǒng)一治理奠定了重要的基礎(chǔ)。在大多數(shù)場(chǎng)景下，nginx 主要作為服務(wù)端 API 的反向代理服務(wù)器，統(tǒng)一管控服務(wù)端的路由地址列表，相當(dāng)于是 API 服務(wù)網(wǎng)關(guān)。
如下為一段使用 nginx 配置后端服務(wù)的反向代理路由配置，相信稍有經(jīng)驗(yàn)的同學(xué)應(yīng)該不陌生，這樣做帶來(lái)的好處也是明顯的，不僅對(duì)外隱藏了真實(shí)的 API 地址，起到了一定的安全保護(hù)作用，同時(shí)也提供了一個(gè)統(tǒng)一的對(duì)外流量訪問(wèn)入口，從這個(gè)角度來(lái)看，nginx 在這里，承載了一個(gè)作為 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/; } }盡管 nginx 功能很強(qiáng)，可以發(fā)揮系統(tǒng)對(duì)外的網(wǎng)關(guān)作用，但是不難發(fā)現(xiàn)，在微服務(wù)架構(gòu)體系下，nginx 能夠發(fā)揮的作用依然是有限的，具體來(lái)說(shuō)，當(dāng)出現(xiàn)如下場(chǎng)景時(shí)，使用 nginx 網(wǎng)關(guān)就很難處理：
類似的場(chǎng)景還有很多，此時(shí)像傳統(tǒng)網(wǎng)關(guān) F5 或 nginx，在應(yīng)對(duì)這類場(chǎng)景問(wèn)題的解決上就顯得力不從心了。究其原因，微服務(wù)架構(gòu)下看似眾多的服務(wù)模塊屬于一種松散的“耦合”聚在在一起，服務(wù)之間大多數(shù)情況下是處于一種相對(duì)“無(wú)狀態(tài)”的模式下，這種情況下，要解決上面這些場(chǎng)景的痛點(diǎn)，無(wú)疑需要在整個(gè)微服務(wù)架構(gòu)之前，架設(shè)一道應(yīng)用級(jí)的 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)勢(shì)更加突出，主要具備如下特點(diǎn)：
相比 nginx，可編程式網(wǎng)關(guān)在路由規(guī)則的配置上靈活性更高，動(dòng)態(tài)性更好，支持的場(chǎng)景也更豐富，學(xué)習(xí)成本更低等特性。
可編程式網(wǎng)關(guān)相比傳統(tǒng) nginx 等網(wǎng)關(guān)最靈活的一點(diǎn)，莫過(guò)于可根據(jù)業(yè)務(wù)的需求通過(guò)編程的方式實(shí)現(xiàn)功能的快速擴(kuò)展。比如說(shuō)，現(xiàn)在需要對(duì)某一類的請(qǐng)求進(jìn)行風(fēng)險(xiǎn)識(shí)別，如果是 nginx，盡管現(xiàn)在可以通過(guò)集成其他插件進(jìn)行編碼，但這個(gè)成本是相當(dāng)巨大，而且給后續(xù)的運(yùn)維帶來(lái)了高昂的代價(jià)，而這個(gè)需求在編程式網(wǎng)關(guān)中可以說(shuō)是非常簡(jiǎn)單了，支持主流的編程語(yǔ)言，只需簡(jiǎn)單的幾行代碼，不管是開(kāi)發(fā)，運(yùn)維，測(cè)試等人員，都可以快速的做到。
一種技術(shù)在選型階段時(shí)，一個(gè)重要的考量指標(biāo)就是這種技術(shù)是否能滿足很多復(fù)雜的定制化場(chǎng)景，以限流來(lái)說(shuō)，nginx 能夠提供的限流解決方案是很有限的，譬如對(duì)來(lái)源 IP，網(wǎng)段，黑白名單中特定 IP 源，或請(qǐng)求參數(shù)等場(chǎng)景，但涉及到更高級(jí)的限流，比如對(duì)熱點(diǎn)請(qǐng)求限流、特定應(yīng)用限流，甚至具體到 API 級(jí)別的限流場(chǎng)景時(shí)，nginx 這類網(wǎng)關(guān)就顯得力不從心了，而這些帶有定制化場(chǎng)景下的限流解決方案，是需要通過(guò)定制化的編程才可能完成。
服務(wù)治理說(shuō)到底具體表現(xiàn)就是對(duì)服務(wù)的 API 治理，利用可編程式網(wǎng)關(guān)的能力，架設(shè) API 網(wǎng)關(guān)服務(wù)，在網(wǎng)關(guān)服務(wù)中，可以對(duì) API 資源做更加豐富的場(chǎng)景化，模塊化，定制化，生態(tài)化的治理，比如在分布式 API 鏈路追蹤與監(jiān)控還不夠成熟的情況下，通過(guò)接入 API 網(wǎng)關(guān)，在 API 網(wǎng)關(guān)中通過(guò)編碼的方式監(jiān)控所有的入口請(qǐng)求，就可以做到對(duì) API 調(diào)用的實(shí)時(shí)監(jiān)控，甚至對(duì)惡意請(qǐng)求進(jìn)行風(fēng)控、告警，為后續(xù) API 級(jí)別的熱點(diǎn)請(qǐng)求做限流提供數(shù)據(jù)的可觀測(cè)性支持。
從云基礎(chǔ)設(shè)施的逐漸完善，到云原生技術(shù)的規(guī)模化實(shí)踐，越來(lái)越多的廠商開(kāi)始擁抱云技術(shù)帶來(lái)的變更。以 k8s 生態(tài)為代表的云原生技術(shù)被越來(lái)越多的人接受，并在自身的產(chǎn)品中進(jìn)行嘗鮮探索。這其中，作為流量的入口，云原生網(wǎng)關(guān)的出現(xiàn)逐漸彌補(bǔ)并充實(shí)了云原生技術(shù)生態(tài)在統(tǒng)一流量治理方面的難題。如下為近些年比較流行的云原生網(wǎng)關(guān) apisix 的典型應(yīng)用場(chǎng)景圖。從圖中可以看到，云原生網(wǎng)關(guān)深耕于當(dāng)下流行的 k8s 云原生技術(shù)，利用自身的產(chǎn)品化優(yōu)勢(shì)為微服務(wù)進(jìn)行 k8s 的生產(chǎn)實(shí)踐擴(kuò)展新的配置使用入口，這也是典型的云原生網(wǎng)關(guān)的特點(diǎn)。
而隨著云原生技術(shù)的不斷演進(jìn)和需求的增長(zhǎng)，現(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)提出了新的要求，具體來(lái)說(shuō)，作為云原生網(wǎng)關(guān)，至少需要具備下面的特點(diǎn)：
使用過(guò) nginx 的同學(xué)應(yīng)該不陌生，如果需要給 nginx 配置新的路由訪問(wèn)規(guī)則，配置完成后，需要重啟 nginx，規(guī)則才能生效，這在大規(guī)模生產(chǎn)環(huán)境下可以說(shuō)是一個(gè)長(zhǎng)久以來(lái)一直沒(méi)有很好解決的難題，隨著微服務(wù)應(yīng)用的增多，服務(wù)的配置變更可能非常頻繁，每秒甚至都有幾十甚至上百個(gè)配置規(guī)則需要配置，在這種情況下，重啟 NGINX 將不可避免的帶來(lái)服務(wù)的短暫性不可用的尷尬情形。所以，云原生網(wǎng)關(guān)需要解決的首要問(wèn)題就是如何實(shí)現(xiàn)配置規(guī)則的熱加載生效。
我們知道，nginx 集群的搭建需要借助其他的中間組件，而且在實(shí)際運(yùn)維過(guò)程中，nginx 集群并不是很友好，其實(shí)是具備相當(dāng)?shù)娜肆Τ杀镜模绕涫窃趯?duì) nginx 集群的管理中，一個(gè)讓人頭疼的地方就是同樣的配置規(guī)則需要在多處進(jìn)行修改。假如說(shuō)，能夠方便地修改一個(gè)地方，然后所有的控制流量 API 網(wǎng)關(guān)都能夠生效的話，這就大大解放了人力，所以云原生網(wǎng)關(guān)需要具備這樣的能力，方便開(kāi)發(fā)和運(yùn)維人員能夠方便的通過(guò)網(wǎng)關(guān)實(shí)現(xiàn)集群化管理。
作為 API 流量的入口，控制著所有入口的流量，不管是傳統(tǒng)的 API 網(wǎng)關(guān)，還是云原生網(wǎng)關(guān)，都應(yīng)該具備流量治理能力，流量治理說(shuō)到底就是網(wǎng)關(guān)需要能夠結(jié)合實(shí)際業(yè)務(wù)的需要，比如針對(duì)不同的語(yǔ)言，不同的協(xié)議，能夠快速的進(jìn)行簡(jiǎn)單的二次開(kāi)發(fā)，以滿足眾多的個(gè)性化場(chǎng)景，像 Apisix，Kong，Higress 等云原生網(wǎng)關(guān)產(chǎn)品，都已經(jīng)初步具備二次開(kāi)發(fā)能力。
盡管 nginx 在云原生網(wǎng)關(guān)的場(chǎng)景下看起來(lái)有些不合時(shí)宜了，但是 nginx 作為一款經(jīng)久不衰的反向代理和負(fù)載均衡服務(wù)，性能方面可以說(shuō)是很高的，而云原生網(wǎng)關(guān)的出現(xiàn)，盡管彌補(bǔ)了 nginx 在其他方面的不足，但歸結(jié)到現(xiàn)實(shí)的產(chǎn)品落地使用時(shí)，性能是否足夠優(yōu)秀仍然是考驗(yàn)網(wǎng)關(guān)的第一標(biāo)準(zhǔn)，如果犧牲了網(wǎng)關(guān)的性能，最終也很難經(jīng)受住市場(chǎng)的考驗(yàn)。
不管是從開(kāi)發(fā)還是運(yùn)維的視角，一款優(yōu)秀的軟件之所以能夠保持長(zhǎng)久的生命力，一個(gè)不可忽視的因素就是該軟件的生態(tài)圈是否足夠大。以編輯器 vsocde 來(lái)說(shuō)，從早期的文本編輯功能，到如今集成并支持成百上千個(gè)內(nèi)置可擴(kuò)展的插件單元，讓 vscode 在行業(yè)內(nèi)始終保持很高的競(jìng)爭(zhēng)力，類似的 Jenkins 也不例外。
隨著微服務(wù)技術(shù)生態(tài)的擴(kuò)展，各種與微服務(wù)相關(guān)的中間件層出不窮，以服務(wù)注冊(cè)中心來(lái)說(shuō)，大家熟悉的 zookeeper，eureka，consul，nacos 等，眾多的中間件讓微服務(wù)技術(shù)架構(gòu)在選型時(shí)有了更寬的視角，說(shuō)到網(wǎng)關(guān)，試想如果一款云原生網(wǎng)關(guān)無(wú)法兼容對(duì)市場(chǎng)主流的 API 鑒權(quán)組件，API 限流組件，服務(wù)注冊(cè)組件等，那么在未來(lái)注定被拋棄，而插件化的模式也逐漸被很多云原生網(wǎng)關(guān)產(chǎn)品所吸收并使用，利用插件化的技術(shù)，開(kāi)發(fā)運(yùn)維人員可以很方便的根據(jù)場(chǎng)景的需要，快速接入新的外部組件到網(wǎng)關(guān)中，適配個(gè)性化的場(chǎng)景。
插件化趨勢(shì)已經(jīng)在不少應(yīng)用軟件領(lǐng)域取得了卓有成效的效果，插件化模式的好處是顯而易見(jiàn)的，為了讓更多的技術(shù)開(kāi)發(fā)者，開(kāi)源生態(tài)技術(shù)快速融入你的應(yīng)用，插件化是一個(gè)快速、高效的體驗(yàn)?zāi)Ｊ?，比如?dāng)你需要在 jenkins 上快速體驗(yàn)?zāi)硞€(gè)新功能時(shí)，無(wú)需多想，去應(yīng)用市場(chǎng)中搜一把再說(shuō)，幾個(gè)點(diǎn)擊的動(dòng)作就可以完成技術(shù)的嘗鮮。
對(duì)于網(wǎng)關(guān)來(lái)說(shuō)，技術(shù)選型階段，拋開(kāi)那些必備的功能性技術(shù)點(diǎn)，是否具備快速接入接入市場(chǎng)主流的技術(shù)棧，滿足用戶復(fù)雜多樣的使用場(chǎng)景，也是一個(gè)極其重要的考慮因素。以云原生網(wǎng)關(guān) apisix 來(lái)說(shuō)，經(jīng)歷了市場(chǎng)多年的沉淀，從部署上，支撐裸機(jī)部署，容器化部署，k8s 部署，從使用上，支撐 api 規(guī)則配置，可視化界面配置，在與微服務(wù)架構(gòu)的對(duì)接使用中，apisix 與 springcloud-alibaba 等眾多開(kāi)源的組件進(jìn)行無(wú)縫融合，這樣一來(lái)，使用 apisix 對(duì)微服務(wù)在進(jìn)行云原生的部署中也可以很好的實(shí)現(xiàn)無(wú)障礙跨域，這對(duì)技術(shù)架構(gòu)選型無(wú)疑是一大亮點(diǎn)。
隨著云原生技術(shù)的迅猛發(fā)展，云原生網(wǎng)關(guān)大有統(tǒng)一并取代微服務(wù)網(wǎng)關(guān)的趨勢(shì)，眾多的互聯(lián)網(wǎng)廠商也是看到了這一點(diǎn)，開(kāi)始布局云原生網(wǎng)關(guān)，以期在云原生技術(shù)的實(shí)施落地中搶占制高點(diǎn)。
前面提到，作為微服務(wù)架構(gòu)中最底層也是最核心的 API 資源，可以說(shuō)是整個(gè)云原生架構(gòu)的基石，不管未來(lái)云原生的商業(yè)化運(yùn)用以何種技術(shù)呈現(xiàn)，API 的標(biāo)準(zhǔn)實(shí)現(xiàn)規(guī)范仍舊是最根本的?；谝惶?API 可以有不同的實(shí)現(xiàn)，既讓用戶不被具體實(shí)現(xiàn)鎖定，又可以橋接技術(shù)演進(jìn)的鴻溝。或許有一天 K8s 會(huì)消失，docker也不復(fù)存在，但面向抽象的 API 標(biāo)準(zhǔn)定會(huì)長(zhǎng)存。
在流量網(wǎng)關(guān)領(lǐng)域，盡管發(fā)展到今天，Ingress API 已經(jīng)成為標(biāo)準(zhǔn)，但是對(duì)于微服務(wù)網(wǎng)關(guān)等更復(fù)雜的使用場(chǎng)景，Ingress 受限于其簡(jiǎn)單的協(xié)議字段，需要通過(guò) Ingress 注解等方式進(jìn)行能力擴(kuò)展，現(xiàn)階段來(lái)說(shuō)還很難被標(biāo)準(zhǔn)化。因此諸如 Contour、Emissary、Kong、APISIX 等都開(kāi)始定義自己的 HTTP 路由等 CRD，這就是說(shuō)，從當(dāng)前的現(xiàn)狀來(lái)看，微服務(wù)網(wǎng)關(guān)的 API 定義開(kāi)始呈現(xiàn)碎片化的模式。
這一背景之下，Gateway API 標(biāo)準(zhǔn)應(yīng)運(yùn)而生，并且在過(guò)去的一年里已經(jīng)從 alpha 演進(jìn)到了 beta 階段。雖然目前 Gateway API 還未最終定稿，涉及到的標(biāo)準(zhǔn)協(xié)議仍會(huì)發(fā)生變動(dòng)，不建議用于生產(chǎn)，但 API 統(tǒng)一趨勢(shì)已經(jīng)不可阻擋，不過(guò)是時(shí)間問(wèn)題了。
下圖是使用Gateway API 的一個(gè)用例場(chǎng)景，不同于 Ingress API，將集群運(yùn)維和業(yè)務(wù)運(yùn)維的職責(zé)進(jìn)行了劃分，這樣業(yè)務(wù)開(kāi)發(fā)人員不再需要關(guān)心網(wǎng)站證書等集群級(jí)的細(xì)節(jié)，只需專注業(yè)務(wù)本身的 DevOps，集群運(yùn)維任務(wù)可以交給 SRE 人員進(jìn)行統(tǒng)一處理。
而采用三合一的架構(gòu)后（下圖所示），可以顯著降低成本，同時(shí)提高系統(tǒng)整體可用性，水平動(dòng)態(tài)擴(kuò)展性。這也符合 DevSecOps 的微服務(wù)演進(jìn)趨勢(shì)，微服務(wù)開(kāi)發(fā)者可以更多地從業(yè)務(wù)接口視角關(guān)注安全性，而不是在每一層做過(guò)于繁瑣的安全防護(hù)措施以增加系統(tǒng)的復(fù)雜性。
網(wǎng)關(guān)作為應(yīng)用系統(tǒng)的流量防衛(wèi)兵，可以說(shuō)在保障整個(gè)系統(tǒng)的穩(wěn)定運(yùn)轉(zhuǎn)過(guò)程中發(fā)揮著不可或缺的作用。不管未來(lái)的技術(shù)形態(tài)如何演進(jìn)，不管是否能出現(xiàn)云原生架構(gòu)全面取代傳統(tǒng)的部署模式，可以確定的是，微服務(wù)網(wǎng)關(guān)的持續(xù)性規(guī)劃和建設(shè)對(duì)于一個(gè)互聯(lián)網(wǎng)公司來(lái)說(shuō)，都是一項(xiàng)值得長(zhǎng)期投入的工作，可以預(yù)見(jiàn)的是，在不久的未來(lái)，網(wǎng)關(guān)將以特殊的角色扮演，在企業(yè)系統(tǒng)對(duì)外提供產(chǎn)品服務(wù)價(jià)值的基礎(chǔ)上發(fā)揮不可估量的作用。
本文鏈接：http://www.www897cc.com/showinfo-26-10494-0.html深入探究微服務(wù)架構(gòu)下 API 網(wǎng)關(guān)的發(fā)展趨勢(shì)
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)