所有六个博客，以及一个关于微服务应用程序的Web前端的博客，都被收集到一个免费的电子书中。
另请查看有关微服务的其他NGINX资源：
AveryusefulandpopularseriesbyChrisRichardsonaboutmicroservicesapplicationdesignTheChrisRichardsonarticlescollectedintoafreeebook,withadditionaltipsonimplementingmicroserviceswithNGINXandNGINXPlusOthermicroservicesblogpostsMicroserviceswebinarsMicroservicesSolutionspageTopic:Microservices介绍
NGINX从一开始就参与了微服务运动。NGINX的轻巧，高性能和灵活性非常适合微服务。
NGINXDocker映像是DockerHub上排名第一的应用程序映像，您今天在Web上找到的大多数微服务平台都包含一个演示，它以某种形式部署NGINX并连接到欢迎页面。
因为我们认为转向微服务对于客户的成功至关重要，我们NGINX已经启动了一个专门的程序来开发支持Web应用程序开发和交付这种地震转变的功能和实践。我们还认识到，实现微服务有许多不同的方法，其中许多方法都是新颖的，并且特定于各个开发团队的需求。我们认为需要使用模型来使公司更容易开发和交付自己的基于微服务的应用程序。
考虑到这一切，NGINX专业服务部门正在开发NGINX微服务参考架构（MRA）-一组可用于创建自己的微服务应用程序的模型。
MRA由两部分组成：三个模型中的每一个的详细描述，以及实现我们的示例照片共享程序的可下载代码，Ingenious。三种型号的唯一区别是用于为每种型号配置NGINXPlus的配置代码。这一系列博客文章将提供每个模型的概述说明;Ingenious示例程序的详细描述，配置代码和代码将在今年晚些时候推出。
我们构建此参考架构的目标有三个：
为客户和行业提供随时可用的蓝图，用于构建基于微服务的系统，加速和改进开发创建用于测试NGINX和NGINXPlus中新功能的平台，无论是内部开发还是外部开发，分布在产品核心中或作为动态模块为了帮助我们了解合作伙伴系统和组件，我们可以从整体上了解微服务生态系统微服务参考架构也是NGINX客户专业服务产品的重要组成部分。在MRA中，我们尽可能使用NGINX开源和NGINXPlus共有的功能，并在需要时使用NGINXPlus特有的功能。NGINXPlus依赖关系在更复杂的模型中更强，如下所述。我们预计，MRA的许多用户将受益于NGINX专业服务的访问以及NGINXPlus订阅的技术支持。
微服务参考架构概述
我们正在构建参考架构以符合Twelve-FactorApp的原则。这些服务设计为轻量级，短暂的和无状态的。
MRA使用行业标准组件，如Docker容器，各种语言-Java，PHP，Python，NodeJS/JavaScript和Ruby-以及基于NGINX的网络。
迁移到微服务时，应用程序设计和体系结构的最大变化之一是使用网络在应用程序的功能组件之间进行通信。在单片应用程序中，应用程序组件在内存中进行通信。在微服务应用程序中，该通信通过网络进行，因此网络设计和实施变得至关重要。
为了反映这一点，MRA已经使用三种不同的网络模型实现，所有这些模型都使用NGINX或NGINXPlus。它们的范围从相对简单到功能丰富且更复杂：
代理模型（ProxyModel）-一种简单的网络模型，适用于实现NGINXPlus作为微服务应用程序的控制器或API网关。该模型建立在DockerCloud之上。路由器网格模型（RouterMeshModel）-一种更强大的网络方法，每台主机上都有一个负载均衡器，可以管理系统之间的连接。该模型类似于Deis1.0的体系结构。织品模型（FabricModel）-MRA的皇冠上的明珠，面料模型在每个容器中都有NGINXPlus，处理所有入口和出口交通。它适用于高负载系统，并支持所有级别的SSL/TLS，NGINXPlus提供减少的延迟，持久的SSL/TLS连接，服务发现以及所有微服务中的断路器模式。我们的目的是您使用这些模型作为您自己的微服务实现的起点，我们欢迎您提供有关如何改进MRA的反馈。（您可以从添加到下面的评论开始。）
以下是每种模型的简要说明;我们建议您阅读所有描述，以便开始了解如何最好地使用一个或多个模型。未来的博客文章将详细描述每个模型，每个博客文章一个。
代理模型简介
代理模型是一种相对简单的网络模型。它是初始微服务应用程序的出色起点，或者是转换中等复杂的单片遗留应用程序的目标模型。
在代理模型中，NGINX或NGINXPlus充当入口控制器，将请求路由到微服务。当创建新服务时，NGINXPlus可以使用动态DNS进行服务发现。当使用NGINX作为API网关时，代理模型也适合用作模板。
如果需要进行服务间通信-并且大多数应用程序都处于任何复杂程度-服务注册表提供集群内的机制。（有关服务间通信机制的详细列表，请参阅此博客文章。）DockerCloud默认使用此方法;为了连接到另一个服务，服务查询DNS并获取IP地址以发送请求。
通常，代理模型适用于简单到中等复杂的应用程序。它不是负载平衡最有效的方法/模型，特别是在规模上;如果您有严重的负载平衡要求，请使用下面描述的模型之一。（“Scale”可以指大量的微服务以及高流量。）
编辑器-有关此模型的深入探索，请参阅MRA，第2部分-代理模型。
路由器网格模型
路由器网格模型中等复杂，非常适合强大的新应用程序设计，也适用于转换不需要Fabric模型功能的更复杂的单片遗留应用程序。
通过在每个主机上运行负载均衡器并主动管理微服务之间的连接，路由器网状网模型采用比代理模型更强大的网络方法。路由器网格模型的主要优点是服务之间的更高效和稳健的负载平衡。如果使用NGINXPlus，则可以实施活动运行状况检查以监视各个服务实例，并在关闭时优雅地限制流量。
DeisWorkflow使用类似于路由器网格模型的方法在服务之间路由流量，NGINX实例在每个主机上的容器中运行。当新的应用程序实例被启动时，进程从etcd服务注册表中提取服务信息并将其加载到NGINX中。NGINXPlus也可以在这种模式下工作，使用各种位置及其相关的上游。
编辑器-有关此模型的深入探索，请参阅MRA，第3部分-路由器网格模型(