在当前容器化、k8s流行的背景下不太建议使用nacos作注册中心当然nacos作配置中心使用也是个不错的选择。nacos作注册中心适用那种只使用java编程语言、非k8s部署方式的情况下。一、背景微服务的配置信息经历了程序配置文件-git config-配置中心nacos、apollo;注册中心常用的解决方案zookeeperdubbo、eureka、nacos微服务部署过程中既要注册中心、也需要配置中心但如果分别搭建2套组件一方面占用更多资源另一方面维护成本也会增加nacos既可作为配置中心又可以作为注册中心在微服务发展中因此脱颖而出随着容器化的发展特别是k8s的兴起nacos不一定是最优秀的解决方案二、二种微服务调用解决方案直接通过ip:port访问一般通过nginx等方式做负载均衡一般情况下通过nginx等方式做服务的负载均衡但很难做到服务的动态发现2. 注册中心1服务提供者注册到注册中心注册中心记录服务提供者的IP、PORT2服务消费者订阅注册中心数据获取服务提供者的IP、PORT然后通过IP、PORT调用服务提供者的接口3通过注册中心做到服务的动态发现三、nacos作注册中心存在的问题微服务部署在docker容器中可能会导致服务在注册中心登记的IP为容器的ip,从而导致服务无法调用微服务部署在不同的k8s集群也会导致微服务相互调不通微服务部署的服务器如果是双网卡的也很容易会导致微服务无法调用跨语言调用支持例如有一些微服务是基于java的一些微服务是基于python的java服务调用python服务不能通过nacos注册中心来调用间接方法通过sidecar来注册到nacos微服务间调用容易受nacos影响nacos宕机开发环境nacos可能只部署一个所有开发都注册到这个nacos上容易导致被调用方不是调用方期望的。例如开发A想调用开发环境上服务S的接口开发B这时在自己电脑上开发测试服务S二者都注册到了nacos上这时开发A有可能调到了开发B电脑上的服务S。这时开发B重启服务、修复接口会导致开发A调用有问题四、微服务调用方案建议在k8s越来越流行很多公司都上k8s了在k8s集群内部可以通过k8s serviceName的方式调用服务提供者的接口在k8s集群外部调用k8s集群的服务可以通过k8s ingress将集群内部的服务暴露出来让服务消费者调用通过这种方式能解决服务动态发现、跨语言调用java调用python服务二大问题五、java Feign调用配置说明feign的一般配置如下所示FeignClient注解有2个关键参数nameurl。当url为空时FeignClient会根据nameserviceName在注册中心获取微服务的IP、端口调用接口如果url不会空时会通过url参数调用接口。例如1 nameservice1、url为空service1在注册中心的ip、端口为127.0.0.1:8080,则调用method1时访问url为 http://127.0.0.1:8080/method1;2urlhttp://abc:3000,name可以为空也可以非空则调用method1访问url为 http://abc:3000/method1;url参数放到注册中心默认为空这时可以通过注册中心调用微服务在开发测试生产环境时一般通过指定url的方式来调用微服务1开发、测试环境可能部署在容器或k8s集群上通过注册中心不一定能调得通2开发、测试环境nacos一般只部署一套如果开发人员做开发时注册到了nacos会导致开发、测试环境异常影响别的开发、测试同事3生产环境的发布服务停止、启动会导致服务短暂调不通原因由于nacos是基于APCAP理论实现的先保证可以不能保证数据的一致性即有一些微服务当前是不可用的但nacos没有马上更新FeignClient(name service1, url ${base-url:}) public interface TradePasswordFeignClient { PostMapping(/method1) ResultWrapperString method1(); }六、nacos作为注册中心的适合场景如果生产环境不是使用k8s部署所有微服务都是基于java实现的这种情况nacos作注册中心比较合适。因为如果通过url的方式访问微服务要配置一个统一网关将微服务暴露出来同时做负载均衡这样很麻烦直接使用nacos作注册中心就可以解决。