云原生要素介紹之抽象端點

51CTO
51CTO
分布式計算最基本的概念之一是端點??梢酝ㄟ^輸入和輸出來了解每一個軟件片段——對象、微服務(wù)、應(yīng)用程序,而這些都被稱之為交互端點。

分布式計算最基本的概念之一是端點??梢酝ㄟ^輸入和輸出來了解每一個軟件片段——對象、微服務(wù)、應(yīng)用程序,而這些都被稱之為交互端點。

在分布式計算的歷史上,端點有多種形式:套接字、IP地址、接口、Web服務(wù)和入口等。無論它們的性質(zhì)如何,其他軟件必須能夠找到合適的端點,連接或綁定它們,并與它們交互。

1.jpeg

端點也代表攻擊面中的漏洞,因此保護(hù)它們也是至關(guān)重要的。在最基本的情況下,端點是物理分布式計算架構(gòu)的一部分。但是,如果只是處理物理端點,就幾乎沒有靈活性,因此,如果可編程性有限,并且它們的可用性受到嚴(yán)重限制。由于這些原因,很多企業(yè)多年來就采用了許多抽象端點的方法,如今在構(gòu)建云原生基礎(chǔ)設(shè)施時延續(xù)了這一趨勢。

然而,在新的云原生計算模式中,抽象的端點具有新的含義。

抽象端點層

事實上,抽象端點既平凡又普通。DNS服務(wù)器抽象IP地址,其分配可以根據(jù)需要重新分配域名。負(fù)載均衡器可以將請求定向到不同的服務(wù)或應(yīng)用程序端點,而請求者并不知道。

表述性狀態(tài)傳遞(REST)的核心是使用URL來抽象端點和它們支持的操作。底層基礎(chǔ)設(shè)施可能會利用Web服務(wù)器、負(fù)載平衡器或API網(wǎng)關(guān)(或某些組合)來解析URL,并將流量定向到適當(dāng)?shù)奈锢矶它c。

REST場景強(qiáng)調(diào)了抽象端點的一個重要原則:通常情況下,一條消息可能會遍歷幾種不同的技術(shù),每個技術(shù)都將不同的抽象端點層添加到組合中。雖然這些層增加了架構(gòu)的復(fù)雜性,但為端點消費者增加靈活性和簡單性的好處通常會超過這種復(fù)雜性的成本。

云原生計算中的抽象端點

云原生計算需要其他形式的分布式計算不需要的額外抽象端點。

這種額外復(fù)雜性的原因是Kubernetes本身目標(biāo)的基礎(chǔ):在容器、Pod和集群級別提供快速而無限的水平可擴(kuò)展性。

服務(wù)網(wǎng)格使用代理在特定微服務(wù)實例之間路由“東西向”流量,即使請求的微服務(wù)通常也不知道在特定時間點有多少實例可用或它們的IP地址是什么。

換句話說,服務(wù)網(wǎng)格在入口點提供抽象端點,這對于使用在Kubernetes上運行的微服務(wù)至關(guān)重要。

當(dāng)請求者位于相關(guān)微服務(wù)域之外時,同樣的原則適用于“南北向”流量。在這些情況下,API網(wǎng)關(guān)處理抽象端點。

實現(xiàn)這些抽象端點的底層技術(shù)是不同的:東西向流量的Sidecar和代理以及南北向流量策略驅(qū)動的安全API網(wǎng)關(guān)。

云原生零信任

為抽象端點提供足夠和適當(dāng)?shù)陌踩越o基礎(chǔ)設(shè)施和安全團(tuán)隊帶來了新的挑戰(zhàn)。考慮到Kubernetes部署的動態(tài)特性及其對混合IT場景的支持,零信任方法將所有端點視為不可信,除非證明是可信的。

只有一個問題:“傳統(tǒng)的”零信任方法無法勝任這項任務(wù)。這種零信任的原始方法將端點與人類用戶相關(guān)聯(lián),因此傳統(tǒng)的身份和訪問管理技術(shù)僅適用于管理與端點關(guān)聯(lián)的人類身份。

相比之下,在云原生世界中,端點可能是微服務(wù)、API、智能手機(jī)、物聯(lián)網(wǎng)傳感器或任何數(shù)量的其他類型的技術(shù)。因此,不再可能利用人類身份來訪問大多數(shù)抽象端點。云原生零信任需要不同的方法。

連接與集成

云原生計算中的抽象端點使任何其他端點(消費者/請求者、消息源或接收者等)能夠在給定基礎(chǔ)設(shè)施的場景中找到并綁定到該端點。該基礎(chǔ)設(shè)施可能包括Kubernetes、服務(wù)目錄或其他支持技術(shù)。

這種能力稱之為端點連接。事實上,“連接性”這個術(shù)語本身就代表一種抽象,利用現(xiàn)有的端點抽象使這些端點能夠根據(jù)定義抽象的策略相互交互。

然而,連接性并不等同于集成。集成端點當(dāng)然需要連接性,但也需要在端點之間移動消息的機(jī)制。在Kubernetes之前的世界中,集成技術(shù)還提供了各種“智能”功能,包括數(shù)據(jù)轉(zhuǎn)換、安全性、流程邏輯執(zhí)行等。

依賴于這種集成中間件來完成這項繁重工作的架構(gòu)就是所謂的“智能管道、啞端點”架構(gòu)。企業(yè)不僅在大部分工作中利用集成技術(shù),而且除了遵守各自的契約(例如,Web服務(wù)的WSDL契約或RESTful端點的互聯(lián)網(wǎng)媒體類型)之外,不必依賴端點來完成更多的工作。

面向服務(wù)架構(gòu)(SOA)時代最重要的教訓(xùn)之一是智能管道方法過于集中,因此不是特別適合云計算。隨著分布式計算架構(gòu)轉(zhuǎn)向云計算,現(xiàn)在轉(zhuǎn)向云原生,人們將繁重的工作從中間件移出,轉(zhuǎn)而依賴輕量級排隊技術(shù)和其他開源集成方法。

如果管道以這種方式從智能變?yōu)榉侵悄?,那么端點只會從非智能變?yōu)橹悄?。在某種程度上,只要所說的智能端點是抽象端點,它們就必須如此。畢竟,物理端點可能仍然是IP地址、API或URL。人們不希望此類協(xié)議和技術(shù)比以往更智能。

與其相反,人們依賴于抽象的端點基礎(chǔ)設(shè)施來了解如何處理數(shù)據(jù)轉(zhuǎn)換、安全性、策略實施,以從企業(yè)服務(wù)總線(ESB)和其他傳統(tǒng)中間件所需的所有其他功能——現(xiàn)在才抽象出Kubernetes的可擴(kuò)展性和臨時性環(huán)境。

也可以抽象集成嗎?

假設(shè)一個端點是物聯(lián)網(wǎng)傳感器,另一個是基于云的API。如果充分抽象了這些端點,那么就為它們提供了連接性。

但是仍然必須物理地將消息從一個傳輸?shù)搅硪粋€——例如,這項任務(wù)可能包括5G、專用MPLS鏈路、某種中間件以及進(jìn)入選擇的云平臺。

在理想的云原生世界中,人們將根據(jù)既定策略自動處理此類集成的配置、管理和安全性,使人們能夠抽象集成以及端點本身,從而能夠出于性能或成本原因,在最終用戶不知情的情況下,將一項技術(shù)轉(zhuǎn)換為另一項技術(shù)。

其結(jié)果就是基于意圖的集成。利益相關(guān)者將表達(dá)端點之間交互的業(yè)務(wù)意圖(延遲、數(shù)據(jù)主權(quán)、可靠性和其他要求),基礎(chǔ)設(shè)施將自動、動態(tài)地選擇最佳路由拓?fù)浜图杉夹g(shù),以持續(xù)地符合該意圖。

SD-WAN等技術(shù)提供了部分解決方案,但這種基于意圖的集成的全部范圍仍主要在繪圖板上(盡管開源NATS項目正在順利實現(xiàn)這一愿景)。然而,沒有理由進(jìn)行等待。抽象端點在今天已成為現(xiàn)實,因此了解如何在云原生場景中實現(xiàn)它們對于兌現(xiàn)Kubernetes的承諾至關(guān)重要。

請求/回復(fù)

這篇文章中使用了請求/回復(fù)示例,因為它們比異步交互更易于解釋和理解。事情的真相是,異步、實時的流交互更像是云原生計算的規(guī)范,而請求/回復(fù)模式則是一個特例。

因此,重要的是要指出,抽象端點對于異步流用例也同樣重要。事實上,有一類新的“事件網(wǎng)格”技術(shù)概括了當(dāng)今服務(wù)網(wǎng)格處理異步流數(shù)據(jù)流的能力——既適用于東西向流量,也適用于南北向流量。

當(dāng)然,處理流數(shù)據(jù)流的策略執(zhí)行、安全性和可靠性會帶來一系列挑戰(zhàn),例如提高抽象端點重要性的標(biāo)準(zhǔn)。

隨著邊緣計算的成熟和流數(shù)據(jù)越來越成為企業(yè)計算的規(guī)范,而抽象集成以及端點對于保持云原生計算所承諾的可擴(kuò)展性、靈活性和彈性將變得越來越重要。

THEEND

最新評論(評論僅代表用戶觀點)

更多
暫無評論