基于Nginx的微服務參考架構有哪些

小編給大家分享一下基于Nginx的微服務參考架構有哪些，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

介紹

NGINX從一開始就參與了微服務運動。 NGINX的輕巧，高性能和靈活性非常適合微服務。

NGINX Docker映像是Docker  Hub上排名第一的應用程序映像，您今天在Web上找到的大多數微服務平臺都包含一個演示，它以某種形式部署NGINX并連接到歡迎頁面。

因為我們認為轉向微服務對于客戶的成功至關重要，我們NGINX已經啟動了一個專門的程序來開發支持Web應用程序開發和交付這種地震轉變的功能和實踐。我們還認識到，實現微服務有許多不同的方法，其中許多方法都是新穎的，并且特定于各個開發團隊的需求。我們認為需要使用模型來使公司更容易開發和交付自己的基于微服務的應用程序。

考慮到這一切，NGINX專業服務部門正在開發NGINX微服務參考架構(MRA) - 一組可用于創建自己的微服務應用程序的模型。

MRA由兩部分組成：三個模型中的每一個的詳細描述，以及實現我們的示例照片共享程序的可下載代碼，Ingenious。三種型號的唯一區別是用于為每種型號配置NGINX  Plus的配置代碼。這一系列博客文章將提供每個模型的概述說明; Ingenious示例程序的詳細描述，配置代碼和代碼將在今年晚些時候推出。

我們構建此參考架構的目標有三個：

1. 為客戶和行業提供隨時可用的藍圖，用于構建基于微服務的系統，加速和改進開發

2. 創建用于測試NGINX和NGINX Plus中新功能的平臺，無論是內部開發還是外部開發，分布在產品核心中或作為動態模塊

3. 為了幫助我們了解合作伙伴系統和組件，我們可以從整體上了解微服務生態系統

微服務參考架構也是NGINX客戶專業服務產品的重要組成部分。在MRA中，我們盡可能使用NGINX開源和NGINX  Plus共有的功能，并在需要時使用NGINX Plus特有的功能。 NGINX  Plus依賴關系在更復雜的模型中更強，如下所述。我們預計，MRA的許多用戶將受益于NGINX專業服務的訪問以及NGINX Plus訂閱的技術支持。

微服務參考架構概述

我們正在構建參考架構以符合Twelve-Factor App的原則。這些服務設計為輕量級，短暫的和無狀態的。

MRA使用行業標準組件，如Docker容器，各種語言 - Java，PHP，Python，NodeJS / JavaScript和Ruby -  以及基于NGINX的網絡。

遷移到微服務時，應用程序設計和體系結構的最大變化之一是使用網絡在應用程序的功能組件之間進行通信。在單片應用程序中，應用程序組件在內存中進行通信。在微服務應用程序中，該通信通過網絡進行，因此網絡設計和實施變得至關重要。

為了反映這一點，MRA已經使用三種不同的網絡模型實現，所有這些模型都使用NGINX或NGINX Plus。它們的范圍從相對簡單到功能豐富且更復雜：

• 代理模型 (Proxy Model)- 一種簡單的網絡模型，適用于實現NGINX Plus作為微服務應用程序的控制器或API網關。該模型建立在Docker  Cloud之上。

• 路由器網格模型(Router Mesh Model ) -  一種更強大的網絡方法，每臺主機上都有一個負載均衡器，可以管理系統之間的連接。該模型類似于Deis 1.0的體系結構。

• 織品模型 (Fabric Model) - MRA的皇冠上的明珠，面料模型在每個容器中都有NGINX  Plus，處理所有入口和出口交通。它適用于高負載系統，并支持所有級別的SSL / TLS，NGINX Plus提供減少的延遲，持久的SSL /  TLS連接，服務發現以及所有微服務中的斷路器模式。

我們的目的是您使用這些模型作為您自己的微服務實現的起點，我們歡迎您提供有關如何改進MRA的反饋。 (您可以從添加到下面的評論開始。)

以下是每種模型的簡要說明;我們建議您閱讀所有描述，以便開始了解如何最好地使用一個或多個模型。未來的博客文章將詳細描述每個模型，每個博客文章一個。

代理模型簡介

代理模型是一種相對簡單的網絡模型。它是初始微服務應用程序的出色起點，或者是轉換中等復雜的單片遺留應用程序的目標模型。

在代理模型中，NGINX或NGINX Plus充當入口控制器，將請求路由到微服務。當創建新服務時，NGINX  Plus可以使用動態DNS進行服務發現。當使用NGINX作為API網關時，代理模型也適合用作模板。

如果需要進行服務間通信 - 并且大多數應用程序都處于任何復雜程度 - 服務注冊表提供集群內的機制。  (有關服務間通信機制的詳細列表，請參閱此博客文章。)Docker  Cloud默認使用此方法;為了連接到另一個服務，服務查詢DNS并獲取IP地址以發送請求。

通常，代理模型適用于簡單到中等復雜的應用程序。它不是負載平衡最有效的方法/模型，特別是在規模上;如果您有嚴重的負載平衡要求，請使用下面描述的模型之一。  (“Scale”可以指大量的微服務以及高流量。)

編輯器 - 有關此模型的深入探索，請參閱MRA，第2部分 - 代理模型。

路由器網格模型

路由器網格模型中等復雜，非常適合強大的新應用程序設計，也適用于轉換不需要Fabric模型功能的更復雜的單片遺留應用程序。

通過在每個主機上運行負載均衡器并主動管理微服務之間的連接，路由器網狀網模型采用比代理模型更強大的網絡方法。路由器網格模型的主要優點是服務之間的更高效和穩健的負載平衡。如果使用NGINX  Plus，則可以實施活動運行狀況檢查以監視各個服務實例，并在關閉時優雅地限制流量。

Deis  Workflow使用類似于路由器網格模型的方法在服務之間路由流量，NGINX實例在每個主機上的容器中運行。當新的應用程序實例被啟動時，進程從etcd服務注冊表中提取服務信息并將其加載到NGINX中。  NGINX Plus也可以在這種模式下工作，使用各種位置及其相關的上游。

編輯器 - 有關此模型的深入探索，請參閱MRA，第3部分 -  路由器網格模型(https://www.nginx.com/blog/microservices-reference-architecture-nginx-router-mesh-model/)。

最后 - Fabric模型，帶有可選的SSL / TLS

我們NGINX對Fabric模型最為興奮。它帶來了一些最令人興奮的微服務承諾，包括高性能，負載平衡的靈活性，以及無處不在的SSL /  TLS，直到單個微服務的水平。 Fabric模型適用于安全應用程序，可擴展到非常大的應用程序。

在Fabric模型中，NGINX  Plus部署在每個容器中，并成為進出容器的所有HTTP流量的代理。應用程序與本地(localhost)主機位置通信以獲取所有服務連接，并依賴NGINX  Plus進行服務發現，負載平衡和運行狀況檢查。

在我們的配置中，NGINX Plus向ZooKeeper查詢應用程序需要連接的所有服務實例。例如，使用DNS頻率設置(有效)設置為1秒，NGINX  Plus會每隔一秒掃描ZooKeeper，并適當地路由流量。

由于NGINX Plus中強大的HTTP處理功能，我們可以使用keepalive來維護與微服務的狀態連接，減少延遲并提高性能。當使用SSL /  TLS來保護微服務之間的流量時，這是一個特別有價值的功能。

最后，我們使用NGINX Plus的主動健康檢查來管理健康實例的流量，并且基本上免費構建斷路器模式。

編輯 - 有關此模型的深入探索，請參閱MRA，第4部分 -  結構模型(https://www.nginx.com/blog/microservices-reference-architecture-nginx-fabric-model/)。

MRA的巧妙演示應用程序

MRA包括一個示例應用程序作為演示：Ingenious照片共享應用程序。 Ingenious在三種模型中實現 - 代理，路由器網格和結構。  Ingenious演示應用程序將于今年晚些時候向公眾發布。

Ingenious是照片存儲和共享應用程序的簡化版本，la Flickr或Shutterfly。我們選擇照片共享應用程序的原因有以下幾點：

1. 用戶和開發人員都很容易掌握它的功能。

2. 需要管理多個數據維度。

3. 在應用程序中很容易融入漂亮的設計。

4. 它提供了非對稱計算要求 - 高強度和低強度處理的混合 - 可以實現跨不同功能的故障轉移，擴展和監視功能的真實測試。

看完了這篇文章，相信你對“基于Nginx的微服務參考架構有哪些”有了一定的了解，如果想了解更多相關知識，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！