[[434881]]

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

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

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

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

抽象端點層

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

表述性狀態傳遞(REST)的核心是使用URL來抽象端點和它們支持的操作。底層基礎設施可能會利用Web服務器、負載平衡器或API網關(或某些組合)來解析URL，并將流量定向到適當的物理端點。

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

云原生計算中的抽象端點

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

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

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

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

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

實現這些抽象端點的底層技術是不同的：東西向流量的Sidecar和代理以及南北向流量策略驅動的安全API網關。

云原生零信任

為抽象端點提供足夠和適當的安全性給基礎設施和安全團隊帶來了新的挑戰。考慮到Kubernetes部署的動態特性及其對混合IT場景的支持，零信任方法將所有端點視為不可信，除非證明是可信的。

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

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

連接與集成

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

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

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

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

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

如果管道以這種方式從智能變為非智能，那么端點只會從非智能變為智能。在某種程度上，只要所說的智能端點是抽象端點，它們就必須如此。畢竟，物理端點可能仍然是IP地址、API或URL。人們不希望此類協議和技術比以往更智能。

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

也可以抽象集成嗎?

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

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

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

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

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

請求/回復

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

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

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

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

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

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