[[434881]]

【51CTO.com快譯】分布式計算最基本的概念之一是端點。可以通過輸入和輸出來了解每一個軟件片段——對象、微服務、應用程序，而這些都被稱之為交互端點。

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

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

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

抽象端點層

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

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

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

云原生計算中的抽象端點

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

這種額外復雜性的原因是Kubernetes本身目標的基礎：在容器、Pod和集群級別提供快速而無限的水平可擴展性。

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

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

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

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

云原生零信任

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

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

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

連接與集成

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

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

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

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

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

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

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

也可以抽象集成嗎?

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

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

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

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

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

請求/回復

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

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

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

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

原文標題：Cloud-Native Essentials: Abstracted Endpoints，作者：Jason Bloomberg

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】