Nginx的微服务架构分析

本篇内容主要讲解“Nginx的微服务架构分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Nginx的微服务架构分析”吧!

 介绍

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也可以在这种模式下工作，使用各种位置及其相关的上游。

最后 – 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的巧妙演示应用程序

MRA包括一个示例应用程序作为演示：Ingenious照片共享应用程序。 Ingenious在三种模型中实现 – 代理，路由器网格和结构。 Ingenious演示应用程序将于今年晚些时候向公众发布。

Ingenious是照片存储和共享应用程序的简化版本，la Flickr或Shutterfly。我们选择照片共享应用程序的原因有以下几点：

用户和开发人员都很容易掌握它的功能。

需要管理多个数据维度。

在应用程序中很容易融入漂亮的设计。

它提供了非对称计算要求 – 高强度和低强度处理的混合 – 可以实现跨不同功能的故障转移，扩展和监视功能的真实测试。

到此，相信大家对“Nginx的微服务架构分析”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！