楼凤网站怎么做的谷歌首页

25.网关Nginx负载模型配置

通过模拟多个HTTP服务配置到 Nginx 做负载均衡，以学习API网关负载的配置和使用

API 网关是用于支撑分布式 RPC 接口协议转换提供 HTTP 调用的一套服务，那么 API 网关系统就需要可横向扩展来满足系统的吞吐量诉求。所以这里需要让 API 网关来支持分布式架构部署，提供负载均衡的能力。

那么在这方面有一套非常成熟的模式就是基于 Nginx 以及 LVS、F5 相关的配置构建出负载均衡服务。在这里同样我们的 API 网关也可以被这样的方式进行处理，来满足部署需求。

负载均衡模型

首先我们知道，API网关是根据HTTP协议请求的地址转换为对应的映射泛化调用的RPC框架。这部分请求地址被配置到数据库中。如图：

wg 是一个固定开头的地址，转换后面紧跟着所访问的具体方法。在前面已经实现过 uri 映射到具体的 RPC 上。所以当我们通过在浏览器进行 HTTP 访问接口http://localhost:8090/wg/activity/sayHi 时，则会访问的到对应的网关算力节点服务上，完成对应的 RPC 调用和结果封装。

那么现在我们需要的是根据一个 URL 地址所访问路径的差异，访问到不同的 api 协议转换通信服务上，这样就可以完成一个负载调用的过程了。如图

这里我会先给大家介绍基于 Nginx 如何构建出一套负载均衡的网络请求模型，方便让更多的读者理解这样一个过程。

配置Nginx负载均衡策略

根据实际情况选择合适的负载均衡策略

1. 最基本的配置方法，它是upstream模块默认的负载均衡默认策略。每个请求会按时间顺序逐一分配到不同的后端服务器。
2. Weight：权重方式，在轮询策略的基础上指定轮询的几率。注意：

• 权重越高分配到需要处理的请求越多。
• 此策略可以与least_conn和ip_hash结合使用。
• 此策略比较适合服务器的硬件配置差别比较大的情况。

3.ip_hash：指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端的请求一直发送到相同的服务器，以保证session会话。这样每个访客都固定访问一个后端服务器，可以解决session不能跨服务器的问题。

4.least_conn：把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。

5.第三方策略：

第三方的负载均衡策略的实现需要安装第三方插件。

①fair按照服务器端的响应时间来分配请求，响应时间短的优先分配。

②url_hash 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，要配合缓存命中来使用。同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。而使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取。

26.动态刷新网关Nginx负载均衡配置

以Java程序调用Docker容器控制Nginx刷新为手段，处理服务与Docker容器间挂载的Nginx配置文件动态刷新操作。

为了满足当有新的网关算力节点注册、下线、调整时可以自动的生效Nginx配置，我们要在api-gateway-center服务中对外提供实现Nginx动态配置的接口。

核心问题:

1. 对于一个网关的算力的动态配置和刷新，要根据服务的注册动态变更Nginx配置文件并生效。那么这里就会牵扯到Nginx的配置文件变更和刷新，如何通过Java程序进行控制等问题。
2. 那么以当前服务部署到Docker容器场景为例，Docker 是嵌入到 Linux 服务器内的，每个镜像实例的部署也都是隔离的，那么这个时候该怎么完成配置文件的互通和指令调用就成了本章要解决的核心问题。

解决方案：

1. 问题1：Nginx 的配置文件如何被其他应用程序获取并修改，这里需要用到文件挂载操作。我们把存放在 Linux 服务器上的 nginx.conf 所在的文件夹📂挂在到 api-gateway-center 上，之后把 nginx.conf 配置文件挂在 Nginx 服务上。这样就打通第一个要解决的配置文件问题。之后再 api-gateway-center 服务上就可以通过 IO 流更新 nginx.conf 文件。
2. 问题2：如何通过 api-gateway-center 程序对 Nginx 进行调用。这里因为我们是在 Docker 场景下，所以需要通过 Java 控制并获取 Docker 容器中 Nginx 的服务，并对其进行操作。这里还会涉及到网络的问题，否则在容器中服务1不能调用服务2。

1. Nginx 配置服务

把存放在 Linux 服务器上的 nginx.conf 所在的文件夹📂挂在到 api-gateway-center 上.

docker run \
--name Nginx \
-d \
-v  /Users/kjz/Documents/develop/tmp/nginx/html:/usr/share/nginx/html \
-v /Users/kjz/Documents/develop/tmp/nginx/conf/nginx.conf:/etc/nginx/nginx.conf \
-p 8090:80 \
nginx

2. 刷新文件建模

实现流程分为3块，包括；文件的创建、文件的复制、文件的刷新。但鉴于我们已经通过文件的挂在到相同目录下，解决了复制Docker应用程序创建出来的 Nginx 配置文件到本地，所以这里就不需要自己在复制了。

3. 刷新文件实现

本身部署在 Docker 容器的 Nginx 文件，在刷新时候需要通过指令；docker exec Nginx nginx -s rolad 那么这里我们通过 Java 程序控制，就需要连接 Docker 容器，找到对应的服务，在执行容器指令。

27.实现网关算力节点动态负载功能

基于第25节Nginx的负载模型，第26节动态刷新Nginx的配置和实现，在本节把网关算力节点动态刷新到Nginx配置中，完成动态负载的功能实现。

方案设计

在不使用Nginx代理的时候，前面章节使用网关都是通过直接方式的方式操作，如 http://172.20.10.12:7397/wg/activity/sayHi?str=1 那么现在因为有负载的设计，希望把来自于不同URL的请求负载到不同的网关算力上去，所以这里的访问地址将变更为：http://172.20.10.12:8090/10001/wg/activity/sayHi?str=10001。

从第1个地址到第2个地址来看，变化的点主要是端口由原来的访问网关算力节点到访问Nginx，同时多了一个 10001 的路径。这个 10001 就是数据库中 group_id 网关分组的配置。我们也是用这个配置来区分访问哪一组网关。所以整体设计如图

1. api-gateway-center 管理着网关算力的注册，并把注册的配置信息动态刷新到 Nginx 配置中。
2. 同时在 Nginx 的配置中会重写URL，也就是把 10001 这个根目录路径给去掉，让它的功能只是负责路由即可，剩下的与原有直接访问网关算力不变。这样即使以后不需要做负载也可以直接访问网关算力节点。

功能实现

1. GatewayConfigManage#registerGatewayServerNode：在网关算力节点注册的时候，调用在第26章实现的动态刷新Nginx配置接口。此外注意本节新添加了Nginx路径重新配置，以及在yml配置文件中添加了 Nginx IP 的配置。
2. ConfigManageService#queryApplicationSystemRichInfo：bug 优化，null 判断字符串，改为 if (StringUtils.isEmpty(systemId)) 这样更准确。 

28.网关组件工程模块合并

通过合并网关六个模块【admin、center、core、assist、engine、sdk】到统一服务下管理，完成InfiniGate网关的多模块组装，为后续功能迭代做铺垫。

网关的这六个模块工程，主要分为3个大的部分在运行。如图所示:

1. 第一组：网关算力，由 api-gateway-core、api-gateway-assit、api-gateway-engine 组成，core 提供算力、assist 处理封装、engine 镜像打包和启动。
2. 第二组：管理中心，由 api-gateway-admin、api-gateway-center 组成，admin 后台运营、center 注册中心。
3. 第三组：接口上报，由 api-gateway-sdk 提供，它被应用系统引入，在应用系统中以注解的方式摘取应用RPC接口信息并向注册中心发送。