有一个自己的项目，架构使用的是kong网关+nacos微服务体系。kong是一个基于openresty的高性能网关，nacos是alibaba开源的微服务治理框架。但kong不能实时地对nacos体系中的服务实例健康状态进行识别。最近看了一些文章，找到了kong和nacos微服务体系打通方案，这次来总结一下思路。架构图image.png核心思路构建一个kong-nacos服务，注册在nacos微服务体系内，利用nacos-sdk监听nacos内微服务实例上下线事件。服务实例上线/下线时，获取实例的ip:port信息，调用kong-admin-api，同步更新kong的upstream-targ
有一个自己的项目，架构使用的是kong网关+nacos微服务体系。kong是一个基于openresty的高性能网关，nacos是alibaba开源的微服务治理框架。但kong不能实时地对nacos体系中的服务实例健康状态进行识别。最近看了一些文章，找到了kong和nacos微服务体系打通方案，这次来总结一下思路。架构图image.png核心思路构建一个kong-nacos服务，注册在nacos微服务体系内，利用nacos-sdk监听nacos内微服务实例上下线事件。服务实例上线/下线时，获取实例的ip:port信息，调用kong-admin-api，同步更新kong的upstream-targ
SpringCloudAlibabaNaco作为注册中心不止提供了服务注册和服务发现功能，还提供了服务可用性监测的机制。有了这机制之后，Nacos才能感知服务的健康状态，从而为服务调用者提供健康的服务实例，最终保证了业务系统能够正常的执行。两种健康检查机制Nacos中提供两种健康检查机制：客户端主动上报机制服务器端主动下探机制如何理解这两种机制呢？可以想象一个场景，你在学校的教室里面，遇到学业上的问题，或者是科目上的问题。那有什么办法让老师知道你有问题？第一种，你主动去找老师并且告诉老师你的问题和精神状态（健康状态）第二种，老师自己发现你的状态有问题，及主动询问你的问题和状态以上这两种方法和N
SpringCloudAlibabaNaco作为注册中心不止提供了服务注册和服务发现功能，还提供了服务可用性监测的机制。有了这机制之后，Nacos才能感知服务的健康状态，从而为服务调用者提供健康的服务实例，最终保证了业务系统能够正常的执行。两种健康检查机制Nacos中提供两种健康检查机制：客户端主动上报机制服务器端主动下探机制如何理解这两种机制呢？可以想象一个场景，你在学校的教室里面，遇到学业上的问题，或者是科目上的问题。那有什么办法让老师知道你有问题？第一种，你主动去找老师并且告诉老师你的问题和精神状态（健康状态）第二种，老师自己发现你的状态有问题，及主动询问你的问题和状态以上这两种方法和N
前言讲解springboot中使用。springcloud中使用（gateway、nacos中使用）。注意，只做限流讲解，同时springboot为springmvc框架。springcloud使用springwebflux框架基础环境springboot2.4.13，sentinel2021.1,nacos2021.1，gateway3.0.7不提供sentinel控制台jar包，版本1.8.2。不提供nacos中心jar包，版本2.0.3。springboot项目限流（需要gateway等的往下翻）在单独的springboot整体项目中限流，此处我做的是代码持久化，注意是注解式。pom.x
前言讲解springboot中使用。springcloud中使用（gateway、nacos中使用）。注意，只做限流讲解，同时springboot为springmvc框架。springcloud使用springwebflux框架基础环境springboot2.4.13，sentinel2021.1,nacos2021.1，gateway3.0.7不提供sentinel控制台jar包，版本1.8.2。不提供nacos中心jar包，版本2.0.3。springboot项目限流（需要gateway等的往下翻）在单独的springboot整体项目中限流，此处我做的是代码持久化，注意是注解式。pom.x
从远端服务器获取变更数据的主要模式有两种：推（push）和拉（pull）。Push模式简单来说就是服务端主动将数据变更信息推送给客户端，这种模式优点是时效性好，服务端数据发生变更可以立马通知到客户端，但这种模式需要服务端维持与客户端的心跳连接，会增加服务端实现的复杂度，服务端也需要占用更多的资源来维持与客户端的连接。而Pull模式则是客户端主动去服务器请求数据，例如，每间隔10ms就向服务端发起请求获取数据。显而易见pull模式存在时效性问题。请求的间隔也不太好设置，间隔太短，对服务器请求压力过大。间隔时间过长，那么必然会造成时效性很差。而且如果配置长时间不更新，并且存在大量的客户端就会产生大
从远端服务器获取变更数据的主要模式有两种：推（push）和拉（pull）。Push模式简单来说就是服务端主动将数据变更信息推送给客户端，这种模式优点是时效性好，服务端数据发生变更可以立马通知到客户端，但这种模式需要服务端维持与客户端的心跳连接，会增加服务端实现的复杂度，服务端也需要占用更多的资源来维持与客户端的连接。而Pull模式则是客户端主动去服务器请求数据，例如，每间隔10ms就向服务端发起请求获取数据。显而易见pull模式存在时效性问题。请求的间隔也不太好设置，间隔太短，对服务器请求压力过大。间隔时间过长，那么必然会造成时效性很差。而且如果配置长时间不更新，并且存在大量的客户端就会产生大
