用nginx做微服务网关（nginx和微服务）

本篇文章给大家谈谈用nginx做微服务网关，以及nginx和微服务对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享用nginx做微服务网关的知识，其中也会对nginx和微服务进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、「微服务架构」部署NGINX Plus作为API网关，第1部分 - NGINX
• 2、如何用Nginx快速搭建一个安全的微服务架构
• 3、nginx的项目实战：nginx反向代理微服务端口
• 4、23 nginx 和zuul 的区别
• 5、微服务网关层

「微服务架构」部署NGINX Plus作为API网关，第1部分 - NGINX

了解着名的Nginx服务器（微服务必不可少的东西）如何用作API网关。

现代应用程序体系结构的核心是HTTP API。 HTTP使应用程序能够快速构建并轻松维护。无论应用程序的规模如何，HTTP API都提供了一个通用接口，从单用途微服务到无所不包的整体。通过使用HTTP，支持超大规模Internet属性的Web应用程序交付的进步也可用于提供可靠和高性能的API交付。

有关API网关对微服务应用程序重要性的精彩介绍，请参阅我们博客上的构建微服务：使用API​​网关。

作为领先的高性能，轻量级反向代理和负载均衡器，NGINX Plus具有处理API流量所需的高级HTTP处理功能。这使得NGINX Plus成为构建API网关的理想平台。在这篇博文中，我们描述了许多常见的API网关用例，并展示了如何配置NGINX Plus以便以高效，可扩展且易于维护的方式处理它们。我们描述了一个完整的配置，它可以构成生产部署的基础。

注意：除非另有说明，否则本文中的所有信息均适用于NGINX Plus和NGINX开源。

API网关的主要功能是为多个API提供单一，一致的入口点，无论它们在后端如何实现或部署。并非所有API都是微服务应用程序。我们的API网关需要管理现有的API，单块和正在部分过渡到微服务的应用程序。

在这篇博文中，我们引用了一个假设的库存管理API，即“仓库API”。我们使用示例配置代码来说明不同的用例。 Warehouse API是一个RESTful API，它使用JSON请求并生成JSON响应。但是，当部署为API网关时，使用JSON不是NGINX Plus的限制或要求; NGINX Plus与API本身使用的架构风格和数据格式无关。

Warehouse API实现为离散微服务的集合，并作为单个API发布。库存和定价资源作为单独的服务实施，并部署到不同的后端。所以API的路径结构是：

例如，要查询当前仓库库存，客户端应用程序会向/ api / warehouse / inventory发出HTTP GET请求。
使用NGINX Plus作为API网关的一个优点是，它可以执行该角色，同时充当现有HTTP流量的反向代理，负载平衡器和Web服务器。如果NGINX Plus已经是应用程序交付堆栈的一部分，那么通常不需要部署单独的API网关。但是，API网关所期望的某些默认行为与基于浏览器的流量的预期不同。出于这个原因，我们将API网关配置与基于浏览器的流量的任何现有（或未来）配置分开。

为实现这种分离，我们创建了一个支持多用途NGINX Plus实例的配置布局，并为通过CI / CD管道自动配置部署提供了便利的结构。 / etc / nginx下的结果目录结构如下所示。

所有API网关配置的目录和文件名都以api_为前缀。这些文件和目录中的每一个都启用API网关的不同特性和功能，并在下面详细说明。

所有NGINX配置都以主配置文件nginx.conf开头。要读入API网关配置，我们在nginx.conf的http块中添加一个指令，该指令引用包含网关配置的文件api_gateway.conf（下面的第28行）。请注意，默认的nginx.conf文件使用include伪指令从conf.d子目录中引入基于浏览器的HTTP配置（第29行）。本博文广泛使用include指令来提高可读性并实现配置某些部分的自动化。

api_gateway.conf文件定义了将NGINX Plus公开为客户端的API网关的虚拟服务器。此配置公开API网关在单个入口点https://api.example.com/（第13行）发布的所有API，受第16到21行配置的TLS保护。请注意，此配置纯粹是HTTPS - 没有明文HTTP侦听器。我们希望API客户端知道正确的入口点并默认进行HTTPS连接。

此配置是静态的 - 各个API及其后端服务的详细信息在第24行的include伪指令引用的文件中指定。第27到30行处理日志记录默认值和错误处理，并在响应中讨论错误部分如下。

一些API可以在单个后端实现，但是出于弹性或负载平衡的原因，我们通常期望存在多个API。使用微服务API，我们为每个服务定义单独的后端;它们一起作为完整的API。在这里，我们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。

API网关发布的所有API的所有后端API服务都在api_backends.conf中定义。这里我们在每个块中使用多个IP地址 - 端口对来指示API代码的部署位置，但也可以使用主机名。 NGINX Plus订户还可以利用动态DNS负载平衡，自动将新后端添加到运行时配置中。

配置的这一部分首先定义Warehouse API的有效URI，然后定义用于处理对Warehouse API的请求的公共策略。

Warehouse API定义了许多块。 NGINX Plus具有高效灵活的系统，可将请求URI与配置的一部分进行匹配。通常，请求由最具体的路径前缀匹配，并且位置指令的顺序并不重要。这里，在第3行和第8行，我们定义了两个路径前缀。在每种情况下，$ upstream变量都设置为上游块的名称，该上游块分别代表库存和定价服务的后端API服务。

此配置的目标是将API定义与管理API交付方式的策略分开。为此，我们最小化了API定义部分中显示的配置。在为每个位置确定适当的上游组之后，我们停止处理并使用指令来查找API的策略（第10行）。
使用重写指令将处理移至API策略部分

重写指令的结果是NGINX Plus搜索匹配以/ _warehouse开头的URI的位置块。第15行的位置块使用=修饰符执行完全匹配，从而加快处理速度。

在这个阶段，我们的政策部分非常简单。位置块本身标记为第16行，这意味着客户端无法直接向它发出请求。重新定义$ api_name变量以匹配API的名称，以便它在日志文件中正确显示。最后，请求被代理到API定义部分中指定的上游组，使用$ request_uri变量 - 其中包含原始请求URI，未经修改。

API定义有两种方法 - 广泛而精确。每种API最合适的方法取决于API的安全要求以及后端服务是否需要处理无效的URI。

在warehouse_api_simple.conf中，我们通过在第3行和第8行定义URI前缀来使用Warehouse API的广泛方法。这意味着以任一前缀开头的任何URI都代理到相应的后端服务。使用基于前缀的位置匹配，对以下URI的API请求都是有效的：

如果唯一的考虑是将每个请求代理到正确的后端服务，则广泛的方法提供最快的处理和最紧凑的配置。另一方面，精确的方法使API网关能够通过显式定义每个可用API资源的URI路径来理解API的完整URI空间。采用精确的方法，Warehouse API的以下配置使用精确匹配（=）和正则表达式（〜）的组合来定义每个URI。

此配置更详细，但更准确地描述了后端服务实现的资源。这具有保护后端服务免于格式错误的客户端请求的优点，代价是正常表达式匹配的一些小额外开销。有了这个配置，NGINX Plus接受一些URI并拒绝其他URI无效：
使用精确的API定义，现有的API文档格式可以驱动API网关的配置。可以从OpenAPI规范（以前称为Swagger）自动化NGINX Plus API定义。此博客文章的Gists中提供了用于此目的的示例脚本。

随着API的发展，有时会发生需要更新客户端的重大更改。一个这样的示例是重命名或移动API资源。与Web浏览器不同，API网关无法向其客户端发送命名新位置的重定向（代码301）。幸运的是，当修改API客户端不切实际时，我们可以动态地重写客户端请求。

在下面的示例中，我们可以在第3行看到定价服务以前是作为库存服务的一部分实现的：rewrite指令将对旧定价资源的请求转换为新的定价服务。

动态重写URI意味着当我们最终在第26行代理请求时，我们不能再使用$ request_uri变量（正如我们在warehouse_api_simple.conf的第21行所做的那样）。这意味着我们需要在API定义部分的第9行和第14行使用稍微不同的重写指令，以便在处理切换到策略部分时保留URI。
HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。

顶级API网关配置包括一个定义如何处理错误响应的部分。

第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。此（可选）行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。

第28行指的是后端服务本身产生的错误。未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。此配置通过向客户端发送标准化错误来进一步提供保护。

完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。

有了这种配置，客户端对无效URI的请求就会收到以下响应。

在没有某种形式的身份验证的情况下发布API以保护它们是不常见的。 NGINX Plus提供了几种保护API和验证API客户端的方法。有关基于IP地址的访问控制列表（ACL），数字证书身份验证和HTTP基本身份验证的信息，请参阅文档。在这里，我们专注于API特定的身份验证方法。

API密钥身份验证

API密钥是客户端和API网关已知的共享密钥。它们本质上是作为长期凭证发布给API客户端的长而复杂的密码。创建API密钥很简单 - 只需编码一个随机数，如本例所示。

在顶级API网关配置文件api_gateway.conf的第6行，我们包含一个名为api_keys.conf的文件，其中包含每个API客户端的API密钥，由客户端名称或其他描述标识。

API密钥在块中定义。 map指令有两个参数。第一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕获的客户端请求的apikey HTTP头。第二个参数创建一个新变量（$ api_client_name）并将其设置为第一个参数与键匹配的行上的第二个参数的值。

例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。此变量可用于检查经过身份验证的客户端，并包含在日志条目中以进行更详细的审核。

地图块的格式很简单，易于集成到自动化工作流程中，从现有的凭证存储生成api_keys.conf文件。 API密钥身份验证由每个API的策略部分强制执行。

客户端应在apikey HTTP头中显示其API密钥。如果此标头丢失或为空（第20行），我们发送401响应以告知客户端需要进行身份验证。第23行处理API键与地图块中的任何键都不匹配的情况 - 在这种情况下，api_keys.conf第2行的默认参数将$ api_client_name设置为空字符串 - 我们发送403响应告诉身份验证失败的客户端。

有了这个配置，Warehouse API现在可以实现API密钥身份验证。

JWT身份验证

JSON Web令牌（JWT）越来越多地用于API身份验证。原生JWT支持是NGINX Plus独有的，可以在我们的博客上验证JWT，如使用JWT和NGINX Plus验证API客户端中所述。

本系列的第一篇博客详细介绍了将NGINX Plus部署为API网关的完整解决方案。可以从我们的GitHub Gist仓库查看和下载此博客中讨论的完整文件集。本系列的下一篇博客将探讨更高级的用例，以保护后端服务免受恶意或行为不端的客户端的攻击。

原文：https://dzone.com/articles/deploying-nginx-plus-as-an-api-gateway-part-1-ngin

本文：http://pub.intelligentx.net/deploying-nginx-plus-api-gateway-part-1-nginx

讨论：请加入知识星球或者小红圈【首席架构师圈】

如何用Nginx快速搭建一个安全的微服务架构

教你如何用Nginx搭建一个安全的、快速的微服务架构
今天我们要谈论微服务以及如何使用Nginx构建一个快速的、安全的网络系统。最后，我们将向您展示一个使用Fabric模式如何非常快速和轻松地构建一个微服务的demo。
在我们探讨Fabric模式之前，我想谈一谈微服务并且从Nginx的角度来看这意味着什么。
0：56 - 大转变
微服务已经引起了应用程序架构的重大转变。
当我第一次开始构建应用程序时，他们都是差不多的。幻灯片中所展示的单体架构也象征了应用程序的构造方式。
目前存在着某种类型的虚拟机（VM），对我来说，就是通常的Java。在虚拟机中应用的功能组件以对象的形式存在，这些对象是在内存中相互通讯的，它们将来来回回处理并进行方法调用。偶尔，你会采用诸如通知等机制来接触到其他系统以便获取数据或传递信息。
有了微服务之后，应用程序如何构建的范式是完全不同的了。你的功能组件会从在同一个主机的内存中通过虚拟机相互通讯转变到部署在容器中，并且使用Restful API调用通过HTTP来相互连接。
这是非常强大的，因为它赋予了你功能隔离。它为您提供了更细粒度的可伸缩性，并且你可以获得更好地处理故障的弹性。很多情况下这是简单的事实，你只需要使用HTTP进行跨网络调用。
现在，这种方法也有一些缺点。
一件轶事

我有一个暗黑的秘密，我是一个微软的员工并且从事.Net开发已经很多年了。当我在那儿的时候，我搭建了一个他们的名为Showcase的视频发布平台。
Showcase是一个用来将微软内部发布的所有视频发布到网上的工具。人们可以观看这些视频并进行学习，比如Microsoft Word的使用提示和技巧。这是一个非常受欢迎的平台，我们有很多人使用它，并且其中很多人都会在我们发布的视频上发表评论。
Showcase从一开始就是一个.Net单体应用，随着它日益受欢迎，我们决定应该将它更换为SOA架构。转换是相对容易的。Visual Studio提供了本质上的翻转开关的能力，也就是将你的DLL调用转变为Restful API调用。随着一些小的重构，我们能够让我们的代码运行得相当好。我们也为这些评论和应用内的社区功能使用智能社区服务。
紧密的回路问题

看起来我们是SOA可行的，在我们的首次测试中，一切都工作正常，直到我们将系统切换到我们的Staging环境并开始使用生产环境数据时，我们就会看到一些严重的问题。这些问题在在页面上有很多评论。
这是一个非常受欢迎的平台，其中的一些页面已经有多达2000条评论了。当我们深入这些问题时，我们意识到这些页面需要花费一分钟进行渲染的原因是因为智能社区服务首先需要填充用户名，然后对每一个用户名都需要发起一个对于用户数据库的网络调用来获得用户详细信息并且填充在渲染页面上。这是非常低效的，需要一到两分钟来渲染页面，而在内存中进行通常只需要5到6秒钟。
缓解

当我们经历了发现和解决问题的过程后，我们最终通过一些措施来调整优化系统，比如对所有的请求进行分组。我们缓存了一些数据，最终我们优化了网络来真正的提高性能。
所以，这与微服务有什么关系呢？对的，借助于微服务，你基本上是采用SOA架构的，并且会将其放入超光速引擎中。在SOA架构中所有的对象都是包含在单个虚拟机中并且在其内部管理，在内存中相互通讯，而现在微服务中是使用HTTP进行数据交换的。
当这样做没有问题时，你会获得很好的性能和线性可伸缩性。
Nginx能够很好地与微服务工作

Nginx是一个你可以用来过渡到微服务的最佳工具之一。
关于Nginx和微服务的一些历史。我们从一开始就参与了微服务运动，还是第一个从Docker Hub下载应用的，我们的客户以及那些拥有一些世界上最大的微服务安装量的最终用户广泛地在他们的基础设施使用Nginx。
原因是Nginx很小、很快并且很可靠。
Nginx微服务参考架构

我们还致力于在Nginx内部使用微服务工作已经有一段时间了。这是一个我们已经搭建的程式化的Nginx微服务参考架构，目前正在AWS上运行。
我们拥有6个核心的微服务，它们都运行在Docker容器里。我们决定建立一个多语种的应用，所以每个容器都可以运行不同的语言，我们目前使用了Ruby、Python、PHP、Java和Node.js。
我们搭建了这个使用十二要素应用的系统，稍加修改，就会使其更好地为微服务工作从而可以替代Roku平台。稍后，我们将向您展示一个实际上运行在demo里的应用。
MRA的价值

为什么我们要建立这样一个参考的微服务架构呢？
我们建立这个参考架构是因为我们需要给我们的客户提供构建微服务的蓝图，我们也想在微服务上下文中测试Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的优势。最后，我们要确保我们对于微服务生态系统以及其可以给我们提供什么有一个深入的理解。
网络问题

让我们回到我们讨论的大转变。
从将运行在内存里并且被虚拟机管理的你的应用的所有功能组件迁移到通过网络进行工作并且相互通讯的方式，你会本质上引入一系列为了应用有效工作需要你解决的问题。
第一你需要服务发现，第二，你需要在架构中为所有不同的实例进行负载均衡，然后还有第三个，你需要操心性能和安全。
无论是好是坏，这些问题密不可分，你必须做权衡，有希望的是我们有一个可以解决所有这些问题的解决方案。
让我们更深入地看待每一个问题。
服务发现
让我们来谈谈服务发现。在单体应用中，APP引擎会管理所有的对象关系，你永远不必担心一个对象与另一个对象的相对位置，你只需要简单的调用一个方法，虚拟机会连接到对象实例，然后在调用完毕后销毁。
然后有了微服务，你需要考虑那些服务的位置。不幸的是，这不是一个普遍的标准流程。您正在使用的各种服务注册中心，无论是Zookeeper、Consul、etcd或者其它的，都会以不同的方式进行工作。在这个过程中，你需要注册你的服务，还需要能够读取这些服务在哪里并且可以被连接。
负载均衡

第二个问题是关于负载均衡的。当您拥有多个服务实例时，您希望能够轻松地连接到它们，将您的请求在它们中高效地分发，并以最快的方式执行，所以不同实例之间的负载均衡是非常重要的问题。
不幸的是，最简单形式的负载均衡是非常低效的。当你开始使用不同的更加复杂的方案做负载均衡时，它也变得更加复杂并且不易于管理。理想情况下，您希望您的开发人员能够基于他们的应用程序的需求决定何种负载均衡方案。例如，如果你连接到一个有状态的应用程序，你需要拥有持久化，这样可以确保你的Session信息会被保留。
安全和快速通讯

也许微服务最令人生畏的领域是性能和安全。
当在内存中运行时，一切都很快。现在，运行在网络上就会慢了一个数量级。
被安全地包含在一个系统中的信息，通常是二进制格式的，现在会被用文本格式在网络上传输。现在是比较容易在网络上布置嗅探器并能够监听你的应用正在被移动的所有数据。
如果要在传输层加密数据，那么会在连接速率和CPU使用率方面引入显著的开销。SSL/TLS在其全面实施阶段需要九个步骤来初始化一个请求。当你的系统每天需要处理成千上万、几万、数十万或数百万的请求时，这就成为性能的一个重要障碍了。
一个解决方案

我们已经在Nginx开发的一些解决方案，我们认为，会解决所有的这些问题，它赋予你健壮的服务发现、非常棒的用户可配置负载均衡以及安全和快速加密。
网络架构

让我们来谈谈你可以安装和配置你的网络架构的各种方法。
我们提出了三种网络模型，它们本身并不相互排斥，但我们认为它们属于多种格式的。这三种模式是Proxy模式、Router Mesh模式和Fabric模式——这是最复杂的，并在许多方面在其头部进行负载均衡。
Proxy模式

Proxy模式完全聚焦于你的微服务应用的入站流量，并且事实上忽略内部通讯。
你会获得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS终止、流量整形和安全，并且借助于最新版本的Nginx Plus和ModSecurity，你可以获得WAF能力。
你也可以缓存，你可以将Nginx提供给你的单体应用的所有东西添加到你的微服务系统里，并且借助于Nginx Plus，你可以实现服务发现。当你的API实例上下浮动时，Nginx Plus可以在负载均衡工具里动态地添加和减去它们。
Router Mesh模式

Router Mesh模式类似于Proxy模式，在其中我们有一个前端代理服务来管理接入流量，但它也在服务之间添加了集中式的负载均衡。
每个服务连接到集中式的Router Mesh，它管理不同服务之间的连接分发。Router Mesh模式还允许你在熔断器模式中搭建，以便可以对你的应用添加弹性并允许你采取措施来监控和拉回你的失效的服务实例。
不幸的是，因为该模式增加了一个额外的环节，如果你不得不进行SSL/TLS加密，它事实上加剧了性能问题。这就是引入Fabric模式的原因。
Fabric模式

Fabric模式是将其头部的所有东西翻转的模式。
就像之前的另外两个模式一样，在前面会有一个代理服务器来管理流入流量，但与Router Mesh模式不同的地方就是你用运行在每个容器里的Nginx Plus来替代了集中式的Router。
这个Nginx Plus实例对于所有的HTTP流量作为反向和正向代理，使用这个系统，你可以获得服务发现、健壮的负载均衡和最重要的高性能加密网络。
我们将探讨这是如何发生的，以及我们如何处理这项工作。让我们先来看看一个服务如何连接和分发他们的请求结构的正常流程。
正常的流程

在这个图中，你可以看到投资管理器需要跟用户管理器通讯来获取信息。投资管理器创建了一个HTTP客户端，该客户端针对服务注册中心发起了一个DNS请求并获得返回的一个IP地址，接着初始化了一个到用户管理器的SSL/TLS连接，该连接需要通过九阶段的协商或者是”握手”过程。一旦数据传输完毕，虚拟机会关闭连接并进行HTTP客户端的垃圾回收。
整个过程就是这样。这是相当简单和易于理解的。当你把它分解成这些步骤时，您可以看到该模式是如何真正完成请求和响应过程的。
在Fabric模式中，我们已经改变了这一点。
Fabric模式的细节

你会注意到的第一件事是Nginx Plus是运行在每一个服务里的，并且应用程序代码是在本地与Nginx Plus通信的。因为这些是本地连接，你不需要担心加密问题。它们可以是从Java或者PHP代码到Nginx Plus实例的HTTP请求，并且都是在容器内的本地HTTP请求。
你也注意到Nginx Plus会管理到服务注册中心的连接，我们有一个解析器，通过异步查询注册中心的DNS实例来获取所有的用户管理器实例，并且预先建立连接，这样当Java服务需要从用户管理器请求一些数据的时候，可以使用预先建立的连接。
持久的SSL/TLS连接

微服务之间的有状态的、持久化的并且可以加密的连接是真正的益处。
记得在第一个图中服务实例是如何通过一些流程的吧，比如创建HTTP客户端、协商SSL/TLS连接、发起请求并关闭的吗？在这里，Nginx预先建立了微服务之间的连接，并使用Keepalive特性，保持调用之间的持续连接，这样你就不必为每一个请求处理SSL/TLS协商了。
本质上，我们创建了一个迷你的从服务到服务的VPN连接。在我们最初的测试中，我们发现连接速度增加了77%。
熔断器Plus

在Fabric模式以及Router Mesh模式中，你也可以从创建和使用熔断器模式中获得好处。
本质上，您定义了一个在服务内部的活跃的健康检查，并设置缓存，以便在服务不可用的情况下保留数据，从而获得完整的熔断器功能。
所以，现在我可以确定你认为Fabirc模式听起来很酷，并且想在实际环境中跃跃欲试。

nginx的项目实战：nginx反向代理微服务端口

一、nginx环境配置我这里就不详细说明了上章节有介绍，我这里就直接上正菜了，简单介绍下conf文件配置。

cd /etc/nginx/conf.d 

vim app.conf

upstream   app{                                                                          #upstream 的命名必须区分

    server 192.168.0.2:8088;

    server 192.168.0.1:8088;                                                    #不做集群填写单个就行，最好为内网

}                                                                                                   

server {

        listen 80;

        listen 443 ssl;

client_max_body_size 50M;

client_body_buffer_size 30M;

    server_name app.com;                                                            #域名

    root /404;

    #index index.html index.htm;

    ssl_certificate  /etc/nginx/cert/6093394_app.com.pem;

      ssl_certificate_key  /etc/nginx/cert/6093394_api.app.com.key;          #证书路径 ssl_session_timeout 5m;

  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;

      ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

      ssl_prefer_server_ciphers on;

      access_log                /opt/nginx-log/app.access.log    main;

    error_log                  /opt/nginx-log/app.error.log      notice;

        set $corsHost "";

if ($http_origin ~* "^https://a.com"){

                set $corsHost $http_origin;                                #跨域配置，比如当a.com

                                                                                              需要调用app.com

                                                                                              代理的接口必须配置，

                                                                                                可配置多个 

        }

  location / {

      client_body_buffer_size 30M;

        if ($request_method = 'OPTIONS') {

                  add_header 'Access-Control-Allow-Origin' '$corsHost';

          add_header 'Access-Control-Allow-Credentials' 'true';

          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

          return 204；

          add_header 'Access-Control-Allow-Headers' 'origin, accept, authorization, if-match, if-unmodified-since, dnt, x-mx-reqtoken, keep-alive, user-agent, x-requested-with, cache-control, content-type,languagecode,F-Token';

        proxy_next_upstream http_500 http_502 http_503 http_504 timeout error invalid_header;

        proxy_pass                http://app;                      #和upstream命名的必须一样

                proxy_set_header  Host  $host;

                proxy_set_header  Referer $http_referer;

                proxy_set_header  Cookie $http_cookie;

                proxy_set_header  X-Real-IP  $remote_addr;

                proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;

    }

...

#的后面的提示需要认真看都是需要根据自己的配置进行修改的

23 nginx 和zuul 的区别

Nginx 与Zuul的区别；
相同点：
Zuul和nginx 都可以实现负载均衡。反向代理，过滤请求，实现网关效果；
不同点：
Nginx 采用C 语言编写；
Zuul采用java 语言编写：
ZUul 负载均衡的实现： 采用ribbon+eureka实现本地负载均衡；
Nginx 负载均衡实现： 采用服务器端实现负载均衡。
Nginx比zuul 功能会强大点因为nginx可以整合一些脚本语言（nginx+lua）

nginx适合于服务器端负载均衡，也可以实现网关
ZUUL适合微服务中实现网关，而且使用技术是java 语言

最好建议nginx+zuul实现网关
nginx作用实现反向代理
Zuul 对微服务实现网关拦截

微服务网关层

API网关是所有客户端的统一入口。路由服务可以被用于很多目的，例如日志、限流、认证，从而做到应用无感知。API网关对于任意一种处理请求有两种方式处理。一部分请求只要简单路由到相应的服务；还有一些请求需要拆分到多个服务。API Gateway是实现微服务重要的组件之一，常用的网关Zuul, Nginx, Spring Cloud, Linkerd，Envoy，UnderTow。

为了评估API网关各自的性能，我们使用Apache的ab作为压测工具。（另外还可以用Gatling做性能测试）

测试结果和心得如下： 关于用nginx做微服务网关和nginx和微服务的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 用nginx做微服务网关的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于nginx和微服务、用nginx做微服务网关的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。