商业源码 Dubbo的简要执行流程
2 服务提供者在启动时，向注册中心(zookeeper)注册自己提供的服务。
3 服务消费者在启动时，向注册中心订阅自己所需的服务。
4 注册中心返回服务提供者地址列表给消费者，(若有变更，注册中心将基于长连接推送变更数据给消费者)
5服务的消费者,从地址列表中,基于负载均衡,选一台提供者的服务器进行调用,若是失败,在从 地址列表中,选择另一台调用
6期间Dubbo的监控中心,会记录定时消费者和提供者,的调用次数和时间
大家在平时开发和测试阶段定位一些bug的时候，需要调用本地启动的dubbo服务debug。如果与服务器、其他同事共用一个注册中心的话，就会调用到别人的服务或者自己本地的服务被别人调用到，造成一些调用失败或者其他异常。
解决如上问题有大致几种解决方案：
1、dubbo直连；
2、dubbo group 服务分组；
3、dubbo version 版本过渡；
在开发以及测试环境下，经常需要绕过注册中心，只测试指定服务的提供者，这时候可 以使用点对点直连的方式。点对点直连方式，将以服务接口为单位，忽略注册中心的提供者表。A接口配置点对点，不影响B接口从注册中心获取列表。
消费者应用，在注入的提供者api上添加 @Reference(version = "100", url = "dubbo://ip:port") 即可！
此时，如果提供者不希望本地的服务被别人调用到，设置：dubboregistryregister=false,默认值是true。该属性含义： 是否向此注册中心注册服务，如果设为false，将只订阅，不注册。
通过服务分组实现环境隔离，不用绕过注册中心，大家可以共用一个注册中心。服务注册分组，使跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。
场景：服务A希望调用到本地的服务B(此时，B服务正常的调用远程服务C)，而不是远程服务B。
本地服务B的配置设置如下： //应用全局配置 dubboprovidergroup=local-group //设置本地B所提供的dubbo服务均在local-group分组下如图：
//针对某个Api进行配置
也可以针对某个api单独做分组，例如：@Service(version = "100",group = "local-group")服务A：在注入的B dubbo服务的api上加 @Reference(version = "100", group = "local-group") 即可。
服务分组的几个属性解释：
1、dubboregistrygroup=local-group
该值自行定义，确保唯一即可，该属性含义：服务注册分组，跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。 该配置不推荐配置，配置之后服务在dubbo admin上默认无法查看，也调用不到该服 务。不同环境，通过zookeeper做数据隔离。
2、dubboprovidergroup=local-group
该属性含义：服务分组，当一个接口有多个实现，可以用分组区分。该配置使当前服务所有的提供者都在local-group下。也可以只针对某个api做配置@Service(version ="100",group ="local-group")；推荐后者！
3、dubboconsumergroup=local-group
该配置使当前服务只消费local-group分组下的提供者，建议只针对某个api进行配置即可，例如： @Reference(version ="100", group ="local-group")
当一个接口的实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。dubboproviderversion=10 //服务版本， 建议使用两位数字版本，如：10 ，通常在接口不兼容时版本号才需要升级。
dubboconsumerversion=10 //消费10版本的提供者
可全局配置，亦可配置到某个api服务上，此时优先级大于全局配置。
提供者服务示例：@Service(version ="your version")
消费者api服务示例： @Reference(version ="your version")
dubbo 是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议( dubbo://xxxx )或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。
Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。
咱们来看下Spring 配置声明暴露服务，providerxml文件
再来看服务消费者，consumerxml文件
这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumerxml中配置多个服务提供者，并配置响应的负载均衡策略。
配置多个服务调用者在comsumerxml的dubbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumerxml的dubbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：
那么目前的架构有什么问题呢？
1当服务提供者增加节点时，需要修改配置文件。
2当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。
这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将providerxml和consumerxml更改为如下：
如果zookeeper是一个集群，则多个地址之间用逗号分隔即可
把consumerxml中配置的直连的方式去掉
注册信息在zookeeper中如何保存？
启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下
最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。
其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点。
zookeeper 介绍：
zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
流程说明：
支持以下功能：
补充：
dubbo的协议使用什么序列化框架？
dubbo有多种协议，不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2 序列化(说明：Hessian2 是阿里在 Hessian 基础上进行的二次开发，起名为Hessian2)。rmi协议默认为 java 原生序列化，http协议默认为为 json。
dubbo的通信方式？
采用单一长连接和NIO异步通信，基于Hessian2作为序列化协议。适合于小数据量（每次请求在100kb以内）大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient，提供者使用 NettyServer，Provider 启动的时候，会开启端口监听，使用我们平时启动 Netty 一样的方式。而 Client 在 Spring getBean 的时候，会创建 Client，调用远程方法的时候，将数据通过DubboCodec编码发送到 NettyServer，然后 NettServer 收到数据后解码，并调用本地方法，并返回数据，完成一次完美的 RPC 调用。
zookeeper选举机制？
zookeeper选举算法默认的是FastLeaderElection，选举机制的概念：
1服务器ID：比如有三台服务器，编号分别是1、2、3，编号越大在选择算法中的权重越大。
2事务ID：服务器中存放的最大数据ID(致使ZooKeeper节点状态改变的每一个操作都将更新事务id，即时间戳)，值越大说明数据越新，在选举算法中数据越新权重越大。
3逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
选举状态：LOOKING：竞选状态；FOLLOWING：随从状态，同步leader状态，参与投票；OBSERVING：观察状态,同步leader状态，不参与投票；LEADING：领导者状态。
初次选举简述：
目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：
1服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
2服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
3服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数为3正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
4服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
5服务器5启动，后面的逻辑同服务器4成为小弟。
如果中间有节点挂掉，只要有半数以上节点存活，就可以正常服务，如果leader挂掉，则所有节点处于Looking状态 ，各自依次发起投票，投票包含自己的服务器ID和最新事务ID，如果发现别人的事务id比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的事务id所属节点(事务id一样，则数据id大的胜出)。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。
引用：
https://wwwcnblogscom/iisme/p/10620125html
1、查看当前hostname
hostname
2、修改/etc/hosts文件
vim /etc/hosts
将hostname对应的ip地址改为外网地址
3、重启jar包即可
注修改/etc/hosts文件 记得将localhost新增为127001 本地ip地址，防止tomcat启动不起来（orgapachecatalinacoreStandardServerawait 无法在地址[localhost]和端口[8005]上创建服务器关闭套接字（基本端口[8005]和偏移量[0]）javanetBindException: 无法指定被请求的地址 (Bind failed)）
往service里注入失败了。
改成：ref="CarServiceImpl"
Dubbo分布式服务框架 服务注册不上：
(1) 检查dubbo的jar包有没有在classpath中，以及有没有重复的jar包
(2) 检查有没有重复的dubboproperties配置文件
(3) 检查暴露服务的spring配置有没有加载
(4) 检查beanId或beanName有没有重复
(5) 查看有没有错误日志：
cat ~/output/logs/webxlog
(6) 在服务提供者机器上测试与注册中心的网络是否通：
telnet 17222394 9090
(7) 检查与注册中心的连接是否存在：
netstat -anp | grep 17222394
(8) 如果是预发布机，检查hosts文件有没有正确绑定：
cat /etc/hosts
(9) 实在不行，开启远程调试：
– (a) 在服务器JVM参数中加入：-Xdebug -Xnoagent -Djavacompiler=NONE -Xrunjdwp:transport=dt_socket,address=7001,server=y,suspend=y
注意线上只有7001和8080可以被线下访问，调试端口需用这两个之一，因注册是启动时行为，启动时必需挂起suspend=y
– (b) 在dubbo源码的DefaultRegistryService的registerService()方法中设置断点。
– (c) 在Eclipse的Debug按钮下拉菜单Debug Configurations中的Remote Java Applications中新增远程调试，并设置IP和端口，以及增加dubbo的源码，进行远程Debug调试。
他俩其实没什么大区别，只不过dubbo可以和Spring框架无缝集成。
1、Web service是一种服务导向架构的技术，通过标准的Web协议提供服务，目的是保证不同平台的应用服务可以互操作。根据W3C的定义，Web服务(Web service)应当是一个软件系统，用以支持网络间不同机器的互动操作。
网络服务通常是许多应用程序接口(API)所组成的，它们透过网络，例如Internet的远程服务器端，执行客户所提交服务的请求。无论定义还是实现，WEB服务过程中会由服务器提供一个机器可读的描述以辨识服务器所提供的WEB服务。
另外，虽然WSDL不是SOAP服务端点的必要条件，但目前基于Java的主流WEB服务开发框架往往需要WSDL实现客户端的源代码生成。一些工业标准化组织就在WEB服务定义中强制包含SOAP和WSDL。
2、Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC 实现服务的输 出和输入功能，可以和 Spring框架无缝集成。
0条评论