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

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

　　 容器技術實現地理分佈

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

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

　　像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 原文連結：