如何管理基於微服務的分散式應用程序

通過在微服務上構建分散式應用，可以提供一種很好的方式來運行雲原生應用程序。這種分散式應用程序架構為企業帶來了更大的優勢——改進對性能的控制、高可用性、更好的災難恢復和更深層次的可見性——但基於微服務構建的分散式應用遠比傳統應用複雜，因此這種構建可以說既是一門藝術，也是一門科學。

容器技術實現地理分布

傳統應用程序往往與它們的底層基礎設施緊密相連。現代容器技術改變了這種關係，因為它能夠通過將基礎設施層從應用程序代碼中抽象出來，讓同一個應用程序可以在任何類型的基礎設施上運行。這種轉變開創了多雲或混合雲模式的時代。應用程序可移植性是吸引開發人員使用容器的第一個原因，也是容器技術在支持分散式微服務方面的一個顯著特性。

地理分布的應用程序有各種形狀和大小。你可以集中應用程序的某些方面，並將其他方面進行分布。進行地理分布時，你必須考慮雲供應商的可用區域。除了雲供應商的數據中心之外，你還可以將數據存儲在你自己的數據中心，可以在本地或遠程管理這些數據中心。除了硬體的物理位置之外，開發團隊和最終用戶的位置也有助於確定應用程序性能。因此，選擇一個離應用程序用戶最近的物理位置非常重要。

像Kubernetes這樣的容器編排工具，能夠將在分散式環境中運行應用程序所需的所有組件組合在一起。Kubernetes可用於管理任何雲供應商上的雲實例，它將容器實例抽象為一組Pod，使基礎設施易於管理，更適合分散式應用程序。

在Kubernetes中，每個Pod都應該有一個副本Pod，作為主Pod的備份。每個Kubernetes部署的副本數量是使用ReplicaSet自動控制的。副本還有助於提高在流量高峰期的水平可伸縮性。

管理網路作為一個單獨的層

容器網路近年來日趨成熟，最大的一點是我們現在可以將存儲和網路等視為與應用程序層和基礎結構層分離的層。有一些功能強大的Kubernetes網路工具，如Istio、Linkerd和gRPC，都可以用於改善負載平衡、服務發現和其他關鍵網路進程。

服務連接工具gRPC使用HTTP/2協議，支持多個雙向流調用。在一個地理分布的微服務應用程序中，網路調用的數量必然很高，像gRPC這樣的工具提供了能夠大規模處理這些調用的渠道。

Kubernetes還以一種對地理分布的微服務應用程序有效的方式處理網路，因為它遵循網路代理的sidecar代理模型。sidecar容器並不獨立存在，而是支持Kubernetes Pod中的另一個主容器或另一組容器。它可用於通過日誌代理收集日誌，或使用網路代理來處理服務到服務(service-to-service)的通信。

在分散式微服務應用程序中，服務到服務的通信量是巨大而複雜的。與其在應用程序代碼或應用程序容器中配置所有聯網邏輯，不如將它們分離到sidecar容器中。這可以幫助我們在應用程序之外管理它們，甚至可以在未來重用它們，以節省時間。

Latency-aware數據存儲

在地理分布的應用程序中，如何管理存儲將直接影響應用程序的性能。為了保證應用程序處理請求的速度，訪問遠程存儲數據並保證數據傳輸速率是非常重要的。

企業應用程序通常會在諸如SAP ERP、Oracle E-Business Suite等系統中容納數萬甚至數百萬個數據點。要讓應用程序訪問和使用這些大型數據集，需要的不僅僅是按指定路線發送(routing)一個請求到正確的資料庫。系統必須配置為，在此過程中處理延遲和微故障。

當能夠從遠程位置獲取數據時，配置為最終數據一致性的應用程序會運行得很好。在這個模型中，數據以塊的形式獲取，當每一塊數據到達前端設備時，它可以直接進行載入而不用等待所有的數據塊。通過這種操作方式，可以稍後在更新數據本身，使其與後端資料庫保持一致，但重點仍然是在處理大型數據集的情況下交付快速的UI。

在移動應用程序中，數據緩存是處理數據訪問的一個重要方面。應用程序來回請求數據是低效的，其中一些數據可能會被複制。如果應用程序將部分數據存儲在客戶機上，那就更好了，因為客戶機需要一種一致的方式來處理離線功能的數據緩存。更少的請求可以加速數據傳輸，並在應用程序中提供更好的用戶體驗。

使用微服務的地理分布應用程序在今天的雲原生環境中很常見。容器技術會有助於這種架構的設置，並幫助用戶管理數據交付的各個方面，比如網路和存儲，而這些方面與應用程序代碼本身是分離的。隨著相關技術的進步，基於微服務構建的地理分布應用程序的管理將比以往任何時候都更容易，並且應成為高效的軟體交付策略中的一部分。

來源：TechTarget 原文鏈接請戳了解更多。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！