api 网关反向代理（反向代理http）

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

本文目录一览：

• 1、「微服务架构」部署NGINX Plus作为API网关，第1部分 - NGINX
• 2、Go - Micro微服务框架实践 - API（十三）
• 3、什么是 微服务
• 4、getway不校验白名单怎么设置
• 5、国信证券Zebra微服务架构简介
• 6、Uber实时推送平台是如何打造的

「微服务架构」部署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

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

Go - Micro微服务框架实践 - API（十三）

Micro的api就是api网关

API参考了 API网关模式 为服务提供了一个单一的公共入口。基于服务发现api 网关反向代理，使得micro api可以提供具备http及动态路由的服务。

Micro的API基于HTTP协议。请求的API接口通过HTTP协议访问api 网关反向代理，并且路由是基于服务发现机制向下转发的。 Micro API在 go-micro 之上开发api 网关反向代理，所以它集成了服务发现、负载均衡、编码及基于RPC的通信。

因为micro api内部使用了go-microapi 网关反向代理，所以它自身也是可插拔的。 参考 go-plugins 了解对gRPC、kubernetes、etcd、nats、及rabbitmq等支持。另外，api也使用了 go-api ，这样，接口handler也是可以配置的。

ACME（ Automatic Certificate Management Environment）是由 Let’s Encrypt 制定的安全协议。

可以选择是否配置白名单

API服务支持TLS证书

API使用带分隔符的命名空间来在逻辑上区分后台服务及公开的服务。命名空间及http请求路径会用于解析服务名与方法，比如 GET /foo HTTP/1.1 会被路由到 go.micro.api.foo 服务上。

API默认的命名空间是 go.micro.api ，当然，也可以修改：

我们演示一个3层的服务架构：

完整示例可以参考： examples/greeter

先决条件：我们使用Consul作为默认的服务发现，所以请先确定它已经安装好了，并且已经运行，比如执行 consul agent -dev 这样子方式运行。

向micro api发起http请求

HTTP请求的路径 /greeter/say/hello 会被路由到服务 go.micro.api.greeter 的方法 Say.Hello 上。

绕开api服务并且直接通过rpc调用：

使用JSON的方式执行同一请求：

micro api提供下面类型的http api接口

请看下面的例子

Handler负责持有并管理HTTP请求路由。

默认的handler使用从注册中心获取的端口元数据来决定指向服务的路由，如果路由不匹配，就会回退到使用”rpc” hander。在注册时，可以通过 go-api 来配置路由。

API有如下方法可以配置请求handler：

通过 /rpc 入口可以绕开handler处理器。

API处理器接收任何的HTTP请求，并且向前转发指定格式的RPC请求。

RPC处理器接收json或protobuf格式的HTTP POST请求，然后向前转成RPC请求。

代理Handler其实是内置在服务发现中的反向代理服务。

事件处理器使用go-micro的broker代理接收http请求并把请求作为消息传到消息总线上。

Web处理器是，它是内置在服务发现中的HTTP反向代理服务，支持web socket。

/rpc 端点允许绕过主handler，然后与任何服务直接会话。

示例：

更多信息查看可运行的示例： github.com/micro/examples/api

解析器，Micro使用命名空间与HTTP请求路径来动态路由到具体的服务。

API命名的空间是 go.micro.api 。可以通过指令 --namespace 或者环境变量 MICRO_NAMESPACE= 设置命名空间。

下面说一下解析器是如何使用的：

RPC解析器示例中的RPC服务有名称与方法，分别是 go.micro.api.greeter ， Greeter.Hello 。

URL会被解析成以下几部分：

带版本号的API URL也可以很容易定位到具体的服务：

代理解析器只处理服务名，所以处理方案和RPC解析器有点不太一样。

URL会被解析成以下几部分：

什么是 微服务

微服务架构是一种方法，其中单个应用程序由许多松散耦合且可独立部署的较小服务组成。

微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

这些服务通常

虽然关于微服务的大部分讨论都围绕架构定义和特征展开，但它们的价值可以通过相当简单的业务和组织优势来更普遍地理解：

微服务也可以通过它们 不是 什么来理解。

与微服务架构最常进行的两个比较是单体架构和面向服务的架构 (SOA)。

微服务和单体架构之间的区别在于，微服务由许多较小的、松散耦合的服务组成一个应用程序，而不是大型、紧密耦合的应用程序的单体方法

微服务和 SOA 之间的区别可能不太清楚。

虽然可以在微服务和 SOA 之间进行技术对比，尤其是围绕 企业服务总线 (ESB) 的角色，但更容易将差异视为 范围之一 。

SOA 是企业范围内的一项努力，旨在标准化 组织中 所有 Web 服务相互通信和集成的方式，而微服务架构是特定于应用程序的。

微服务可能至少与开发人员一样受高管和项目负责人的欢迎。

这是微服务更不寻常的特征之一，因为架构热情通常是为软件开发团队保留的。

原因是微服务更好地反映了许多业务领导者希望构建和运行他们的团队和开发流程的方式。

换句话说，微服务是一种架构模型，可以更好地促进所需的操作模型。

在IBM 最近对 1,200 多名开发人员和 IT 主管进行的一项调查中，87% 的微服务用户同意微服务的采用是值得的。

也许微服务最重要的一个特点是，由于服务更小并且可以独立部署，它不再需要国会的法案来更改一行代码或在应用程序中添加新功能。

微服务向组织承诺提供一种解毒剂，以解决与需要大量时间的小改动相关的内心挫败感。

它不需要博士学位。

在计算机科学中看到或理解一种更好地促进速度和敏捷性的方法的价值。

但速度并不是以这种方式设计服务的唯一价值。

一种常见的新兴组织模型是围绕业务问题、服务或产品将跨职能团队聚集在一起。

微服务模型完全符合这一趋势，因为它使组织能够围绕一个服务或一组服务创建小型、跨职能的团队，并让他们以敏捷的方式运行。

微服务的松散耦合还为应用程序建立了一定程度的故障隔离和更好的弹性。

服务的小规模，加上清晰的边界和沟通模式，使新团队成员更容易理解代码库并快速为其做出贡献——在速度和员工士气方面都有明显的好处。
在传统的 n 层架构模式中，应用程序通常共享一个公共堆栈，其中一个大型关系数据库支持整个应用程序。

这种方法有几个明显的缺点——其中最重要的是应用程序的每个组件都必须共享一个公共堆栈、数据模型和数据库，即使对于某些元素的工作有一个清晰、更好的工具。

它造成了糟糕的架构，并且对于那些不断意识到构建这些组件的更好、更有效的方法是可用的开发人员来说是令人沮丧的。

相比之下，在微服务模型中，组件是独立部署的，并通过 REST、事件流和消息代理的某种组合进行通信——因此每个单独服务的堆栈都可以针对该服务进行优化。

技术一直在变化，由多个较小的服务组成的应用程序更容易和更便宜地随着更理想的技术发展而变得可用。
使用微服务，可以单独部署单个服务，但也可以单独扩展它们。由此产生的好处是显而易见的：如果做得正确，微服务比单体应用程序需要更少的基础设施，因为它们只支持对需要它的组件进行精确扩展，而不是在单体应用程序的情况下对整个应用程序进行扩展。
微服务的显着优势伴随着重大挑战。

从单体架构到微服务意味着更多的管理复杂性——更多的服务，由更多的团队创建，部署在更多的地方。

一项服务中的问题可能会导致或由其他服务中的问题引起。

日志数据（用于监控和解决问题）更加庞大，并且在服务之间可能不一致。

新版本可能会导致向后兼容性问题。

应用程序涉及更多的网络连接，这意味着出现延迟和连接问题的机会更多。

DevOps 方法可以解决其中的许多问题，但 DevOps 的采用也有其自身的挑战。

然而，这些挑战并没有阻止非采用者采用微服务——或者采用者深化他们的微服务承诺。

新的 IBM 调查数据 显示，56% 的当前非用户可能或非常可能在未来两年内采用微服务，78% 的当前微服务用户可能会增加他们在微服务上投入的时间、金钱和精力

微服务架构通常被描述为针对 DevOps 和持续集成/持续交付 (CI/CD) 进行了优化，在可以频繁部署的小型服务的上下文中，原因很容易理解。

但另一种看待微服务和 DevOps 之间关系的方式是，微服务架构实际上 需要 DevOps 才能成功。

虽然单体应用程序具有本文前面讨论过的一系列缺点，但它们的好处是它不是一个具有多个移动部件和独立技术堆栈的复杂分布式系统。

相比之下，鉴于微服务带来的复杂性、移动部件和依赖项的大量增加，在部署、监控和生命周期自动化方面没有大量投资的情况下使用微服务是不明智的。

虽然几乎任何现代工具或语言都可以在微服务架构中使用，但有一些核心工具已成为微服务必不可少的边界定义：

微服务的关键要素之一是它通常非常小。

（没有任意数量的代码可以确定某物是否是微服务，但名称中的“微”就在那里。）

当Docker在 2013 年迎来现代容器时代时，它还引入了与微服务最密切相关的计算模型。

由于单个容器没有自己的操作系统的开销，它们比传统的虚拟机更小更轻，并且可以更快地启动和关闭，使其成为微服务架构中更小、更轻的服务的完美匹配.

随着服务和容器的激增，编排和管理大量容器很快成为关键挑战之一。

Kubernetes是一个开源容器编排平台，已成为最受欢迎的编排解决方案之一，因为它做得非常好。

微服务通常通过 API 进行通信，尤其是在首次建立状态时。

虽然客户端和服务确实可以直接相互通信，但 API 网关通常是一个有用的中间层，尤其是当应用程序中的服务数量随着时间的推移而增长时。

API 网关通过路由请求、跨多个服务扇出请求以及提供额外的安全性和身份验证来充当客户端的反向代理。

有多种技术可用于实现 API 网关，包括 API 管理平台，但如果使用容器和 Kubernetes 实现微服务架构，则网关通常使用 Ingress 或最近的Istio 来实现。
虽然最佳实践可能是设计无状态服务，但状态仍然存在，服务需要了解它。

虽然 API 调用通常是为给定服务初始建立状态的有效方式，但它并不是保持最新状态的特别有效方式。

不断的轮询，“我们到了吗？” 保持服务最新的方法根本不切实际。

相反，有必要将建立状态的 API 调用与消息传递或事件流结合起来，以便服务可以广播状态的变化，而其他相关方可以监听这些变化并进行相应的调整。

这项工作可能最适合通用消息代理，但在某些情况下，事件流平台（例如Apache Kafka）可能更适合。

通过将微服务与事件驱动架构相结合，开发人员可以构建分布式、高度可扩展、容错和可扩展的系统，可以实时消费和处理大量事件或信息。
无服务器架构将一些核心云和微服务模式得出其合乎逻辑的结论。

在无服务器的情况下，执行单元不仅仅是一个小服务，而是一个函数，它通常可以只是几行代码。

将无服务器功能与微服务分开的界限很模糊，但通常认为功能比微服务还要小。

无服务器架构和功能即服务 (FaaS)平台与微服务的相似之处在于，它们都对创建更小的部署单元和根据需求精确扩展感兴趣。

微服务不一定与云计算完全相关，但它们如此频繁地结合在一起有几个重要原因——这些原因超越了微服务成为新应用程序的流行架构风格以及云成为新应用程序的流行托管目的地的原因。

微服务架构的主要优势之一是与单独部署和扩展组件相关的利用率和成本优势。

虽然这些优势在一定程度上仍然存在于本地基础设施中，但小型、独立可扩展的组件与按需、按使用付费的基础设施相结合是可以找到真正成本优化的地方。

其次，也许更重要的是，微服务的另一个主要好处是每个单独的组件都可以采用最适合其特定工作的堆栈。

当您自己管理堆栈扩散时，可能会导致严重的复杂性和开销，但是将支持堆栈作为云服务使用可以大大减少管理挑战。

换句话说，虽然推出自己的微服务基础设施并非不可能，但不可取，尤其是刚开始时。

在微服务架构中，有许多常见且有用的设计、通信和集成模式有助于解决一些更常见的挑战和机遇，包括：

例如，在桌面上使用的应用程序将具有与移动设备不同的屏幕尺寸、显示和性能限制。

BFF 模式允许开发人员使用该界面的最佳选项为每个用户界面创建和支持一种后端类型，而不是尝试支持适用于任何界面但可能会对前端性能产生负面影响的通用后端。
例如，在电子商务网站上，产品对象可能通过产品名称、类型和价格来区分。

聚合是应被视为一个单元的相关实体的集合。

因此，对于电子商务网站，订单将是买家订购的产品（实体）的集合（集合）。

这些模式用于以有意义的方式对数据进行分类。
在微服务架构中，服务实例会因伸缩、升级、服务故障甚至服务终止而动态变化。

这些模式提供了发现机制来应对这种短暂性。

负载平衡可以通过使用 健康 检查和服务故障作为重新平衡流量的触发器来使用服务发现模式。
适配器模式的目的是帮助翻译不兼容的类或对象之间的关系。

依赖第三方 API 的应用程序可能需要使用适配器模式来确保应用程序和 API 可以通信。
这个色彩缤纷的名字指的是藤蔓（微服务）如何随着时间的推移慢慢地超越并扼杀一棵树（单体应用程序）。

虽然有很多模式可以很好地完成微服务，但同样数量的模式可以很快让任何开发团队陷入困境。

其中一些——改写为微服务“不要”——如下：

一旦应用程序变得太大且难以轻松更新和维护，微服务是一种管理复杂性的方法。

只有当您感觉到单体架构的痛苦和复杂性开始蔓延时，才值得考虑如何将该应用程序重构为更小的服务。

在你感受到那种痛苦之前，你甚至没有真正拥有需要重构的单体。
尝试在没有 a) 适当的部署和监控自动化或 b) 托管云服务来支持您现在庞大的异构基础设施的情况下进行微服务，会带来很多不必要的麻烦。

省去你自己的麻烦，这样你就可以把时间花在担心状态上。
最好倾向于更大的服务，然后只在它们开始开发微服务解决的特征时才将它们分开——即部署更改变得困难和缓慢，通用数据模型变得过于复杂，或者不同部分服务有不同的负载/规模要求。
微服务和 SOA 之间的区别在于，微服务项目通常涉及重构应用程序以便更易于管理，而 SOA 关注的是改变 IT 服务在企业范围内的工作方式。

一个演变成 SOA 项目的微服务项目可能会因自身的重量而崩溃。
你最好从一个你可以处理的速度开始，避免复杂性，并尽可能多地使用现成的工具。

getway不校验白名单怎么设置


lovenuo1314 
码龄11年
关注
1、若依后端gateway模块配置白名单
顾名思义，就是允许访问的地址。且无需登录就能访问。在ignore中设置whites，表示允许匿名访问。
1.1、在nacos中gateway配置文件中配置

1.2、代码
package com.ruoyi.gateway.filter;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import com.ruoyi.common.core.constant.CacheConstants;
import com.ruoyi.common.core.constant.HttpStatus;
import com.ruoyi.common.core.constant.SecurityConstants;
import com.ruoyi.common.core.constant.TokenConstants;
import com.ruoyi.common.core.utils.JwtUtils;
import com.ruoyi.common.core.utils.ServletUtils;
import com.ruoyi.common.core.utils.StringUtils;
import com.ruoyi.common.redis.service.RedisService;
import com.ruoyi.gateway.config.properties.IgnoreWhiteProperties;
import io.jsonwebtoken.Claims;
import reactor.core.publisher.Mono;
/**
* 网关鉴权
*
* @author ruoyi
*/
@Component
public class AuthFilter implements GlobalFilter, Ordered
{
private static final Logger log = LoggerFactory.getLogger(AuthFilter.class);
// 排除过滤的 uri 地址，nacos自行添加
@Autowired
private IgnoreWhiteProperties ignoreWhite;
@Autowired
private RedisService redisService;
@Override
public Mono<Void filter(ServerWebExchange exchange, GatewayFilterChain chain)
{
ServerHttpRequest request = exchange.getRequest();
ServerHttpRequest.Builder mutate = request.mutate();
String url = request.getURI().getPath();
// 跳过不需要验证的路径
if (StringUtils.matches(url, ignoreWhite.getWhites()))
{
return chain.filter(exchange);
}
String token = getToken(request);
if (StringUtils.isEmpty(token))
{
return unauthorizedResponse(exchange, "令牌不能为空");
}
Claims claims = JwtUtils.parseToken(token);
if (claims == null)
{
return unauthorizedResponse(exchange, "令牌已过期或验证不正确！");
}
String userkey = JwtUtils.getUserKey(claims);
boolean islogin = redisService.hasKey(getTokenKey(userkey));
if (!islogin)
{
return unauthorizedResponse(exchange, "登录状态已过期");
}
String userid = JwtUtils.getUserId(claims);
String username = JwtUtils.getUserName(claims);
if (StringUtils.isEmpty(userid) || StringUtils.isEmpty(username))
{
return unauthorizedResponse(exchange, "令牌验证失败");
}
// 设置用户信息到请求
addHeader(mutate, SecurityConstants.USER_KEY, userkey);
addHeader(mutate, SecurityConstants.DETAILS_USER_ID, userid);
addHeader(mutate, SecurityConstants.DETAILS_USERNAME, username);
// 内部请求来源参数清除
removeHeader(mutate, SecurityConstants.FROM_SOURCE);
return chain.filter(exchange.mutate().request(mutate.build()).build());
}
private void addHeader(ServerHttpRequest.Builder mutate, String name, Object value)
{
if (value == null)
{
return;
}
String valueStr = value.toString();
String valueEncode = ServletUtils.urlEncode(valueStr);
mutate.header(name, valueEncode);
}
private void removeHeader(ServerHttpRequest.Builder mutate, String name)
{
mutate.headers(httpHeaders - httpHeaders.remove(name)).build();
}
private Mono<Void unauthorizedResponse(ServerWebExchange exchange, String msg)
{
log.error("[鉴权异常处理]请求路径:{}", exchange.getRequest().getPath());
return ServletUtils.webFluxResponseWriter(exchange.getResponse(), msg, HttpStatus.UNAUTHORIZED);
}
/**
* 获取缓存key
*/
private String getTokenKey(String token)
{
return CacheConstants.LOGIN_TOKEN_KEY + token;
}
/**
* 获取请求token
*/
private String getToken(ServerHttpRequest request)
{
String token = request.getHeaders().getFirst(TokenConstants.AUTHENTICATION);
// 如果前端设置了令牌前缀，则裁剪掉前缀
if (StringUtils.isNotEmpty(token) token.startsWith(TokenConstants.PREFIX))
{
token = token.replaceFirst(TokenConstants.PREFIX, StringUtils.EMPTY);
}
return token;
}
@Override
public int getOrder()
{
return -200;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
package com.ruoyi.gateway.config.properties;
import java.util.ArrayList;
import java.util.List;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.context.annotation.Configuration;
/**
* 放行白名单配置
*
* @author ruoyi
*/
@Configuration
@RefreshScope
@ConfigurationProperties(prefix = "security.ignore")
public class IgnoreWhiteProperties
{
/**
* 放行白名单配置，网关不校验此处的白名单
*/
private List<String whites = new ArrayList<();
public List<String getWhites()
{
return whites;
}
public void setWhites(List<String whites)
{
this.whites = whites;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
启动代码并测试

已经走到了sytem模块中，并且没有进行登录；说明我们的配置已经生效
文章知识点与官方知识档案匹配
Java技能树首页概览
84637 人正在系统学习中
打开CSDN，阅读体验更佳
Amazon API Gateway使用IP白名单控制后端服务访问_亚林瓜子的博客-CSD...
异地IP验证 使用移动IP调用,请求被拒绝了。 白名单IP验证 同样的请求,在白名单中的IP就可以正常请求。 总结 这里使用的AWS中国北京地区的API Gateway服务,通过策略控制对后台服务的访问控制。
SpringCloud Gateway网关配置(二)接口访问IP白名单配置(真实IP)
SpringCloud Gateway网关配置中,需要对访问的IP设置白名单,SpringCloud Gateway官方给出YML配置文件配置。 如下: 5.10. The RemoteAddr Route Predicate Factory The RemoteAddr route predicate factory takes a list (min size 1) of so...
Spring Cloud Gateway 网关实现白名单功能
对于微服务后台而言，网关层作为所有网络请求的入口。一般基于安全考虑，会在网关层做权限认证，但是对于一些例如登录、注册等接口以及一些资源数据，这些是不需要有认证信息，因此需要在网关层设计一个白名单的功能。本文将基于 Spring Cloud Gateway 2.X 实现白名单功能。注意事项: Gateway 网关层的白名单实现原理是在过滤器内判断请求地址是否符合白名单，如果通过则跳过当前过滤器。如果有多个过滤器，则需要在每一个过滤器里边添加白名单判断。......
继续访问
若依vue分离版（ruoyi-vue）跳过token验证，设置白名单
找到SecurityConfig类的configure方法 如图所示 在设置白名单后还需要把接口上的权限标识符去掉。然后需要重启一下项目，热加载不行，会报错。
继续访问

Kong Gateway - 13 基于网关服务的IP白名单限制访问(Whitelist IP Restri...
为名称为book的服务的路由{route_id启用IP白名单限制访问其中192.168.10.50表示限制macOS系统这一台计算机不能访问book服务的路由其中192.168.43.0/24表示限制IP地址是192.168.43这一整个网段的IP都不能访问book服务的路由(Windows 10在此...
服务网关:Gateway_青铜造白的博客
可以实现日志拦截、权限控制、解决跨域、限流、熔断、负载均衡,隐藏服务端的ip,黑名单与白名单拦截、授权等。 二:gateway的核心概念 1、Route(路由):就是转发规则 Spring Cloud Gateway的基础元素,可简单理解成一条转发的规则。包含:ID...
SpringCloud Gateway网关配置（二）接口访问IP白名单配置（真实IP）
SpringCloud Gateway网关配置中，需要对访问的IP设置白名单，SpringCloud Gateway官方给出YML配置文件配置。 如下： 5.10. The RemoteAddr Route Predicate Factory The RemoteAddr route predicate factory takes a list (min size 1) of sources, which are CIDR-notation (IPv4 or IPv6) strings, such as 1
继续访问
nacos权限认证(二) 开启权限认证
直接设置下述属性为true，就可以避免 nacos权限认证(一) 中的问题。 这个时候再访问nacos页面，则会直接报错。因此，还需要再设置两个属性（数值可以随便填）。添加好这两个属性时页面就能正常访问了。注意：如果你遇到这种情况，只需要关闭提示，点击用户名，登出，然后重新登录即可。这个时候，如果你加修改直接启动其他服务，则其他服务无法正常连接nacos，也需要坐一番配置。需要再其他服务的配置文件中加上如下配置。 这样，其他服务就能正常连接nacos了。至此，nacos的权限漏洞问题就解决了。
继续访问

若依RuoYi-Cloud代码学习三---ruoyi-gateway扩展gateway网关组件的知识
一、API 网关概述 作为微服务的门面，应用于服务数量众多、复杂度较高、规模比较大的系统。 优点： 客户端通过 API 网关与微服务交互时，客户端只需要知道 API 网关地址即可，而不需要维护大量的服务地址，简化了客户端的开发。 客户端直接与 API 网关通信，能够减少客户端与各个服务的交互次数。 客户端与后端的服务耦合度降低。 节省流量，提高性能，提升用户体验。 API 网关还提供了安全、流控、过滤、缓存、计费以及监控等 API 管理功能。 常见API 网关实现方案 Spring Cloud G
继续访问
热门推荐 GateWay中添加白名单
最近开发中有一个鉴权的操作，最后需要进行添加白名单的，废话不多说，直接上代码吧， 这是我的项目结构 applicaton启动类： import org.springframework.boot.SpringApplication; import org.springframework.cloud.client.SpringCloudApplication; import org.spr...
继续访问

Spring Gateway+白名单+docker
域名解析 从物理机上调用外部服务正常，但是docker里的java服务去调用却有问题。 答案 docker并不能使用宿主机的host配置信息 为每一个http请求定制header 如果在RouteLocatorBuilder里设置header的话就会对所有http request生效，如果为了对每个request请求使用不同header需要如下设置 @Configuration public cl...
继续访问
GateWay网关应用案例(跨域、限流、黑白名单)
Spring Cloud Gateway是基于Spring Boot 2.x，Spring WebFlux和Project Reactor 构建的。属于异步非阻塞架构 Spring Cloud Gateway与Spring Data 和Spring Securit 技术不能同时使用 Spring Cloud Gateway基于Spring Boot和Spring Webflux提供的Netty运行。它在传统的Servlet容器中或用WAR的方式构建时不起作用 网关基本的功能 ：鉴权、流量控制、熔断、路径重写
继续访问

ruoyi分离版前端白名单
ruoyi分离版前端白名单 先在router下的index.js中加上需要添加的路由 之后再permission.js下的whiteList中加上上面添加的路由就可以了 后端的接口 接口白名单 /**是匹配路径下的所有接口，也可以直接指定某一个具体的接口 ...
继续访问
若依后端gateway模块解决跨域问题
跨域问题
继续访问

微服务项目在gateway网关配置路径访问白名单
网关的鉴权：权限身份认证作用实际上就是由一串组合起来的过滤器实现的, 过滤器的自定义过程就是实现两个接口org.springframework.cloud.gateway.filter.GlobalFilter和org.springframework.core.Ordered 通过重写org.springframework.cloud.gateway.filter.GlobalFilter中的filter方法来定义过滤的逻辑 通过重写org.springframework.core.Ordered中的get
继续访问
若依微服务SpringCloud—使用Spring Cloud Gateway网关
一.API网关 API网关，就是指系统的统一入口，它封装来应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证，鉴权，监控，路由转发等等。 二.业界流行的网关 （1)Ngnix+lua ：使用nginx的反向代理和负载均衡可实现api服务器的负载均衡及高可用。lua是一种脚步语言，可以来编写一些简单的nginx支持lua脚本。 （2）Kong：基于Nginx+Lua开发，性能高，稳定，有多个可用的插件（限流，鉴权等等）可以开箱即用。缺点：只支持http协
继续访问

最新发布 若依前后端分离ruoyi-vue请求添加白名单403
【代码】若依前后端分离ruoyi-vue请求添加白名单403。
继续访问

Nacos配置与踩坑总结
核心问题： 1.不同域名，走不同配置 2.开关、配置、JSON三种配置类型 解决方案 设计思路： 1.分三大类： 业务配置、域名配置、域名自定义配置 业务配置：用于配置所有业务中的配置信息 针对业务情况，分为三类业务配置：开关配置、基础配置、数据配置(黑/白名单) 每种配置都为单独的nacos 针对大促情况：将三类配置各自再两个环境配置，共三个环境配置，方便在不同配置环境中自由切换 域名配置：用于配置域名走哪个配置环境，实现出现问题快速将某域名切换到不同环境 域
继续访问

微服务网关springcloud gateway自定义全局过滤器
微服务网关springcloud gateway自定义全局过滤器
继续访问
ruoyi-spring boot 升级为nacos配置
springboot集成nacos
继续访问
若依Cloud之旅（二）：一次登录到出现界面，若依做了什么？
若依一次登录到出现界面的三个接口都做了什么
继续访问

实现登录验证
最近练习搭建了一个后台管理系统,首先第一步做了关于验证登录的功能.以下项目使用了Nacos作为服务发现和注册中心,将Auth和gateway,system等相关多个微服务注册进Nacos.每次刷新登录页面,就会获取新的验证码(,输入正确的验证码即可成功跳转至首页. 获取验证码url:http://localhost/dev-api/code - dev-api是前端设置的反向代理,实际访问的是网关路径和端口.即在网关gateway模块做了路由转发.返回给前端 /** * 路由转发...
继续访问
若依前后端分离-免登录
项目需要对若依进行不输入账号密码的登录，所以临时进行修改，增加获取不到token时，判断是否携带了某个特殊参数，有就用默认的账号密码调用登录达到验证登录的需求。 http://localhost/#/?index=1 // 没有token if (whiteList.indexOf(to.path) !== -1) { // 在免登录白名单，直接进入 next() } else if (to.query.index === '1') { let..
继续访问

gateway白名单
gateway

国信证券Zebra微服务架构简介

我们从0到1设计开发了国信微服务架构，他是一个完整的，从前到后的架构。我们希望逐步分享出来，后续也会将此架构开源。

1、配置依赖最小化；

2、开发速度最大化；

3、环境部署最简化；   

选用grpc,因为grpc有以下几个优势：

1、多语言支持；

2、社区活跃，生命力强，七月份发布1.5版本；

3、支持ios、Android，支持SSL和自定义鉴权（支持国密），可以简单实现客户端到后台的多路复用、rpc调用；

4、只有通信层依赖于grpc，所以容易替换；

5、grpc使用pb协议，此协议在互联网上广泛使用，生命力强；

6、支持流stream，在流的基础上实现了Server Push，方便做变更通知，不再需要客户端做费力的Long Pull；

方案基于进程内LB方案，结合分布式一致的组件etcd3，进行设计开发，具备以下功能：

1、服务自动注册；

2、服务自动发现；

3、负载均衡；

4、注册中心异常保护；

5、异常通报下发；

6、服务降级；

可视化服务管理平台，展示服务信息，包含功能如下：

1、server展示，包括ip地址、端口号、应用名称、接口名称；

2、api展示，显示proto文件内容；

3、api测试；

4、服务监控展示；

5、服务依赖动态图展示；

api网关基于vert.x实现，后期考虑采用原生netty进行升级：

1、由统一的入口来调用微服务的API；

2、API鉴权；

3、反向代理、数据剪裁、数据聚合；

4、流量控制；

5、监控报警；

6、TCP、HTTP等多协议支持；

基于springboot进行业务开发：

1、权限管理，服务接口授权；

2、服务端流量控制；

3、业务线程池管理；

4、调用端和服务端TCP连接数管理；

5、服务过载快速失败；

6、TCP心跳保活；

7、调用链分析埋点；

8、超时管理；

9、泛化调用；

参考Prometheus搭建监控中心，具有以下功能：

1、服务流量上报；

2、服务访问ip上报；

3、服务平均耗时情况上报；

4、异常上报；

5、日志收集服务；

6、调用链埋点；

对配置信息进行统一管理，可做到一次打包，各个环境都可使用，具有以下功能：

1、资源类配置与业务类配置分离；

2、作用域分离（分为四大作用域：GLOBAL、IDC、SET、NODE）；

3、配置中心异常容错；

Uber实时推送平台是如何打造的

原文：Uber’s Real-Time Push Platform

译者：LZM

Uber 建立的出行平台每天在处理全球数以百万计的打车订单。

实时打车市场是一个十分活跃的市场。一次行程包括多个参与者（乘客、司机），他们需要能在 APP 上实时查看、修改当前旅程的状态。因此，Uber 需要保证每个参与者和他们的 APP 实时同步相关信息，无论是接车时间、达到时间还是行驶路线和附近的司机。

今天，手机端呈现的功能日益丰富，而这些功能对实时信息同步的需求也逐渐增多。本文将介绍 Uber 工程团队如何把 Uber 平台信息同步机制从轮询转为基于 gRPC 的双向消息流协议。
在 Uber 后台，一个行程连接了现实世界中的乘客和司机。在行程过程中，这两个实体需要实时更新后台系统的信息。

我们思考一个场景：乘客发出打车请求，而司机在系统上等待接单。Uber 配对系统在后台自动匹配二者，向司机发送订单。到此为止，每一方（乘客、司机、后台）应该彼此同步他们的内容。

如果一个新订单带来，司机 APP 会每隔几秒轮询一次信息以及时更新订单状态。与此同时，乘客 APP 也会每隔几秒轮询一个信息来查看司机时候接单。

轮询的频率由数据改变的速率决定。对于一个大型 APP（例如 Uber APP），这个变化速率从几秒到几个小时不等，变化范围十分宽泛。

80% 的后台 API 请求都是来自客户端的轮询请求。激进的轮询策略能让 APP 的消息保持最新，但也会导致服务器资源耗尽。任何轮询过程中的 bug 都可能频繁导致后台负载显著加剧，甚至崩溃。随着需要动态实时数据的功能的增加，这个方法变得不再可行。

轮询会导致更快的电池消耗、应用程序延迟和网络级拥塞。这在城市中使用 2G/3G 网络或网络不稳定的地方尤其明显。在这些地方，应用程序每次尝试拉取信息时，都会重试多次。

随着功能增加，开发者们尝试重载轮询 API 或重建一个新的 API。在高峰期，APP 同时向多个 API 发送轮询请求。每个 API 负载数个功能。这些轮询 API 本质上成为一组分片负载 API。但是，在 API 级别上保持一致性和逻辑分离仍然是一个越来越大的挑战。

冷启动问题是其中最具挑战性的问题之一。每当 APP 启动，所有功能都希望从后台获取最新状态，以渲染用户界面。这导致多个 API 并发竞争，APP 不能成功渲染出正常界面，直到关键组件的消息被返回。在没有优先级的情况下，因为所有的 API 都有一些关键信息，所以应用加载时间会持续增加。糟糕的网络条件会进一步恶化冷启动问题。

很明显，我们需要一个彻头彻尾的、对消息同步机制的改变。我们开启了建立一个全新的实时推送平台的旅程。在这个平台上，服务器可以根据需要向应用程序发送数据。当我们采用这种新架构时，我们发现效率有显著的改进，同时也解决了不同的问题和挑战。

接下来，来看看我们对推送平台的几代改进以及该平台是如何演变的。

虽然使用消息推送是取代轮询的自然选择，但在如何构建推送机制上有很多需要考虑的问题。四个主要设计原则如下：

1）从轮询到推送的简单迁移

目前存在大量端设备在进行轮询。新系统必须利用现有的、分配给轮询 API 的负载和逻辑，而不是完全推倒重来。

2）简易开发

与开发轮询 API 相比，开发人员在推送数据方面不应该做截然不同的事情。

3）可靠性

所有消息应该通过网络可靠地发送到客户的 APP 上，并在发送失败时重试。

4）高效率

随着 Uber 在发展中国家的迅速发展，数据使用成本对我们的用户来说是一个挑战，对于每天要在 Uber 平台上呆上几个小时的司机来说尤其如此。新协议必须最小化服务器和移动应用程序之间的数据传输量。

我们将这个消息推送系统命名为 RAMEN (Realtime Asynchronous MEssaging Network，实时异步消息网络)。

任何时候，实时信息都在变化。消息的生命周期开始于决定生成一条信息的那一刻。微服务 Fireball 用于决定何时推送消息。很大部分决策都由配置文件决定。Fireball 在系统间监听多种类型的事件，并决定是否推送给该消息涉及的客户。

例如，当一个司机加单，司机和行程的状态都会改变，并触发 Fireball。之后，根据配置文件的内容，Fireball 决定何类消息应该推送给客户。通常，一个触发器会向多个用户发送多个消息。

任何事件都可能被触发器捕获，例如一些客户行为（如发出打车请求、打开 APP）、定时器到期、消息总线上的后端业务事件或是地理上的驶出 / 驶入事件。所有这些触发器都被过滤并转换为对各种后台 API 的调用。这些 API 需要客户的上下文信息，如设备定位、设备的操作系统以及 APP 的版本号，来生成一个响应。Fireball 获取设备上下文 RAMEN 服务器，并在调用 API 时将它们添加到头部。

所有来自 Uber APP 的服务器调用都由我们的 API 网关提供。推送有效负载以同样的方式生成。一旦 Fireball 决定了推送消息的对象和时间，API 网关就负责决定推送什么。网关会调用各类域服务来生成正确的推送负载。

网关中的所有 API 在如何生成有效负载方面是相似的。这些 API 分为拉取式和推送式两种。。拉取式 API 由移动设备调用来执行任何 HTTP 操作。推送 API 由 Fireball 调用，它有一个额外的 “推送” 中间件，可以拦截拉取式 API 的响应，并将其转发给推送消息系统。

将 API 网关介乎于二者之间有以下好处：

l  拉式和推式 API 共享端设备上的大部分业务逻辑。一个给定的负载可以从拉式 API 无缝切换到推式 API。例如，无论你的 APP 是通过拉式 API 调用拉出一个客户对象，还是 Fireball 通过推式 API 调用发送一个客户对象，他们都使用相同的逻辑。

l  网关负责处理大量业务逻辑，如推送消息的速率、路由和消息验证。

在适当的时候，Fireball 和网关一起生成发送给客户的推送消息。负责将这些信息传递到移动设备的是 “推送消息传递系统”。

每条消息推送会根据不同的配置执行，这些配置项包括：

1）优先级

由于为不同的用例生成了数百个不同的消息负载，因此需要对发送到 APP 的内容进行优先排序。我们将在下一节中看到，我们采用的协议限制在单个连接上发送多个并发负载。此外，接收设备的带宽是有限的。为了给人一种相对优先级的感觉，我们将信息大致分为三个不同的优先级：

l  高优先级：核心功能数据

l  中优先级：其他有助于提升客户体验的功能数据

l  低优先级：需要发送的数据规模大且使用频率不高

优先级配置用于管理平台的多种行为。例如，连接建立后，消息按照优先级降序排列在套接字（socket）中。在 RPC 失败的情况下，通过服务器端重试，高优先级消息变得更加可靠，并且支持跨区域复制。

2）存活时间

推送消息是为了改善实时体验。因此，每个消息都有一个预先定义的生存时间，从几秒到半个小时不等。消息传递系统将消息持久化并在发生错误时重试传递消息，直到有效值过期为止。

3）去重复

当通过触发器机制或重传机制多次生成相同的消息时，此配置项确定是否应该删除重复的消息推送。对于我们的大多数用例，发送给定类型的最新推送消息足以满足用户体验，这允许我们降低总体数据传输速率。

消息推送系统的最后一个组件是实际的有效负载交付服务。该服务维持着与世界各地数百万 APP 程序的活跃连接，并在它们到达时将有效信息同步。世界各地的移动网络提供了不同级别的可靠性，因此传输系统需要足够鲁棒以适应故障。我们的系统保证 “至少一次” 交货。

为了保证可靠传输，我们必须基于 TCP 协议，建立从应用程序到数据中心的持久连接。对于 2015 年的一个应用协议，我们的选择是使用带有长轮询、网络套接字或最终服务器发送事件 (SSE) 的 HTTP/1.1。

基于各种考虑，如安全性、移动 SDK 的支持和数据大小的影响，我们决定使用 SSE。Uber 已经支持了 HTTP + JSON API 栈，它的简单性和可操作性使它成为我们当时的选择。

然而，SSE 是一种单向协议，即数据只能从服务器发送到应用程序。为了提供之前提到的 “至少一次” 的保障，需要确认和重传机制以构建到应用程序协议之上的交付协议中。在 SSE 的基础上，我们定义了一个非常优雅和简单的协议方案。
客户端开始接收第一个 HTTP 请求的消息 /ramen/receive?seq=0，在任何新会话开始时序列号为 0。服务器以 HTTP 200 和 “Content-Type: text/event-stream” 响应客户端以维护 SSE 连接。接下来，服务器将按照优先级降序发送所有挂起的消息并依次递增序列号。由于底层传输协议是 TCP 协议，如果没有交付带有 seq#3 的消息，那么该连接应该已断开、超时或失败。

客户端期望在下一个看到的带有最大序列号重新连接 (在本例中 seq=2)。这就告诉了服务器，即使编号 3 写到了套接字上，它也没有被正常传递。然后服务器将重新发送相同的消息或以 seq=3 开始的任何更高优先级的消息。该协议构建了流连接所需的可恢复性，服务器负责大部分的存储工作，在客户端实现起来非常简单。

为了获知链接是否存活，服务器每 4 秒会发送一个心跳包，这类数据包大小只有一个比特。如果超过 7 秒没有收到来自服务器的消息或心跳，客户端会认定服务终端并重新发起链接。

在上面的协议中，每当客户端重新以一个更高的序列号发起连接时，它就充当服务器刷新旧消息的确认机制。在一个环境良好的网络中，用户可能会保持连接数分钟，从而导致服务器不断积累旧消息。为了缓解这个问题，应用程序会每 30 秒一次调用 /ramen/ack?seq=N，不管连接质量如何。协议的简单性允许用许多不同的语言和平台非常快速地编写客户端。

在设备上下文存储上，RAMEN 服务器在每次建立连接时存储设备上下文，并将此上下文暴露给 Fireball。每个设备上下文的 id 是用户及其设备参数对应的唯一哈希值。这允许隔离推送消息，即使用户在不同的设置下同时使用多个设备或应用程序。

第一代 RAMEN 服务器使用 Node.js 编写，并使用 Uber 内部的一致性哈西 / 分片框架 Ringpop。Ringpop 是一个去中心化的分片系统。所有连接都使用用户的 UUID 进行分片，并使用 Redis 作为持久性数据存储。

在接下来的一年半时间里，消息推送平台在整个公司得到了广泛的应用。高峰期时，RAMEN 系统通过维持高达 60 万个并发数据流连接，每秒向三种不同类型的应用程序推送超过 70000 个 QPS 消息。该系统很快成为服务器 - 客户端 API 基础结构中最重要的部分。

随着通信量和持久连接的快速增加，我们的技术选择也需要扩展。基于 Ringpop 的分布式分片是一个非常简单的架构，不会随着 ring 中的节点数量的增加而动态扩展。Ringpop 库使用一种 gossip 协议来评估成员资格。gossip 协议的收敛时间也随着环的大小增加而增加。

此外，Node.js 是单线程的，并且会有更高级别的事件循环延迟，从而进一步延迟成员信息的收敛。这些问题可能引发拓扑信息不一致，进而导致消息丢失、超时和错误。

2017 年初，我们决定重新启动 RAMEN 协议的服务器实现，以继续扩大应用规模。在这次迭代中，我们使用了以下技术：Netty、Apache Zookeeper、Apache Helix、Redis 和 Apache Cassandra。

1）Netty： Netty 是一个用于构建网络服务器和客户端的高性能库。Netty 的 bytebuf 允许零拷贝缓冲区，这使得系统非常高效。

2）Apache ZooKeeper： Apache ZooKeeper 对网络连接进行一致性哈希，可以直接传输数据，不需要任何存储层。但是与分散的拓扑管理不同，我们选择了 ZooKeeper 的集中共享。ZooKeeper 是一个非常强大的分布式同步和配置管理系统，可以快速检测连接节点的故障。

3）Apache Helix： Helix 是一个健壮的集群管理框架，运行在 ZooKeeper 之上，允许定义自定义拓扑和重新平衡算法。它还很好地从核心业务逻辑中抽象出拓扑逻辑。它使用 ZooKeeper 来监控已连接的工作者，并传播分片状态信息的变化。它还允许我们编写一个自定义的 Leader-Follower 拓扑和自定义的渐进再平衡算法。

4）Redis 和 Apache Cassandra： 当我们为多区域云架构做准备时，有必要对消息进行正确的复制和存储。Cassandra 是一个持久的跨区域复制存储。Redis 被用作 Cassandra 之上的容量缓存，以避免分片系统在部署或故障转移事件中常见的群发问题。
5）Streamgate： 这个服务在 Netty 上实现了 RAMEN 协议，并拥有所有与处理连接、消息和存储相关的逻辑。该服务还实现了一个 Apache Helix 参与者来建立与 ZooKeeper 的连接并维护心跳。

6）StreamgateFE (Streamgate Front End)： 该服务充当 Apache Helix 的旁观者，从 ZooKeeper 上侦听拓扑变化。它实现了反向代理。来自客户机 (火球、网关或移动应用程序) 的每个请求都使用拓扑信息进行分片，并路由到正确的 Streamgate 工作程序。

7）Helix Controllers： 顾名思义，这是一个 5 节点的独立服务，单独负责运行 Apache Helix Controller 进程，是拓扑管理的大脑。无论何时任何 Streamgate 节点启动或停止，它都会检测到更改并重新分配分片分区。

在过去的几年中，我们一直在使用这种架构，并且实现了 99.99% 的服务器端可靠性。我们推动基础设施的使用持续增长，支持 iOS、Android 和 Web 平台上的十多种不同类型的应用程序。我们已经使用超过 1.5M 的并发连接来操作这个系统，并且每秒推送超过 250,000 条消息。

服务器端基础设施一直保持稳定运行。随着我们为更多新城市提供各种各样的网络服务和应用程序，我们的重点将是继续提高向移动设备消息推送机制的长尾可靠性。我们一直在试验新协议、开发新方法，以弥合和现实需求的差距。在检查以往的不足时，我们发现以下方面是导致可靠性下降的原因。

1）缺乏认证

RAMEN 协议在减少数据传输进行了优化，仅在每 30 秒或客户端重新连接时才发送确认消息。这将导致延迟确认，在某些情况下无法确认消息达到，因此很难区分是真正的消息丢失还是确认失败。

2）连接不稳定

维持客户端和服务器的正常连接至关重要。跨不同平台的客户端实现方式在处理错误、超时、后退或应用生命周期事件 (打开或关闭)、网络状态更改、主机名和数据中心故障转移等方面有许多细微差别。这导致了不同版本间的性能差异。

3）传输限制

由于该协议在 SSE 协议基础上实现，因此数据传输是单向的。但是，许多新的应用程序要求我们启用双向消息传输机制。没有实时的往返行程时间测量，确定网络状况、传输速度、缓解线路阻塞都是不可能的。SSE 也是一个基于文本的协议，它限制了我们传输二进制有效负载的能力，不需要使用像 base64 这样的文本编码，从而获得更大的有效负载。

2019 年底，我们开始开发下一代 RAMEN 协议以解决上述缺点。经过大量考量，我们选择在 gRPC 的基础上进行构建。gRPC 是一个被广泛采用的 RPC 栈，具有跨多种语言的客户端和服务器的标准化实现，对许多不同的 RPC 方法提供了一流的支持，并具有与 QUIC 传输层协议的互操作性。

新的、基于 gRPC 的 RAMEN 协议扩展了以前基于 SSE 的协议，有几个关键的区别：

l  确认消息立即通过反向流发送，提高了确认的可靠性，而数据传输量几乎没有增加。

l  实时确认机制允许我们测量 RTT，了解实时的网络状况。我们可以区分真正的消息损失和网络损失。

l  在协议之上提供了抽象层，以支持流多路传输等功能。它还允许我们试验应用级网络优先级和流控制算法，从而在数据使用和通信延迟方面带来更高的效率。

l  协议对消息有效负载进行抽象，以支持不同类型的序列化。将来，我们会探索其他序列化方法，但要将 gRPC 保留在传输层。

l  不同语言的客户端实现也让我们能够快速支持不同类型的应用程序和设备。

目前，这项开发工作处于 beta 版阶段，很快就能上线。

消息推送平台是 Uber 出行体验的组成部分之一。今天有数百种功能建立在该平台的基础服务之上。我们总结了消息推送平台在 Uber 出行生态中取得巨大成功的几个关键原因。

1）职能分离

消息触发、创建和传递系统之间明确的职责分离允许我们在业务需求发生变化时将注意力转移到平台的不同部分。通过将交付组件分离到 Apache Helix 中，数据流的拓扑逻辑和核心业务逻辑被很好的区分开，这允许在完全相同的架构上使用不同的有线协议支持 gRPC。

2）行业标准技术

构建在行业标准技术之上使我们的实现更加鲁棒且低成本。上述系统的维护开销非常小。我们能够以一个非常高效的团队规模来传递平台的价值。根据我们的经验，Helix 和 Zookeeper 非常稳定。

我们可以在不同的网络条件下扩展到数百万用户的规模，支持数百个功能和几十个应用程序。该协议的简单性使其易于扩展和快速迭代。

原文:

https://eng.uber.com/real-time-push-platform/ 关于api 网关反向代理和反向代理http的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 api 网关反向代理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于反向代理http、api 网关反向代理的信息别忘了在本站进行查找喔。

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