冯立彬的博客

一、问题描述我们现在是在用Nacos替换Eureka，原来Eureka和Spring gateway运行正常，可以通过Spring gateway调用注册到Eureka中的服务。当前Spring cloud的版本是Hoxton.SR8，Nacos discovery的版本为0.9.0.RELEASE，使用的Nacos版本为2.0.3。Nacos替换Eureka改动的地方如下：１、去掉POM中Eureka的引入；２、去掉主类中引入的@EnableEurekaClient注解；３、引入N

一、发现问题应用启动时，增加Nacos服务端的配置信息。应用使用IP加端口连接Nacos服务器时，运行一切正常：#启动参数增加以下Nacos参数-Dspring.cloud.nacos.discovery.namespace=DEV -Dspring.cloud.nacos.discovery.server-addr=127.0.0.1:8848但是将server-addr换成解析好的域名就有问题：#Nacos默认的服务端端口为8848，因而Nacos服务端的端口必须配置，#否

我们应用往Eureka中注册使用的名称以及应用内部通过Feign调用，使用的服务名称都是小写，如user-service，但是注册到Eureka中后，应用的名称全部都是以大写的形式存储及展现，由于Eureka客户端对大小写的支持都是一样的，因而通过Feign使用小写的名称调用就没有问题。现在是将Spring Cloud注册中心由Eureka迁移到Nacos，但是Nacos服务端及Nacos客户端对服务名称的支持是区分大小写的，即从Eureka同步到Nacos中的大写服务名称，通过Feign中使用小写的服

HASentinel（https://gitee.com/laofeng/hasentinel）支持Nacos做为配置中心控制台改造完成，先来张Nacos中配置的截图：后续会修改修改客户端，不过当前项目较忙，会先把Eureka切换为Nacos弄完后再接着弄了。本次同时把支持更多配置中心的架构给设计好了，后续会续还会支持Apollo，觉得好请观注项目的后续发展。...

最近在将HASentinel（https://gitee.com/laofeng/hasentinel）接入Nacos配置中心，在连接的时候怎么都不能够连接成功，报错误：ErrCode:-401, ErrMsg:Client not connected,current status:STARTING使用的Nacos server及client的版本都是2.0.3。创建ConfigService使用的是方法ConfigFactory.createConfigService(Properties)，

一、NacosRegistryConsumer端启动时，通过NacosRegistry中的doSubscribe(...)方法，往Nacos服务端发起注册及获取Provider信息：方法doSubscribe(URL, NotifyListener)中根据Consumer端的url生成对应的Provider服务名称，如此时consumer的url如下：consumer://192.168.22.198/cn.raysonblog.shopserviceprovider.service.Rp

默认情况下Nacos只支持单个应用的同步，针对数百个应用要配置同步，单页面配置就是一项不小的工作量，且每新增加一个应用就需要增加一个同步配置，如果是Eureka与Nacos的双向同步则需要增加两条配置，当然可以直接在数据库中插入数据，但是这毕竟也不是长久之计，使用上也会不便，更加不符合程序员的做事风格。改造完成后Eureka与Nacos双向配置，就只以下两条配置记录：且以后不论是Eureka或是Nacos有应用注册，都会同步给对彼此，不需要新增任何的配置：注册到Eureka的应用会自动同步到

默认情况下Nacos只支持单个应用的同步，针对数百个应用要配置同步，单页面配置就是一项不小的工作量，当然可以直接在数据库中插入数据，但是这毕竟也不是长久之计，使用上也会不便，更加不符合程序员的做事风格。于是就直接针对源码开刀，改造源码支持应用名称配置为“*”时，表示从Eureka中同步全部的应用信息：现在已经改造完成了，一项配置完成了原来数百项配置才能够完成的工作，哦耶！后续接着改造从Nacos中到Eureka的批量化同步！...

一、Nacos的动态配置nacos 服务端保存了配置信息，客户端连接到服务端之后，根据 dataID、group及tanant（就是Namesapce）可以获取到具体的配置信息，当服务端的配置发生变更时，客户端会通过长轮询的HTTP长连接获取到变更通知，然后再由客户端主动去获取变更后的配置信息。二、Nacos回调机制１、Nacos 服务端创建了相关的配置项（创建 ConfigService并实例化 ConfigService）；２、客户端添加 Listener进行监听：客户端通过在Cli

功能介绍自动扫描Spring的Controller代码并生成OpenAPI文档，无代码侵入。对比与Swageer的代码侵入显得更加简洁。项目地址：https://gitee.com/laofeng/yapidoc-maven-plugin诞生原因在开发的过程中，尤其是联调的过程中，接口出入参的修改是很频繁的一件事。这就导致开发过程中，修改了接口参数缺忘记修改接口文档。因此需要一个工具能够自动读取Java类中的注释来生成文档。对比SwaggerSpringfox的代码侵入性太强了，使得代码一点

题外话设计并实现了一个消息投递平台，可以实现对不同业务场景的消息进行订阅，并将这些接收的消息根据业务场景需要，将其转投递到外部的ＥＳ、RocketMQ、Get API、Post API以及Spring Cloud类型的API，让应用以最小的接入及改造成本，实现应用的解耦。问题本次发现的问题为源消息中间为阿里云的RocketMQ，当我们在针对同一个Topic的不同Tag进行消息订阅的时候，发现最终都只能够订阅一个Tag，其它Tag的消息不能够订阅，以下代码是组装消息订阅的Map实现：如此时

早上打开Gitee，突然发现项目HASentinel被Gitee推荐了，感觉心里好开心！HASentinel特性：１、流控及降级配置改造为存储到Zookeeper中；２、将应用上报的Metrics持久化存储到Influxdb集群中；３、Metrics由Sentinel控制台主动获取，修改为由应用端主动上报，同时支持控制台集群化部署；４、优化Sentinel控制台的操作，将原来只能够针对应用的各个节点的配置操作，优化为针对应用本身的配置操作，然后应用到应用集群的所有节点；５、增加Grafa

由于平台应用场景的需要，允许将启动好的开源版本的RocketMQ的Producer执行下线、上线等操作，下线操作简单，调用其shutdown()可以方便的完成，但是上线这个操作着实费了点力气，主要发现以下几个问题：１、关闭后的Producer不可以再次启用执行了下线操作即执行了shutdown()方法的Producer，该Producer的状态变会为SHUTDOWN_ALREADY，是不允许再次上线的，当直接对该Producer执行start()方法时，就会报状态错误，也就是同一个Producer下

该脚本包括RocketMQ NameServer、RocketMQ Broker及RocketMQ Console的一键安装，其中rocketmq的版本为当前最新版本4.8.0，使用的是foxiswho打包的镜像，而rocketmq-console-ng在Docker上面找了一下，打包的版本至少都是半年以前的了，因而自己拉取最新源码打包并推送到了Docker镜像仓库中。当前安装脚本通过自定义网络及指定网络别名的方式，解决了不同Docker容器之间的相互访问的网络问题，脚本如下：#创建RocketM