Dubbo

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、背景介绍 公司的旧项目今年要微服务化，最近在帮业务部门做demo验证，旧项目用的JDK7，且在JDK8下会出现奇怪的编译问题。而我们新开发的服务是基于JDK8，两个项目之间通过dubbo接口进行调用。 然后今天业务部门的兄弟就找我反映了一个问题，说是项目用JDK7启动会报下边这个错 但是用JDK8就是好的，而JDK8又会有奇怪的编译问题，于是就只能JDK7编译、JDK8启动......希望我们能帮他们解决下。 二、问题原因及解决 暂时还没空写一个demo重现这个问题，先简单记录一下。 问题代码如下所示： //ClassPathScanningCandidateComponentProvider.java protected void registerDefaultFilters() { this.includeFilters.add(new AnnotationTypeFilter(Component.class)); ClassLoader cl = ClassPathScanningCandidateComponentProvider.class.getClassLoader(); try { this.includeFilters.add(new AnnotationTypeFilter( (

1）注解方式 @Reference(version = "1.5",url="dubbo://192.168.52.43:26887") protected OrderDataManager orderDataManager; url=“协议://系统ip:系统dubbo服务端口” 2）配置xml方式 <dubbo:reference id="orderDataManager" interface="com.xx.OrderDataManager" url="dubbo://192.168.52.43:26987"/> 3.代码方式 ApplicationConfig ac=new ApplicationConfig(); ac.setName("consumerSystem");//消费系统 ReferenceConfig<OrderDataManager> rf=new ReferenceConfig<OrderDataManager>(); rf.setInterface(OrderDataManager.class);//dubbo接口 rf.setUrl("dubbo://192.168.52.43:26987/com.xxx.OrderDataManager");//调用地址 rf.setVersion("1.5"); rf.setProtocol("dubbo");

zk伪集群指的是一台主机配置多个zk 先安装一个zk，然后把zk文件夹复制粘贴多份，这样就可以配置多个zk了，然后在每个zk配置指定参数 这里我配置了4个zk，点击进入，打开conf下的zoo.cfg(zoo_sample.cfg复制一份去掉sample就是了) 另外三个zk配置文件只要dataDir、dataLogDir和clientPort不一样即可，其他都一样 然后建立dataDir和dataLogDir对应的文件夹 然后再dataDir下的每个文件夹下建立一个myid，其内容为对应的上面所说的1、2、3、4 其他的类似，内容为2、3、4 到此zk伪集群的配置就完成了，点击zk文件夹对应的bin下的zkServer.cmd就可以启动zk了 SpringBoot和Dubbo在idea中的依赖搭建什么的我就不多说了，看我的github=》ecs项目（当然只能我自己看得到，本来就是写个自己的，记个笔记而已） 这里我出一个application.yml配置dubbo的内容 另外3个除了dubbo.application.name和protocol.port不一样，其他一样 然后提供者暴露的接口使用的注解是dubbo中的@Service，消费者需要使用dubbo中的@Reference注解自动注入，提供者的启动类要再加上个@EnableDubbo，还有用到的实体类啊

在此基础上记录dubbo官网介绍的常用属性配置,dubbo读取我们配置的属性时是有优先级的,优先级如下图：　　 　　　　　　　　　　　　　　　　　　 　　如图所示，优先级的属性依次为虚拟机参数>xml配置>dubbo.properties,虚拟机参数即程序启动之前我们通过-D配置的dubbo属性,xml配置即我们项目中自己写的xml文件或者是springboot中的application.properties，当公共配置很简单，没有多注册中心，多协议等情况，或者想多个 Spring 容器想共享配置的情况下可以用dubbo.properties作为缺省配置；需要注意的是我这里的测试用例都是写在application.properties中,当然如果感觉不习惯,也可以跟普通maven项目一样新建xml文件,在xml中进行配置，只是不要忘了在springboot的启动类中添加@ImportResource(locations="xml路径")注解来引入就行,下面开始记录dubbo的常用配置； 　　一、启动时检查(check) 　　默认情况下dubbo是开启自动检查的,即当项目启动时会自动检查其依赖的服务是否开启,如果没开是会阻止spring的初始化的,即check=true;我们可以将check置为false来关闭启动时检查,如我们在测试或者对其他服务没有依赖的时候可以关闭检查

前言 fescar发布已有时日，分布式事务一直是业界备受关注的领域，fescar发布一个月左右便受到了近5000个star足以说明其热度。当然，在fescar出来之前，已经有比较成熟的分布式事务的解决方案开源了，比较典型的方案如LCN（https://github.com/codingapi/tx-lcn）的2pc型无侵入事务，目前lcn已发展到5.0，已支持和fescar事务模型类似的TCX型事务。还有如TCC型事务实现hmily（https://github.com/yu199195/hmily）、tcc-transaction(https://github.com/changmingxie/tcc-transaction)等。在微服务架构流行的当下、阿里这种开源大户背景下，fescar的发布无疑又掀起了研究分布式事务的热潮。fescar脱胎于阿里云商业分布式事务服务GTS，在线上环境提供这种公共服务其模式肯定经受了非常严苛的考验。其分布式事务模型TXC又仿于传统事务模型XA方案，主要区别在于资源管理器的定位一个在应用层一个在数据库层。博主觉得fescar的txc模型实现非常有研究的价值，所以今天我们来好好翻一翻fescar项目的代码。本文篇幅较长，浏览并理解本文大概耗时30~60分钟左右。 项目地址 fescar：https://github.com/alibaba

第1章 微服务入门 本章中将概要介绍微服务与传统应用之间的差异与实现优势，以便于帮助同学们更加清晰微服务在项目开发中的定位。 1-1 课程导学 试看 1-2 ***学前必读***（助你平稳踩坑，畅学无忧，课程学习与解决问题指南） 1-3 传统应用带来的问题 1-4 微服务概述 第2章 演示环境构建 本章中将通过一系列的基本演示，让同学们可以对Dubbo有一个快速直观的认识。当前项目中构建了目前Dubbo的两种主流兼容框架Spring和Springboot，并且都进行了Dubbo集成，以便于适应多种需求下的应对使用。 2-1 基础环境构建介绍 2-2 Spring基础环境构建 2-3 Spring的直连提供者 2-4 SpringBoot基础环境构建 2-5 SpringBoot直连提供者演示 2-6 注册中心概述 2-7 Zookeeper-windows安装 2-8 Spring集成注册中心 2-9 Springboot集成注册中心 2-10 基于Apache Dubbo结合Springboot构建开发环境 2-11 常见问题集锦 2-12 阶段任务 第3章 业务基础环境构建 经过上一章节的演示，让大家了解到Dubbo与Spring、Springboot集成和基本使用，本章中会将Dubbo与Guns进行集成，构建一个业务系统的基本环境，同时针对API网关进行了一个简单的描述和引入

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Dubbo支持在服务调用方对服务提供者采用负载均衡算法，LoadBalance 接口定义如下： @SPI(RandomLoadBalance.NAME) public interface LoadBalance { /** * select one invoker in list. * * @param invokers invokers. * @param url refer url * @param invocation invocation. * @return selected invoker. */ @Adaptive("loadbalance") <t> Invoker<t> select(List<invoker<t>> invokers, URL url, Invocation invocation) throws RpcException; } 从中透露出如下几个信息： 默认如果不配置，使用RandomLoadBalance策略(加权随机负载算法）。整个Dubbo的负载均衡类图如下所示： 上述各种路由负载策略，对应的配置值如下：dubbo-cluster\src\main\resources\META-INF\dubbo\internal\com.alibaba.dubbo.rpc

背景 Dubbo是一个分布式服务框架，能避免单点故障和支持服务的横向扩容。一个服务通常会部署多个实例。如何从多个服务 Provider 组成的集群中挑选出一个进行调用，就涉及到一个负载均衡的策略。 几个概念 在讨论负载均衡之前，我想先解释一下这3个概念。 负载均衡 集群容错 服务路由 这3个概念容易混淆。他们都描述了怎么从多个 Provider 中选择一个来进行调用。那他们到底有什么区别呢?下面我来举一个简单的例子，把这几个概念阐述清楚吧。 有一个Dubbo的用户服务，在北京部署了10个，在上海部署了20个。一个杭州的服务消费方发起了一次调用，然后发生了以下的事情: 根据配置的路由规则，如果杭州发起的调用，会路由到比较近的上海的20个 Provider。 根据配置的随机负载均衡策略，在20个 Provider 中随机选择了一个来调用，假设随机到了第7个 Provider。 结果调用第7个 Provider 失败了。 根据配置的Failover集群容错模式，重试其他服务器。 重试了第13个 Provider，调用成功。 上面的第1，2，4步骤就分别对应了路由，负载均衡和集群容错。 Dubbo中，先通过路由，从多个 Provider 中按照路由规则，选出一个子集。再根据负载均衡从子集中选出一个 Provider 进行本次调用。如果调用失败了，根据集群容错策略

当注册中心是zookeeper的时候，服务导出其实是在/root/interface/providers下创建一个临时节点，这个节点的路径就是服务的url。而取消注册就是将该节点删除。 // 服务注册 @Override public void doRegister ( URL url ) { try { // 创建临时节点 zkClient . create ( toUrlPath ( url ) , url . getParameter ( DYNAMIC_KEY , true ) ) ; } catch ( Throwable e ) { throw new RpcException ( "Failed to register " + url + " to zookeeper " + getUrl ( ) + ", cause: " + e . getMessage ( ) , e ) ; } } // 服务下线 @Override public void doUnregister ( URL url ) { try { // 把对应节点删除 zkClient . delete ( toUrlPath ( url ) ) ; } catch ( Throwable e ) { throw new RpcException ( "Failed to unregister " +

这是 why 技术的第 28 篇原创文章 之前在 《Dubbo 一致性哈希负载均衡的源码和 Bug，了解一下？》中写到了我发现了一个 Dubbo 一致性哈希负载均衡算法的 Bug。 对于解决方案我是这样写的： 特别简单，把获取identityHashCode的方法从System.identityHashCode(invokers)修改为invokers.hashCode()即可。此方案是我提的issue里面的评论，这里System.identityHashCode和 hashCode之间的联系和区别就不进行展开讲述了，不清楚的大家可以自行了解一下。 我说： 这里 System.identityHashCode 和 hashCode 之间的联系和区别就不进行展开讲述了，不清楚的大家可以自行了解一下。 但是有读者在后台问我详细原因，我已经和他聊清楚了。 再加上这个 BUG 已于近期修复了，且只用了一行代码就修复了 ，那我就写一下解决方案，以及背后的原理。 即是对之前文章的一个补充，也是一个独立的知识点。 所以本文主要是回答下面这三个问题： 1.什么是 System.identityHashCode？ 2.什么是 hashCode？ 3.为什么一行代码就修复了这个 BUG？ 注：本文 Dubbo 源码 2.7.4.1 版本。如果阅读过 《Dubbo 一致性哈希负载均衡的源码和 Bug