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

在酒泉等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作 網(wǎng)站設(shè)計(jì)制作按需策劃,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站制作,酒泉網(wǎng)站建設(shè)費(fèi)用合理。

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

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

Edge和Kubernetes入口

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

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

• 如何擴(kuò)展對100多種服務(wù)和相關(guān)API的管理; 和
• 網(wǎng)關(guān)如何支持通?？缯麄€邊緣堆棧的廣泛的微服務(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)的單個入口點(diǎn)。 API網(wǎng)關(guān)的主要職責(zé)是使用戶能夠可靠，安全地訪問多個API，微服務(wù)和后端系統(tǒng)。

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

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

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

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

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

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

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

• 正在部署的服務(wù)的新版本。
• 修改端點(diǎn)，路由指令或關(guān)聯(lián)的后端服務(wù)。
• 身份驗(yàn)證和授權(quán)服務(wù)的更改。
• 修改非功能性需求，例如速率限制，超時，重試模式和斷路。
• 用戶對新功能的測試，例如，為一小部分Beta測試用戶啟用功能。

采用基于微服務(wù)的體系結(jié)構(gòu)將導(dǎo)致發(fā)行數(shù)量顯著增加。 這種增加只會加劇邊緣管理方面的挑戰(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ù)模型中公開這些功能。

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

摘要

隨著組織采用Kubernetes并轉(zhuǎn)向基于微服務(wù)的體系結(jié)構(gòu)，最終用戶與內(nèi)部微服務(wù)之間的邊界出現(xiàn)了一系列新的挑戰(zhàn)。 因此，系統(tǒng)的"邊緣"以及相關(guān)技術(shù)(例如API網(wǎng)關(guān))是采用微服務(wù)時的重點(diǎn)。 微服務(wù)的組織模型驅(qū)動著邊緣的這些新挑戰(zhàn)，在這種模型中，獨(dú)立團(tuán)隊(duì)有權(quán)并負(fù)責(zé)為微服務(wù)制定正確的體系結(jié)構(gòu)和實(shí)施決策。

管理系統(tǒng)邊緣一直很復(fù)雜。 添加具有多種體系結(jié)構(gòu)的更多服務(wù)只會增加對邊緣的需求。 平臺團(tuán)隊(duì)必須相應(yīng)地設(shè)計(jì)，選擇和實(shí)現(xiàn)其API網(wǎng)關(guān)和邊緣工具。

分享標(biāo)題：采用Kubernetes時API網(wǎng)關(guān)面臨的兩個很重要的挑戰(zhàn)
網(wǎng)站鏈接：http://uogjgqi.cn/article/dhhgpep.html