微服务网关kong（微服务网关和注册中心）

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

本文目录一览：

• 1、Kong + nacos 微服务网关搭建
• 2、云南北大青鸟设计培训告诉你微服务架构中API网关的角色？
• 3、网关服务Kong、Konga搭建记录
• 4、Spring Cloud——微服务网关介绍
• 5、微服务网关层
• 6、Kong gateway health check配置方法

Kong + nacos 微服务网关搭建

有一个自己的项目，架构使用的是kong网关+nacos微服务体系。
kong是一个基于openresty的高性能网关，nacos是alibaba开源的微服务治理框架。
但kong不能实时地对nacos体系中的服务实例健康状态进行识别。
最近看了一些文章，找到了kong和nacos微服务体系打通方案，这次来总结一下思路。

云南北大青鸟设计培训告诉你微服务架构中API网关的角色？

“当你想到网关的时候，你通常会想到一个集中的层，一个额外的跳在网络上处理附加的功能。但这并不一定是真的，”Palladino上周在洛杉矶举行的2017年MesosCon上发表的讲话。网关还可以提供一种有效的方式来处理跨微服务之间的通信。他说：“你也可以在现有的微服务上运行Kong，摆脱额外的跳跃，减少延迟。”

在过去的10年里，大理电脑培训http://www.kmbdqn.cn/认为API一直是一种受欢迎的通信交互方式，Docker使其易于设置微服务架构，其中应用程序和服务是由较小的可交换组件组成。但这些组件之间需要一种方式进行发现与调用。这就是API网关的作用。

API网关“可以成为一个抽象层它位于这些微服务中每个请求的访问路径上，”Palladino说道。

网关巩固了通往系统常用功能的所有路径，比如身份验证或者服务发现，通过插件都能被网关识别。“插件是一种有效的中间件功能你能动态应用于所有的微服务上，”他讲到。

API网关可以聚合服务请求和这些特性。客户端可以做出一个响应，网关可以将其分解为多个请求，节省了客户端自身调用的带宽。网关同样还可以跟踪这些请求。

当一个组织开始把一个单体应用拆分为微服务时，网关可以将对客户端的影响最小化。“网关就像装载单体应用前的一个窗帘。客户端只会处理网关，而你可以在窗帘后面解耦你的单体应用，不必担心更新你的客户端，”他说道。

他说：“当你没掌控你的客户端的时候这个特别有用”。

传统上，API网关在组织网络的边缘上被使用，处理的流量大部分来自于单体应用和外部客户端之间的交互。然而微服务架构将大部分的流量转移到内部网络，因为不同的微服务之间要进行交互。“你可以有外部的客户端使用案例，但这成为了当前消费微服务的众多客户端之一。”

网关服务Kong、Konga搭建记录

使用docker-compose安装是最方便的
在/opt/目录下创建kong文件夹，然后创建一个docker-compose.yml文件并编辑

在docker-compose.yml添加如下配置（20220528亲测可用）

假设使用的是本地搭建
使用浏览器访问127.0.0.1:1337
注：端口号在docker-compose.yml中指定了1337

若是使用云服务器，注意做好DNS解析以及Nginx配置
这里给出一份可用的kong.conf

使用浏览器访问kong.YOUR_DOMAIN:1337

打开界面后，是要创建一个管理员账号的，按说明填写即可

先理解一下概念：
我们现在操作的可视化平台是Konga
Konga通过调用Kong的admin url，对Kong网关进行配置管理
所以这一步我们需要将Konga和Kong搭上线

在Connection页面配置要管理的Kong网关

主要填写参数说明：
Name：必填，唯一，用于备忘
Kong Admin URL：Kong网关的管理路径，默认端口是8001，在docker-compose.yml可修改对外暴露的端口号

这里有个提示很显眼：Kong's admin API should not be publicly exposed
故我们在云服务器部署时，都应该注意8001的这个端口不应随意暴露出去，以免发生黑客攻击风险

进入Service菜单，点击 ADD NEW SERVICE（添加新服务）
这里我们假设要代理某度的服务

主要填写参数说明：
Name：非必填，服务名称，用于备忘这是一个什么服务
Protocol：必填，填写http或https，指请求转发到该服务时，使用哪种协议
Host：必填，填写被代理的主机地址
Port：必填，填写被代理的主机的端口号，默认80

点击刚才创建的服务，点击进入Route管理界面
点击ADD ROUTE

主要填写参数说明：
Name：非必填，路由名称，用于备忘识别这是一个什么路由
Paths：这是重点！具体看效果就明白了，这边添加“/”和“/api/baidu”，注意要回车

访问服务的接口为8000（在docker-compose.yml已配置）

若使用的是本地搭建
使用浏览器访问

若是部署到云服务器，并做好了域名解析
使用浏览器访问

都会被解析Route，指向对应的Service，返回的是某度的页面，搭建成功

当同一个服务为分布式或存在多个域名、ip时，我们可以通过配置Upstream，将这些服务统一起来

进入Upstream页面
点击ADD UPSTREAM

主要填写参数说明：
Name：必填，名称，用于关联Service中Host字段

进入刚添加的Upstream的Detail
进入Target管理页
点击ADD TARGET

主要填写参数说明：
Target：该服务具体的域名+端口，注意这里默认端口8000，故需要手动写80
Weight：权重

添加好后是这个样子

之后我们回到Service配置
将Host填写为刚刚命名，并保存

之后我们再次访问

能发现不仅能访问某度，还能访问到某奇广告网（因为baidu1.com、baidu2.com并不是某度搜索）
至于每次访问结果都有变化，是因为Upstream做了权重的负载均衡，因此实际访问的服务是

Spring Cloud——微服务网关介绍

为了解决以上的问题，API网关应运而生，加入网关后应用架构变为下图所示。

当引入API网关后，在用户端与微服务之间建立了一道屏障，通过API网关对微服务提供了统一的访问入口，所有用户端的请求被API网关拦截，并在此基础上可以实现额外的功能：

OpenResty是一个强大的Web应用服务器，web开发人员可以使用Lua脚本语言调用Nginx支持的各种以C以及Lua模块。

在性能方面，OpenResty可以快速构造出足以胜任10K以上并发连接响应的超高性能Web应用系统。

在国内，360、阿里云、腾讯网、去哪儿、酷狗音乐、新浪等都是OpenResty的深度用户。

但OpenResty是一款独立的产品，与主流的注册中心，存在一定的兼容问题，需要架构师独立实现其服务注册、发现功能。

Zuul是Netflix开源的微服务网关，主要职责是对用户请求进行路由转发与过滤。早期Spring Cloud与Netflix合作，使用Zuul作为微服务架构网关首选产品。

Zuul是基于J2EE Servlet实现路由转发，网络通信采用同步方式。

zuul 是netflix开源的一个API Gateway 服务器，本质上是一个web servlet应用。

Zuul可以通过加载动态过滤机制，从而实现以下各项功能：

Zuul的核心是一系列的filters，其作用可以类比Servlet框架的Filter，或者AOP。工作原理如下图所示：

Zuul可以对Groovy过滤器进行动态的加载，编译，运行。

Zuul2.x设计更为先进，基于Netty 非阻塞和支持长连接， 但是 SpringCloud 目前没有整合。 Zuul2.x 的性能较 Zuul1.x 有较大的提升。

Zuul2.x引入了Netty和RxJava，正如之前的 ZuulFilter 分为了 Pre、Post、Route、Error，Zuul2的Filter分为三种类型：

Spring 自己开发的新一代API网关产品，基于NIO异步处理，摒弃了Zuul基于Servlet同步通信的设计。

Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。

关键特征：

在性能方面，根据官方提供的基准测试， Spring Cloud Gateway 的 RPS（每秒请求数）是Zuul 的 1.6 倍。

Spring Cloud Gateway十分优秀，Spring Cloud Alibaba也默认选用该组件作为网关产品。

客户端向 Spring Cloud Gateway 发出请求。如果 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。 过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑。

Spring Cloud Gateway 的特征：

参考：
http://www.ityouknow.com/springcloud/2018/12/12/spring-cloud-gateway-start.html

http://www.likecs.com/show-50293.html

https://zhuanlan.zhihu.com/p/299608850?utm_source=wechat_session

https://juejin.cn/post/6844903965352525838

https://blog.csdn.net/weixin_38361347/article/details/114108368

http://www.zyiz.net/tech/detail-98256.html

微服务网关层

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

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

测试结果和心得如下：

Kong gateway health check配置方法

随着微服务越来越火微服务网关kong，对于如何对微服务进行健康检查，也出现微服务网关kong了很多成熟微服务网关kong的解决方案。本文以其中应用较多的Kong gateway为例，详细讲述如何配置kong health check。

Kong有两种健康检查方法，可分别或同时使用:

active checks主动检查，其中定期请求目标中的特定HTTP或HTTPS端点，并根据其响应确定目标的健康状态;

passive checks被动检查(也称为断路器)，Kong在其中分析正在代理的流量，并根据目标的行为响应请求来确定目标的健康状况。

配置health check有两种方式，一种通过kong admin api直接配置（参考官方文档），另一种可以通过配置KongIngress的方式来实现。本文主要介绍后一种方式。
配置KongIngress:

配置完成后，可以通过kubectl get kongingress来查看。要想让这个配置生效，还需要绑定到对应service上，方法如下：

在对应service的yaml文件中增加标红部分，之后只要正常部署即可。

最后，可以通过kong admin api来查看效果：

观察到标红处为"HEALTHY"或者"UNHEALTHY"配置就生效了。如果观察到"HEALTHYCHECK_OFF"那就是配置没有生效，需要具体查看原因。 关于微服务网关kong和微服务网关和注册中心的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关kong的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关和注册中心、微服务网关kong的信息别忘了在本站进行查找喔。

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