所有六個博客，以及一個關於微服務應用程式的Web前端的博客，都被收集到一個免費的電子書中。
另請查看有關微服務的其他NGINX資源：
A very useful and popular series by Chris Richardson about microservices application designThe Chris Richardson articles collected into a free ebook, with additional tips on implementing microservices with NGINX and NGINX PlusOther microservices blog postsMicroservices webinarsMicroservices Solutions pageTopic: Microservices介紹
NGINX從一開始就參與了微服務運動。 NGINX的輕巧，高性能和靈活性非常適合微服務。
NGINX Docker映像是Docker Hub上排名第一的應用程式映像，您今天在Web上找到的大多數微服務平臺都包含一個演示，它以某種形式部署NGINX並連接到歡迎頁面。
因為我們認為轉向微服務對於客戶的成功至關重要，我們NGINX已經啟動了一個專門的程序來開發支持Web應用程式開發和交付這種地震轉變的功能和實踐。我們還認識到，實現微服務有許多不同的方法，其中許多方法都是新穎的，並且特定於各個開發團隊的需求。我們認為需要使用模型來使公司更容易開發和交付自己的基於微服務的應用程式。
考慮到這一切，NGINX專業服務部門正在開發NGINX微服務參考架構（MRA） - 一組可用於創建自己的微服務應用程式的模型。
MRA由兩部分組成：三個模型中的每一個的詳細描述，以及實現我們的示例照片共享程序的可下載代碼，Ingenious。三種型號的唯一區別是用於為每種型號配置NGINX Plus的配置代碼。這一系列博客文章將提供每個模型的概述說明; Ingenious示例程序的詳細描述，配置代碼和代碼將在今年晚些時候推出。
我們構建此參考架構的目標有三個：
為客戶和行業提供隨時可用的藍圖，用於構建基於微服務的系統，加速和改進開發創建用於測試NGINX和NGINX Plus中新功能的平臺，無論是內部開發還是外部開發，分布在產品核心中或作為動態模塊為了幫助我們了解合作夥伴系統和組件，我們可以從整體上了解微服務生態系統微服務參考架構也是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。我們選擇照片共享應用程式的原因有以下幾點：
用戶和開發人員都很容易掌握它的功能。需要管理多個數據維度。在應用程式中很容易融入漂亮的設計。它提供了非對稱計算要求 - 高強度和低強度處理的混合 - 可以實現跨不同功能的故障轉移，擴展和監視功能的真實測試。結論
NGINX微服務參考架構對我們來說是一個令人興奮的發展，對於我們迄今為止共享的客戶和合作夥伴而言。 在接下來的幾個月裡，我們將發布一系列博客文章，詳細描述它，我們將在今年晚些時候推出。 我們還將在9月7日至9日在德克薩斯州奧斯汀舉行的nginx.conf 2016上詳細討論。 請給我們您的反饋意見，我們期待著與您相見