介绍NGINX微服务参考架构（本帖）MRA，Part2:TheProxyModelMRA,Part3:TheRouterMeshModelMRA,Part4:TheFabricModelMRA，第5部分：为微服务调整十二因素应用程序MRA，第6部分：使用NGINXPlus实现断路器模式另请查看有关微服务的其他NGINX资源：ChrisRichardson撰写的关于微服务应用程序设计的非常有用且受欢迎的系列文章TheChrisRichardson的文章收集到一本免费电子书中，其中包含有关使用NGINX和NGINXPlus实施微服务的其他技巧其他微服务博客文章微服务网络研讨会微服务解决方案页面主题：微服务简介NGINX从一开始就参与了微服务运动。NGINX的轻量级、高性能和灵活性是微服务的理想选择。NGINXDocker镜像是DockerHub上排名第一的应用程序镜像，您今天在网络上找到的大多数微服务平台都包含一个以某种形式部署NGINX并连接到欢迎页面的演示。因为我们相信转向微服务对我们客户的成功至关重要，我们NGINX已经启动了一个专门的计划来开发支持Web应用程序开发和交付中这种巨大转变的功能和实践。我们还认识到，有许多不同的方法来实现微服务，其中许多是新颖的并且特定于各个开发团队的需求。我们认为有必要使用模型来使公司更容易开发和交付他们自己的基于微服务的应用程序。考虑到所有这些，NGINX专业服务正在开发NGINX微服务参考架构(MRA)—一组可用于创建自己的微服务应用程序的模型。MRA由两部分组成：三个模型中每一个的详细描述，以及实现我们的示例照片共享程序Ingenious的可下载代码。三个模型之间的唯一区别是用于为每个模型配置NGINXPlus的配置代码。本系列博文将为每个模型提供概述说明；Ingenious示例程序、配置代码和代码的详细说明将在今年晚些时候提供。我们构建此参考架构的目标有三个：为客户和行业提供构建基于微服务的系统的现成蓝图加速和改进开发创建一个平台来测试NGINX和NGINXPlus中的新功能，包括内部开发或在外部，分布在产品核心中或作为动态模块帮助我们了解合作伙伴系统和组件，我们可以从整体上了解微服务生态系统微服务参考架构也是NGINX客户专业服务产品的重要组成部分。在MRA中，我们尽可能使用NGINX开源和NGINXPlus通用的特性，并在需要时使用NGINXPlus特有的特性。NGINXPlus依赖性在更复杂的模型中更强，如下所述。我们预计MRA的许多用户将受益于对NGINX专业服务的访问以及NGINXPlus订阅的技术支持。微服务参考架构概述我们正在构建一个参考架构，以符合十二要素应用程序的原则。这些服务被设计成轻量级的、短暂的和无状态的。MRA使用行业标准组件，例如Docker容器、各种语言-Java、PHP、Python、NodeJS/JavaScript和Ruby-以及基于NGINX的网络。迁移到微服务时应用程序设计和架构的最大变化之一是使用网络在应用程序的功能组件之间进行通信。在单体应用程序中，应用程序组件在内存中进行通信。在微服务应用程序中，这种通信通过网络进行，因此网络设计和实现变得至关重要。为了反映这一点，MRA已经使用三种不同的网络模型实施，所有这些模型都使用NGINX或NGINXPlus。它们的范围从相对简单到功能丰富和更复杂：代理模型-一种简单的网络模型，适合将NGINXPlus实现为微服务应用程序的控制器或API网关。该模型建立在DockerCloud之上。路由器网状模型-一种更健壮的网络方法，在每个主机上都有一个负载平衡器来管理系统之间的连接。这个模型类似于Deis1.0的架构。FabricModel-MRA的皇冠上的明珠，FabricModel在每个容器中都有NGINXPlus，处理所有入口和出口流量。它适用于高负载系统并支持所有级别的SSL/TLS，NGINXPlus在所有微服务中提供减少延迟、持久SSL/TLS连接、服务发现和断路器模式。我们的目的是让您使用这些模型作为您自己的微服务实施的起点，我们欢迎您就如何改进MRA提供反馈。（您可以从添加到下面的评论开始。）以下是每个模型的简要说明；我们建议您阅读所有说明以开始了解如何最好地使用一个或多个模型。未来的博文将详细描述每个模型，每篇博文一个。代理模型简介代理模型是一种比较简单的网络模型。它是初始微服务应用程序的绝佳起点，或者是转换适度复杂的单一遗留应用程序的目标模型。在代理模型中，NGINX或NGINXPlus充当入口控制器，将请求路由到微服务。NGINXPlus在创建新服务时可以使用动态DNS进行服务发现。当使用NGINX作为API网关时，代理模型也适合用作模板。如果需要服务间通信——而且大多数应用程序都处于任何复杂程度——服务注册中心提供了一种集群内机制。（有关服务间通信机制的详细列表，请参阅此博客文章。）DockerCloud默认使用此方法；为了连接到另一个服务，该服务查询DNS并获取IP地址以发送请求。一般来说，代理模型适用于简单到中等复杂的应用程序。它不是最有效的负载平衡方法/模型，尤其是在规模上；如果您有严格的负载平衡要求，请使用下面描述的模型之一。（“规模”可以指大量的微服务以及高流量。）编辑-要深入探索此模型，请参阅MRA，第2部分-代理模型。路由器网状模型路由器网状模型适度复杂，非常适合稳健的新应用程序设计，也适用于转换不需要结构模型功能的更复杂的单一遗留应用程序。路由器网格模型通过在每个主机上运行负载均衡器并主动管理微服务之间的连接，采用比代理模型更健壮的网络方法。路由器网状模型的主要优点是服务之间的负载平衡更高效、更健壮。如果使用NGINXPlus，您可以实施主动健康检查来监控各个服务实例，并在它们关闭时优雅地限制流量。DeisWorkflow使用类似于路由器网状模型的方法在服务之间路由流量，NGINX实例在每个主机上的容器中运行。当启动一个新的应用程序实例时，该进程从etcd服务注册表中提取服务信息并将其加载到NGINX中。NGINXPlus也可以在这种模式下工作，使用不同的位置及其相关的上游。编辑器-要深入探索此模型，请参阅MRA，第3部分-路由器网格模型(https://www.nginx.com/blog/microservices-reference-architecture-nginx-router-mesh-model/).最后-Fabric模型，带有可选的SSL/TLS我们在NGINX中对Fabric模型最为兴奋。它带来了微服务的一些最令人兴奋的承诺，包括高性能、负载平衡的灵活性和无处不在的SSL/TLS，直至单个微服务级别。Fabric模型适用于安全应用程序，并且可以扩展到非常大的应用程序。在Fabric模型中，NGINXPlus部署在每个容器中，并成为进出容器的所有HTTP流量的代理。该应用程序与所有服务连接的本地(localhost)主机位置通信，并依赖NGINXPlus进行服务发现、负载平衡和健康检查。在我们的配置中，NGINXPlus向ZooKeeper查询应用程序需要连接的所有服务实例。例如，将DNS频率设置（活动）设置为1秒，NGINXPlus将每秒扫描一次ZooKeeper并适当地路由流量。得益于NGINXPlus中强大的HTTP处理，我们可以使用keepalive来维护与微服务的有状态连接，从而减少延迟并提高性能。当使用SSL/TLS来保护微服务之间的流量时，这是一个特别有价值的功能。最后，我们使用NGINXPlus的主动健康检查来管理健康实例的流量，并且基本上免费构建断路器模式。编辑-要深入探索此模型，请参阅MRA，第4部分-Fabric模型(https://www.nginx.com/blog/microservices-reference-architecture-nginx-fabric-model/)。MRA的Ingenious演示应用程序MRA包含一个示例应用程序作为演示：Ingenious照片共享应用程序。Ingenious以三种模型实现-代理、路由器网状网络和结构。Ingenious演示应用程序将于今年晚些时候向公众发布。Ingenious是照片存储和共享应用程序的精简版，类似Flickr或Shutterfly。我们选择照片共享应用程序的原因如下：对于用户和开发人员而言，它的功能都易于掌握。需要管理多个数据维度。很容易在应用程序中加入漂亮的设计。它提供了非对称计算要求——高强度和低强度处理的混合——支持跨不同功能的故障转移、扩展和监控能力的真实测试。结论NGINX微服务参考架构对我们以及我们迄今为止共享的客户和合作伙伴来说是一个令人兴奋的发展。在接下来的几个月里，我们将在今年晚些时候发布一系列详细描述它的博客文章。我们还将在9月7日至9日于德克萨斯州奥斯汀举行的nginx.conf2016上详细讨论它。请给我们您的反馈，我们期待您的光临。原文：https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/本文：http://pub.intelligentx.net/introducing-microservices-reference-architecture-nginx
