dubbo nacos,Dubbo+Nacos 启动时报错Connection refused
dubbo nacos,Dubbo+Nacos 启动时报错Connection refused详细介绍
本文目录一览： Dubbo与Nacos的区别两者是不是有重叠？
没有重叠，只是两者侧重点不一样。Nacos主要功能集中在动态服务发现、服务配置、服务元数据及流量管理。你可以把他简单的理解为是一个注册中心和配置中心，而Dubbo是一款高性能、轻量级的开源Java服务框架，主要功能点在于RPC框架。
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。
Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力，面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。
微服务初体验（二）：使用Nacos作为配置中心并集成Dubbo
首先启动Nacos，按照上篇文章的步骤，启动Nacos服务和项目，访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml，在Spring boot项目中bootstrap.yml会比application.yml优先初始化，所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已经把Nacos作为配置中心的配置写入了application.yml，现在只需要把它从applicaiton.yml中剪切出来即可， 其中的spring:application:name会作为Nacos中新增配置时的Data ID，需要留意 ），再新增属性gorup进行分组测试，如下图
接着打开Nacos的服务的web页面，打开配置管理->配置列表，点击右侧新增按钮，进行新增。 Data ID： bootstrap.yml配置文件中spring:application:name对应的名称 ； Group：指定分组（便于不同环境下的项目配置管理，因为笔者这里属于测试，所以填写的是和上文中的配置文件中group对应的test一致）； 描述：针对于该配置的描述； 配置格式：配置文件的格式，要和Data ID中的后缀格式一致（这里笔者用的是yml，那么下面就选择yaml，注意该位置也可以选择properties，但是必须和上面bootstrap.yml文件中的file-extension的值相匹配）； 配置内容：具体的配置内容（这里笔者将项目中的application.yml中的配置全部拷贝至其中）；
测试启动consumer服务，在application.yml中为空的时候，项目启动端口还是如Nacos配置中的9011，说明项目依赖Nacos的配置中心成功，其他服务如法炮制即可：
新增一个测试Controller，然后加上@RefreshScope注解，表明该Controller中的配置数据为自动刷新 。
编辑Nacos中的配置文件consumer新增相关参数type: test，访问Controller，返回test。效果如下图：
将Nacos中consumer.yml文件的type: test修改为type: prod，在不重启项目的情况下重新访问对应的controller，效果如下图：
因为Dubbo是属于各个服务之间都要公用的依赖，所以将其引入cloud-common当中，详细的版本可以去 mvnrepository 搜索合适自己项目的
引入依赖后需要编写消费者服务中的配置文件，将Dubbo服务注册至Nacos，新增如下内容，其中subscribed-services指的是生产者服务，prot：-1指的是端口随机，registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos
接下来新增接口服务，项目类型为Maven项目，在项目中新增一个接口。并在cloud-provider（生产者）和cloud-consumer（消费者）pom.xml文件中都引入该模块
在生产者实际服务中实现该接口对应的方法
在服务消费者的Controller中引入该Service，并在该Service上加入@Reference注解，注意在引入jar包的时候选择带有Dubbo的，不要使用Jdk原生的
编写消费者服务中测试Dubbo调用的接口，进行测试，测试结果如下图：
Dubbo + Nacos 部署 Docker 无法找到服务提供者解决方案
近期由于搭建公司整套测试环境中使用Docker 容器化部署Dubbo一直出现找不到服务提供者
经过两天断断续续的摸索以及资料（说到这理要落泪了）的查询该问题得意解决这就是本次要扯的内容。
本次 dubbo 服务 是以docker-compose进行服务编排部署，服务者与消费者也在同一个Java 工程目录下
当我们服务者工程开启的时候会在Nacos中服务列表中产生新的一项接口其内容是这样的，根据下方的图片可以很清楚的看到IP及端口是不是有点似曾相识的感觉呢，特别是20880端口！
又经历了一资料的查询之后，我发现20800端口并没有被我映射出来。于是我把服务提供者配置文件改这样：
消费者配置文件改成这样
终于在我本地以及不同的服务器之间可以正常运行了！
其实如果不在测试环境上遇到这些问题以后在生产环境上也同样会遇到，我们能做的就是在问题到来之前做一定的知识储备避免一些常见的坑。
Dubbo - 为什么选择Nacos
文章链接 : ,这个是阿里写的 ,主要是考虑 dubbo 节点太多的原因 , zk效率太低 , 还有一致性太强了
下载链接
Dubbo 对于版本的把控真的实在是太坑了 , 动不动缺少东西 ,所以运行时如果出现什么加载错误, 可以直接去找是不是根本没有这个类 ,找个版本合适的就行了....
服务器端配置 :
启动类 和我dubbo入门一样 , 几乎不变直接启动就行了 , 然后进入 Nocas的服务器端界面就行了
Dubbo+Nacos 启动时报错Connection refused
开发电脑：MacBook
开发工具：IDEA
项目大致情况：springboot+nacos+dubbo
项目在启动后向nacos中注册的过程中出现
后来看到某位大神的博客说到，dubbo中会遍历电脑的网卡，虽然你看到服务注册上去了，但是其实并不是你的wifi的那个网卡的ip地址，同事的window电脑就不会有这样的问题，我也不是很清楚原因
不过通过配置yml来指定你的服务提供者的ip地址
dubbo.provider.host=192.168.2.67(这里填上mac电脑的en0网卡的ip地址即可)
或者在运行时在JVM?启动参数中加入如下配置
-DDUBBO_IP_TO_BIND=192.168.2.67
有介绍redis dubbo nocas的书籍推荐
推荐的关于redis、dubbo、nocas的书：1.Redis设计与实现：Redis技术专家撰写，深入了解Redis技术内幕的之作。从源码角度解析Redis的架构设计、实现原理和工作机制，为高效使用 Redis 提供原理性指导；2.深入理解Apache Dubbo与实战：主要侧重于详细解读Dubbo框架工作原理和底层机制，并结合少量核心源码进行讲解。在原理的基础上，展示一些动手扩展Dubbo特性的实战场；3.Nacos架构&原理：Nacos 开源之前在阿里内部已经发展了十年，沉淀了很多优秀的能力，如其易用性、稳定性、实时性以及大规模的特性；也有很多历史负担，在开源的时候我们取其精华进行开源，为了提升代码的健壮性和扩展性，进行了充分的分层和模块化设计。
dubbo服务调用异常
dubbo服务调用异常有可能是以下原因造成：地址找不到、调用超时。
地址找不到：No provideravailable。
（1）Provider服务没启动，或者注册中心（比如ZooKeeper，Nacos，Consul）宕机了。
（2）Dubbo的服务配置有误差，必须保证服务名，组别（默认是Dubbo），version三者都正确。
（3）访问的环境有误：通常我们会有开发环境、测试环境、线上生产环境等多套环境。有时候发布的服务到了测试环境，而访问调用时却走了开发环境。
调用超时：client-sidetimeout
（1）服务端确实处理比较慢，无法在指定的时间返回结果，调用端就自动返回一个超时的异常响应来结束此次调用。
（2）服务端如果响应的比较快，但当客户端Load很高，负载压力很大的时候，会因为客户端请求发不出去、响应卡在TCPBuffer等问题，造成超时。因为客户端接收到服务端发来的数据或者请求服务端的数据，都会在系统层面排队，如果系统负载比较高，在内核态的时间占比就会加长，从而造成客户端获取到值时已经超时。
（3）通常是业务处理太慢，可在服务提供方机器上执行：jstack［PID］＞jstack.log分析线程都卡在哪个方法调用上，这里就是慢的原因。如果不能调优性能，请调高timeout阈值。
Dubbo的特性：
面向接口代理的高性能RPC调用提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
智能负载均衡内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
服务自动注册与发现支持多种注册中心服务，服务实例上下线实时感知。
高度可扩展能力遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。
运行期流量调度内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
可视化的服务治理与运维提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。
以上内容参考：百度百科-Dubbo
Nacos服务发现
Nacos 另一个非常重要的特性就是服务注册与发现，说到服务的注册与发现相信大家应该都不陌生，它们是服务治理的最基础功能。
Nacos 支持几乎所有主流类型的 “服务” 的发现、配置和管理。
了解过 Dubbo 的同学，应该对 Dubbo 的架构非常熟悉，最经典的一张架构图如下所示：
图中的6个步骤的含义解释如下：
0、服务容器负责启动，加载，运行服务提供者。
1、服务提供者在启动时，向注册中心注册自己提供的服务。
2、服务消费者在启动时，向注册中心订阅自己所需的服务。
3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
其中图中最上方的 Registry 就是注册中心，负责服务的注册与发现。Dubbo 有自己的 Registry 实现，而 Nacos 则是另一种 Registry 实现。
相对服务注册而言服务发现就简单很多了。就是Nacos客户端调用Open API或者SDK查询服务列表，服务端接受到请求后根据将查询到服务包装成json格式返回。
既然如此，客户端是啥时候发起服务列表查询？
如果客户端查的时差内，刚好有服务实例有down掉，那客户端的请求岂不是有请求到刚好down的服务实例？下面进行解答。
客户端有一个HostReactor类，在com.alibaba.nacos.client.naming.core包下。
HostReactor它里面有一个UpdateTask线程，每 1s 发送一次pull拉取请求，获取服务最新的地址列表。
更新服务的核心逻辑在updateService方法中：
再看看processServiceJson方法， 本地维护一个Map
serviceInfoMap 存储服务信息，同时调用 DiskCache.write(serviceInfo, this.cacheDir) 方法把服务信息写入本地缓存文件中;
服务端采取的是基于push的方式向客户端通知，由于服务端和服务提供者（各个微服务provider）建立了心跳机制，一旦某个服务出现故障，服务端察觉出后，会发送一个push消息给Nacos客户端，也就是我们的消费者。这个push消息是使用DatagramSocket来实现的。
服务消费者收到服务端发来的push消息之后，使用HostReactor中提供的ServiceInfo processServiceJson(String json)方法解析消息，并更新本地服务地址列表。
可以参照下面的图更容易理解服务动态感知原理，包括：客户端主动轮训查询服务列表及服务端Push变故后的服务列表。
message can not send, because channel is closed
异常：
消费者请求服务时一直提示message can not send, because channel is closed。
问题现象：
原因：
Dubbo应用都会占用一个系统端口，默认为20880。当应用增多时就会占用更多的端口，当端口无法开启，就会造成以上问题。
解决办法：
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 20880:20890 -j ACCEPT
异常:
1.4.0版本 单机模式下 错误：code:503,msg:server is DOWN now, please try again later!
解决办法：
删除{nacos.home}/nacos/data/protocol文件夹后重新启动。
参考：
https://github.com/alibaba/nacos/issues/4291
spring cloud和dubbo哪个会被淘汰？
个人觉的两者都不会被淘汰，但是在未来分布式微服务解决方案中或者架构中，springCloud会占主导地位。
springCloud：
1.springCloud提供了完成的分布式解决方案，基础解决方案以及组件比较健全，而且最近几年围绕springCloud边缘服务组件越来越多，例如：nacos。
2.springCloud是基于springboot的，spring的使用部署太方便了。
dubbo：
1.dubbo更多解决的是服务间的调用，也就是服务通讯协议rpc，也会是dubbo没有完整的分布式解决方案基础设施。例如：注册中心需要借助Zookeper，链路追踪：zipkin。
要说Dubbo，算是Spring Cloud的一个子集好了,大致相当于Spring Cloud里的 Eureka + Feign + 1/2Hystrix另外
现在大公司也在慢慢想springCloud服务过度，还有面试中文springCloud问题越来阅读，dubbo越来越少。
dubbo生态圈没有spring cloud好，会被先淘汰掉。现有架构都会优先选择Spring cloud，毕竟使用起来更简单一点。
微服务现在是一阵风而已，实际来说，很多系统不适用，综合算下来，微服务成本比原来大多了。不是所有系统都是互联网，都是弹缩性很强。有的系统就是固定数据量，稳定运行，可能几个大一点服务器就足够了。
真正需要微服务的不会像现在看到的那么多。
慢慢沉淀，估计会把一些不需要的改回去，套壳的改回去。
如果简化方式，感觉dubbo这种轻便的有优势，开发运维都简单。或者替代品也是轻便为主。
剩的可能真的需要微服务，一般都是中等规模以上的，或者巨头，一般都有自己的内部框架。这种用也得全套完善的。
它们都淘汰也是早晚的事[捂脸]毕竟是java闭源。随着service mesh的兴起，isito的落地并于k8s的无缝融合，一切像基础设施下沉[呲牙]
事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。
以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：
第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。
第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。
第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。
第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。
因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。
个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。
分层是计算机科学永恒的主题，service mesh是微服务的未来，这样看来这两个以后都会被取代，只有spring boot能够继续存活。
这是两个作用和使用场景不同的框架，目前的情况来看都不会被淘汰。
springcloud用于微服务，dubbo用于服务治理，各有各的适用场景。
在国外springcloud使用的多，在国内dubbo使用的多。
springcloud由国外的spring团队开发维护，热度和可靠性不用多说，dubbo由国内的阿里巴巴开发，现交由Apache孵化器，可靠性也很高。
Spring cloud是当前主流的微服务架构，轻便，插件式的设计理念很赢得当前开发及企业的青睐，在很多方面优于dubbo的架构设计，我认为dubbo最终会被淘汰，但短时间内不会，因为很多金融机构之前很多系统用的是dubbo架构，金融机构在短时间内考虑系统和业务的稳定性不会立刻就更新换代
dubbo
对内rpc，对外http，dubbo效率比httpclient高很多