這篇文章主要講解了“采用Kubernetes時(shí)API網(wǎng)關(guān)面臨的兩個(gè)挑戰(zhàn)是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“采用Kubernetes時(shí)API網(wǎng)關(guān)面臨的兩個(gè)挑戰(zhàn)是什么”吧！

成都創(chuàng)新互聯(lián)公司從2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元鄒平做網(wǎng)站,已為上家服務(wù),為鄒平各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575

 KUBERNETES和邊緣計(jì)算，擴(kuò)展邊緣管理并支持多種需求

使用微服務(wù)模式構(gòu)建應(yīng)用程序并將這些服務(wù)部署到Kubernetes上已成為當(dāng)今運(yùn)行云原生應(yīng)用程序的實(shí)際方法。  在微服務(wù)架構(gòu)中，單個(gè)應(yīng)用程序被分解為多個(gè)微服務(wù)。 每個(gè)微服務(wù)均由一個(gè)小團(tuán)隊(duì)擁有，該團(tuán)隊(duì)有權(quán)并負(fù)責(zé)為特定的微服務(wù)做出正確的決策。

這種職責(zé)通常從用戶請(qǐng)求到達(dá)的系統(tǒng)邊緣開始，一直到服務(wù)的業(yè)務(wù)邏輯，再到相關(guān)的消息傳遞和數(shù)據(jù)存儲(chǔ)架構(gòu)。

Edge和Kubernetes入口

最終用戶需要訪問微服務(wù)。 內(nèi)部微服務(wù)和最終用戶之間的邊界稱為邊緣。 為了使最終用戶訪問內(nèi)部應(yīng)用程序，流量需要越過邊緣。  在Kubernetes中，流量使用一種稱為入口的軟件穿越邊緣。

將API網(wǎng)關(guān)與在Kubernetes上運(yùn)行的基于微服務(wù)的應(yīng)用程序集成時(shí)，您必須考慮兩個(gè)主要挑戰(zhàn)：

• 如何擴(kuò)展對(duì)100多種服務(wù)和相關(guān)API的管理; 和

• 網(wǎng)關(guān)如何支持通?？缯麄€(gè)邊緣堆棧的廣泛的微服務(wù)體系結(jié)構(gòu)，協(xié)議和配置。

API網(wǎng)關(guān)：微服務(wù)的聯(lián)絡(luò)點(diǎn)

API網(wǎng)關(guān)是如何管理，保護(hù)和呈現(xiàn)API的核心。 它作為軟件組件(或一系列組件)部署在虛擬機(jī)上或Kubernetes中，并充當(dāng)系統(tǒng)的單個(gè)入口點(diǎn)。  API網(wǎng)關(guān)的主要職責(zé)是使用戶能夠可靠，安全地訪問多個(gè)API，微服務(wù)和后端系統(tǒng)。

微服務(wù)和Kubernetes提供了實(shí)現(xiàn)靈活性。  例如，一個(gè)團(tuán)隊(duì)可以選擇在系統(tǒng)的邊緣(內(nèi)部服務(wù)和最終用戶之間的邊界)公開基于容器的微服務(wù)，作為一組基于HTTP的REST API。  另一個(gè)團(tuán)隊(duì)可能會(huì)選擇Protobufs和gRPC。 有實(shí)時(shí)流需求的團(tuán)隊(duì)可以通過WebSocket API公開其微服務(wù)。  Kubernetes中部署的任何API網(wǎng)關(guān)都必須支持所有這些協(xié)議。

每個(gè)團(tuán)隊(duì)不僅可以自由做出這些選擇，而且對(duì)后果負(fù)責(zé)。 這通常轉(zhuǎn)化為"您構(gòu)建，運(yùn)行"。  盡管并非每個(gè)組織都完全贊同這種工作方式，但是每個(gè)微服務(wù)團(tuán)隊(duì)都需要能夠理解，診斷和配置處理每個(gè)服務(wù)以及每個(gè)用戶對(duì)應(yīng)用程序的請(qǐng)求的各個(gè)方面。  與應(yīng)用程序和API相關(guān)的運(yùn)行時(shí)要求的多樣性意味著，每個(gè)團(tuán)隊(duì)都將使用邊緣堆棧中的所有層，例如，動(dòng)態(tài)請(qǐng)求處理，WAF和任何緩存實(shí)現(xiàn)。

微服務(wù)的開發(fā)范例(獨(dú)立，授權(quán)和負(fù)責(zé)的團(tuán)隊(duì))為使用API網(wǎng)關(guān)，Kubernetes入口和邊緣的微服務(wù)團(tuán)隊(duì)帶來了一系列新挑戰(zhàn)。

在本文中，我們確定了邊緣的兩個(gè)重要挑戰(zhàn)：管理獨(dú)立的微服務(wù)以及訪問全面的邊緣堆棧。

挑戰(zhàn)1：擴(kuò)展邊緣管理

隨著部署的微服務(wù)數(shù)量的增加，管理邊緣的挑戰(zhàn)也越來越多

在微服務(wù)架構(gòu)中，工程師將管理更多的服務(wù)和應(yīng)用程序。 每個(gè)團(tuán)隊(duì)都需要能夠獨(dú)立管理他們的服務(wù)，以使發(fā)布與其他團(tuán)隊(duì)的計(jì)劃脫鉤。  在邊緣公開應(yīng)用程序的傳統(tǒng)方法通常是通過集中的操作或平臺(tái)團(tuán)隊(duì)來完成的。 但是，當(dāng)組織擁有數(shù)百個(gè)微服務(wù)時(shí)，一個(gè)運(yùn)維團(tuán)隊(duì)無法擴(kuò)展以處理必要的變更量。

需要在邊緣修改配置的典型更改：

• 正在部署的服務(wù)的新版本。

• 修改端點(diǎn)，路由指令或關(guān)聯(lián)的后端服務(wù)。

• 身份驗(yàn)證和授權(quán)服務(wù)的更改。

• 修改非功能性需求，例如速率限制，超時(shí)，重試模式和斷路。

• 用戶對(duì)新功能的測(cè)試，例如，為一小部分Beta測(cè)試用戶啟用功能。

采用基于微服務(wù)的體系結(jié)構(gòu)將導(dǎo)致發(fā)行數(shù)量顯著增加。 這種增加只會(huì)加劇邊緣管理方面的挑戰(zhàn)，并增加集中式操作方法的壓力。

挑戰(zhàn)2：支持各種范圍的邊緣要求

微服務(wù)在邊緣引入了許多新問題

微服務(wù)架構(gòu)實(shí)現(xiàn)了架構(gòu)靈活性。 應(yīng)用程序開發(fā)人員利用這種靈活性來選擇最適合服務(wù)特定要求的編程語言和體系結(jié)構(gòu)。  無論架構(gòu)如何，邊緣都需要支持需要向用戶公開的廣泛功能。 這擴(kuò)展了API網(wǎng)關(guān)的傳統(tǒng)角色，并且與邊緣整合工具需求相關(guān)的一些挑戰(zhàn)包括：

• 熟練地路由各種協(xié)議的能力。 常見協(xié)議包括HTTP / 1.1，HTTP / 2，WebSocket，gRPC，gRPC-Web和TCP。

• 提供任何特定服務(wù)所需的完整邊緣功能集合，范圍從流量管理到可觀察性再到身份驗(yàn)證等等。

• 為應(yīng)用程序開發(fā)人員在自助服務(wù)模型中公開這些功能。

鼓勵(lì)微服務(wù)團(tuán)隊(duì)實(shí)施的多樣性使工程師可以選擇"適合工作的工具"。 但是，基礎(chǔ)平臺(tái)的整合提供了許多好處。  與其允許開發(fā)人員構(gòu)建定制的實(shí)現(xiàn)以提供額外的協(xié)議支持或安全處理，不如讓其在邊緣具有預(yù)先批準(zhǔn)的"自助"選項(xiàng)，從而使他們可以選擇最合適的選項(xiàng)，從而更加易于管理和擴(kuò)展。  功能組合。

感謝各位的閱讀，以上就是“采用Kubernetes時(shí)API網(wǎng)關(guān)面臨的兩個(gè)挑戰(zhàn)是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)采用Kubernetes時(shí)API網(wǎng)關(guān)面臨的兩個(gè)挑戰(zhàn)是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！