本文目录导航：
nginx 和uwsgi的区别与作用
在引见nginx和uwsgi的区别和作用之前咱们先引见一下几个概念 WSGI的全称是Web Server Gateway Interface（Web主机网关接口），它不是主机、python模块、框架、API或许任何软件，只是一种形容web主机（如nginx，uWSGI等主机）如何与web运行程序（如用Django、Flask框架写的程序）通讯的规范、协定。
server和application的规范在PEP3333中有详细形容，要成功WSGI协定，必定同时成功web server和web application，以后运转在WSGI协定之上的web框架有,Flask, Django。
uWSGI是一个全性能的HTTP主机，成功了WSGI协定、uwsgi协定、http协定等。
它要做的就是把HTTP协定转化成言语允许的网络协定。
比如把HTTP协定转化成WSGI协定，让Python可以间接经常使用。
与WSGI一样，是uWSGI主机的独占通讯协定，用于定义传输消息的类型。
每一个uwsgi packet前4byte为传输消息类型的形容，与WSGI协定是两种物品，听说该协定是fcgi协定的10倍快。
Nginx是一个Web主机其中的HTTP主机性能和uWSGI性能很相似，然而Nginx还可以用作更多用途，比如最罕用的反向代感性能。
1.经常使用的代理一共有两个，nginx和uwsgi，先说明一下，假设不用nginx一样可以访问web名目，经常使用nginx的目的是为了安保和负载平衡。
性能了nginx做前端代理，uwsgi作后端代理的主机(这里所说的前后端都是相对的位置，并无实践含意)，在处置来自Internet的恳求时，要先经过nginx的处置，nginx把恳求再交给uwsgi，经过uwsgi才干访问到名目自身。
2.没有nginx而只要uwsgi的主机，则是Internet恳求间接由uwsgi处置，并反应到web名目中。
nginx可以成功安保过滤，防DDOS等包全安保的操作，并且假设性能了多台主机，nginx可以保障主机的负载相对平衡。
而uwsgi则是一个web主机，成功了WSGI协定(Web Server Gateway Interface)，http协定等，它可以接纳和处置恳求，收回照应等。
所以只用uwsgi也是可以的。
nginx的作用： 1.反向代理，可以阻拦一些web攻打，包全后端的web主机 2.负载平衡，依据轮询算法，调配恳求到多节点web主机 3.缓存静态资源，放慢访问速度，监禁web主机的内存占用，专项公用 uWSGI的实用： 1.单节点主机的繁难部署 2.轻量级，好部署 参考链接：
微服务网关选型，介绍这篇
在微服务时代的浪潮中，API网关表演着至关关键的角色，它似乎系统的大门，封装外部复杂架构，提供定制化的服务接口，并整合身份验证、监控等关键性能。
其外围职责在于一致客户端与泛滥微服务之间的通讯，处置非业务逻辑，成功高效、安保的流量治理。
让咱们深化讨论几种干流的API网关选用及其特点：
作为一款熟知的高性能HTTP主机，Nginx以其Lua定制性能和异步非阻塞处置才干，能够轻松应答海量恳求。
它不只作为静态资源主机，还充任了弱小的反向代理，为API网关的角色削减了更多或许性。
Zuul，特意是Zuul2版本，仰仗其弱小的过滤器性能，如一致鉴权和灵活路由，为API网关削减了灵敏性。
虽然Zuul1曾有提前疑问，但Zuul2的异步架构优化了性能开支。
Spring Cloud Gateway提供了与Zuul1相比更低劣的性能，它与多种性能和组件无缝集成，是寻求高效处置打算的现实选用。
4. Kong：以OpenResty为基石
Kong以其高可用性和易裁减性著称，基于插件系统，能轻松成功限流、监控等内围性能。
它在少数据中心部署和跨环境允许方面体现杰出，且领有丰盛的社区资源。
Traefik：轻量且灵敏
Traefik以其智能性能和极速部署的特点，特意适宜自研微服务网关。
与Etcd联合，它能提供服务发现性能，为微服务架构带来轻量级的高效治理。
网关框架的构建可以划分为后盾治理、路由散发与协定转换，以及服务发现负载平衡三个局部，每个过程都间接相关到网关的性能和稳固性。
在协定转换模块如hal-proxy中，重点在于失掉下游机器消息，经过Client缓存池成功协定允许的多样性，Resolver模块担任耐久化服务名与主机IP的映射，并活期降级。
协定模块则担任数据的初始化转换，而衔接池技术如环形队列和原子操作则确保了并发性能的优化。
总结来说，选用API网关时，需思考性能、可保养性和高可用性等多方面要素。
Nginx的稳固性和Lua裁减性，Zuul的灵敏性，Spring Cloud Gateway的集成深度，Kong的插件生态，以及Traefik的轻量与自定义，都是值得深化掂量的选项。
在实践运行中，要依据团队的技术背景和名目需求，做出最适宜的决策。
「微服务架构」部署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性能都以主性能文件扫尾。
要读入API网关性能，咱们在的http块中减少一个指令，该指令援用蕴含网关性能的文件api_（上方的第28行）。
请留意，自动的文件经常使用include伪指令从conf.d子目录中引入基于阅读器的HTTP性能（第29行）。
本博文宽泛经常使用include指令来提高可读性并成功性能某些局部的智能化。
api_文件定义了将NGINX Plus地下为客户端的API网关的虚构主机。
此性能地下API网关在单个入口点（第13行）颁布的一切API，受第16到21行性能的TLS包全。
请留意，此性能纯正是HTTPS - 没有明文HTTP侦听器。
咱们宿愿API客户端知道正确的入口点并自动启动HTTPS衔接。
此性能是静态的 - 各个API及其后端服务的详细消息在第24行的include伪指令援用的文件中指定。
第27到30行处置日志记载自动值和失误处置，并在照应中讨论失误局部如下。
一些API可以在单个后端成功，然而出于弹性或负载平衡的要素，咱们理论希冀存在多个API。
经常使用微服务API，咱们为每个服务定义独自的后端;它们一同作为完整的API。
在这里，咱们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。
API网关颁布的一切API的一切后端API服务都在api_中定义。
这里咱们在每个块中经常使用多个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_中，咱们经过在第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_的第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_的第6行，咱们蕴含一个名为api_的文件，其中蕴含每个API客户端的API密钥，由客户端称号或其余形容标识。
API密钥在块中定义。
map指令有两个参数。
第一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕捉的客户端恳求的apikey HTTP头。
第二个参数创立一个新变量（$ api_client_name）并将其设置为第一个参数与键婚配的行上的第二个参数的值。
例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。
此变量可用于审核经过身份验证的客户端，并蕴含在日志条目中以启动更详细的审核。
地图块的格局很便捷，易于集成到智能化上班流程中，从现有的凭证存储生成api_文件。
API密钥身份验证由每个API的战略局部强迫口头。
客户端应在apikey HTTP头中显示其API密钥。
假设此标头失落或为空（第20行），咱们发送401照应以告知客户端须要启出发份验证。
第23行处置API键与地图块中的任何键都不婚配的状况 - 在这种状况下，api_第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仓库检查和下载此博客中讨论的完整文件集。
本系列的下一篇博客将讨论更初级的用例，以包全后端服务免受恶意或行为不端的客户端的攻打。
原文：本文：讨论：请参与常识星球或许小红圈【首席架构师圈】
