wang0907的博客

dubbo之入门

写在前面在dubbo之telnet使用 一文中我们介绍了如何使用dubbo 提供的telnet server功能，本文一起来看下其具体实现，对应的源码模块如下图：该功能模块对应的顶层接口是com.alibaba.dubbo.remoting.telnet.TelnetHandler,不同的telnet命令对应了不同的实现子类，如command包下对应的命令分别是clear,exit,help,log,status,如下图红框对部分命令的使用：客户端方发送的消息需要经过适配，才能执行到对应的子类，这

写在前面我们知道像tomcat，nginx等都可以通过telnet命令连接，dubbo也实现了telnet server，因此我们也可以通过telnet命令来连接dubbo，下面我们一起来看下。1：测试我们先来启动一个dubbo的服务提供者，如dubbo://192.168.10.119:20828/dongshi.daddy.service.cluster.ClusterService,则在命令行输入telnet 192.168.10.119 20828就可以连接成功了，如下图：然后就发送指令来

写在前面在dubbo之NIO服务器-抽象API 一文中我们分析了dubbo提供的NIO服务器相关的API抽象，本文一起来看下transport网络传输层的相关代码，实现的功能是抽象mina和netty为统一接口，然后用户基于SPI机制就可以自由选择使用哪种NIO框架了。1：AbstractPeer类签名为public abstract class AbstractPeer implements Endpoint, ChannelHandler{},其中Endpoint接口参考1.1：Endpoint。

TODO

写在前面dubbo为了实现服务的高可用，提供了集群容错的功能，本文我们就一起来看下集群调用接口com.alibaba.dubbo.rpc.cluster.Cluster以及其实现类和相关类。集群容错 对应的顶层接口是com.alibaba.dubbo.rpc.cluster.Cluster,源码如下：@SPI(FailoverCluster.NAME)public interface Cluster { // 基于Directory创建一个统一的Invoker调用，从而实现对一个服务类的一组

写在前面为了实现服务的高可用，一般我们都会考虑通过集群方式来实现，当一台服务提供者出现问题时，还有其他的服务提供者failover，保证系统正常使用，为了能够更好的观察服务信息，我们通过dubbo-amin来查看,关于dubbo-admin搭建可以参考dubbo之dubbo admin搭建 一文。1：测试服务提供者 , 服务消费者 。以下依赖于此进行测试！1.1：启动服务提供者实例启动后查看dubbo-admin:可以看到当前已经有一个服务提供者实例了，再启动一个，查看：此时就有两

1：dubbo-admin准备环境准备:zk安装 。maven setting：<?xml version="1.0" encoding="UTF-8"?><settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://mav

debug测试源码 。写在前面在dubbo之服务本地暴露 文章中我们分析了本地暴露的过程，本文一起看下对应的服务消费者端是如何引用的，即本地引用。一般的，当使用本地引用时，xml配置如下：<fakeRoot> <dubbo:reference id="scopeLocalService" interface="dongshi.daddy.service.scopelocal.ScopeLocalService" scope="local"/></fakeR.

在这里插入图片描述

写在前面服务提供者提供的服务标记了@Service注解的类，想要被服务消费者使用，必须将服务暴露出去，即让服务消费者拿到封装服务信息的com.alibaba.dubbo.common.URL对象字符串，当前服务暴露的方式有如下三种：远程暴露：即将服务信息注册到远端的注册中心，如配置<dubbo:service scope="remote" />。本地暴露：JVM内部调用，因为信息已经在内存中，通过内存可以直接获取调用信息，因此叫做本地暴露，如配置<dubbo:service scop

写在前面本文需要dubbo SPI的简单基础知识，对dubbo SPI不了解的朋友可以参考dubbo之SPI分析 。在dubbo之SPI分析 文章中我们分析了SPI机制，其中有种SPI是一个Wrapper类的情况，本文一起来看下Wrapper的使用，Wapper在dubbo中的作用类似于spring 中AOP，实现扩展类调用拦截的功能，现在考虑这样的一个场景，对于某个扩展类的调用，我们想要做以下的几件事：1：统计调用时长。2：记录调用日志。想要满足这个需求，我们就可以通过Wrapper类来实

写在前面本文一起来看下dubbo远程服务暴漏。TODO 待编写

写在前面dubbo目前提供了三种线程池的实现，如下：fixed：固定大小的线程池，启动时建立，并且不会关闭，这也是缺省的设置。cached：缓存线程池，空闲一分钟自动删除，需要时重建。limited：可伸缩线程池，但是线程池中的线程数只会增长不会收缩，这样做的目的是为了避免当进行收缩时流量突然增加造成性能问题。在dubbo源码中相关代码在dubbo-common模块，如下图：图中的ThreadPool就是顶层的接口，我们就从这个接口开始吧！1：ThreadPool源码如下：@SPI("

写在前面我们知道在jdk中提供了SPI 的机制，但是存在一个问题，就是加载的类会在加载时就进行初始化，而不是使用时再进行初始化，此时如果是初始化的类最终并没有使用，很明显这就是一种资源浪费了，对于dubbo，其提供了非常多的扩展点，并且每个扩展点都提供了很多不同的实现，而这些不同的实现实际运行过程中只有其中一个或者几个才会用到，比如Protocol，有DubboProtocol，InjvmProtocol,RestProtocol等，因此为了解决jdk SPI加载就是初始化的问题，dubbo再jdk SP

写在前面dubbo提供了SPI机制可以通过外部配置文件来动态加载扩展类，有时我们可能需要配置这些扩展类挨个执行来满足业务场景，进行一些数据的处理等，此时这些扩展类我们都是需要的，还有一些其他的场景，需要根据外部环境的不同（如某参数的值），来动态的选择使用哪个扩展类，针对这种需求，dubbo提供了@Adaptive注解来完成该功能，源码如下：@Documented@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.TYPE, ElementT

1：写在前面在这篇文章 中我们分析了通过xml配置方式配置解析的过程，本文一起来看下基于注解配置方式，即Java config方式配置的解析过程。另外关于dubbo注解配置使用可以参考如下的文章列表：dubbo之入门 。dubbo之外部化配置 。如下是服务提供者端一个可能的配置：@Configuration@EnableDubbo(scanBasePackages = "dongshi.daddy.service.annotation")public class DubboConfigurat

写在前面dubbo提供了ApplicationConfig，ProtocolConfig，ProviderConfig，ConsumerConfig，RegistryConfig等类，来完成dubbo各种信息的注册工作，当前只支持的如下图：目前dubbo主要支持的配置方式有xml配置，注解配置（使用@DubboComponentScan+@Configuration方式），另外还有一种配置方式，那就是外部化配置，外部化配置是springboot提出的一种全新的配置理念，通过配置的信息来按照指定的规则生

写在前面在我们的系统中一般可以分为核心业务和非核心业务，比如电商系统中，订单模块就是核心模块，购物成功通知模块，评论模块等是非核心模块，在系统调用中我们不能因为非核心模块出现问题导致核心模块的正常运行，此时就可以考虑使用熔断，本文我们就一起看下如何使用hystrix来实现dubbo调用的熔断。实现思路：利用dubbo的Filter，过滤请求，加入hystrix熔断逻辑。源码：这里 。dubbo基础知识以及环境搭建可以参考这篇文章 。1：引入依赖<dependecies>

1：写在前面在这篇文章 介绍了如何使用spring的自定义标签来生成spring bean，好处是灵活可定制，dubbo提供的xml配置也使用了这种方式来完成配置，下面我们一起来看下。2：定义先来看下dubbo的相关的xsd，namespacehandler的配置。2.1：xsd根据spring的规范xsd需要定义在META-INF/spring.schemas文件中，如下图：内容如下：http\://code.alibabatech.com/schema/dubbo/dubbo.xsd=M

1：写在前面事件通知，用于在调用服务提供者的过程中，配置调用过程中的监听，如配置当开始调用时调用消费者端某方法，执行完毕正常返回时调用消费者端某方法，执行的过程中发生了异常调用消费者端某方法，其实就是一种监听机制，当特定的事件发生时，执行特定的逻辑，下面我们一起来看下。2：服务提供者端2.1：服务接口public interface MyEventNotifyService { /** * 获取用户名字 * * @param userId * @ret

1：写在前面在这篇文章 中我们分析了服务提供者配置的相关源码，本文一起来看下服务消费者配置相关的源码，还是看一个通过API 方式配置服务消费者的实例代码：public class ConsumerWithApiConfigMain { public static void main(String[] args) { // 当前应用配置 ApplicationConfig application = new ApplicationConfig();

1：写在前面从这篇文章 我们可以知道对于服务提供者，不管是xml方式，还是注解方式，抑或是API方式最直接的方式，直接创建对应的配置类，都会创建对应的配置类，我们以API配置方式来看下具体都需要哪些类：public class FakeCls { public void fakeMethod() { // 服务实现 ProviderService providerService = new ProviderServiceImpl();

1：写在前面服务提供者作为服务的提供方，为了安全性，接口是不可以随意调用的，为了解决这个问题，dubbo提供了token令牌机制，只需要在service配置中设置token即可，下面我们来一起看下。2：服务提供方2.1：服务接口public interface MyProviderTokenService { String sayHi(String word);}2.2：服务接口实现public class MyProviderTokenServiceImpl implements

1：写在前面考虑这样的场景，当消费者调用服务提供者后，服务提供者需要执行一段时间，比如一分钟左右，才能有结果，这时就有2种方案，一种是同步方案，即等着，第二种是异步方案，有结果之后让服务提供者回调消费者的一个接口，显然同步的方案肯定是不行的，线程资源可能在很短的时间内就会耗尽，因此第二种明显是最优方案，针对这种场景，dubbo提供了callback机制，下面我们来一起看下。2：服务提供者2.1：服务接口public interface MyCallbackService { void add

1：写在前面考虑这样的场景，当服务提供者还没有开发完毕或者是因为某些原因无法启动时，会导致服务消费者方的停滞，此时为了能够正常的开发测试，可以使用mock功能，在服务消费者端提供一个服务接口的mock实现类，来模拟调用服务提供者正常获取结果，不同于stub 既支持在服务提供者端配置，也支持在服务消费者端配置，mock是假定服务提供者不可用的情况下产生的一种模拟机制，因此只能在服务消费者端配置使用。2：实例以下操作均在服务消费者端进行，因为我们假定的是没有可用的服务提供者端的情况。2.1：定义服务接口

1：写在前面考虑这样的场景，想要在调用真正的服务类之前进行一些拦截，比如安全性验证等工作，此时就可以考虑使用stub来完成，因此stub是一种dubbo提供的基于服务调用的拦截机制，通过装饰真正服务类来完成功能，需要和服务类实现相同的接口，可以定义在服务提供者端，也可也以定义在服务消费者端，下面我们来分别看下这两种方式。2：定义在服务提供者端2.1：provider端2.1.1：定义服务接口public interface MyProviderStubService { String sa

TODO: http://svip.iocoder.cn/Dubbo/configuration-properties/

1：分析如果我们查看在zk中注册的服务提供者信息（服务消费者类似），可能看到如下的信息：[zk: localhost:2181(CONNECTED) 8] ls /dubbo/dongshi.daddy.api.UserRpcService/providers [dubbo://192.168.10.119:20881/dongshi.daddy.api.UserRpcService?anyhost=true&application=user-service-provider11191458&

写在前面dubbo提供的常用配置方式有以下四种：1：API配置2：属性配置3：xml配置4：注解配置本文我们来一起看下第一种方式,即API配置。在这篇文章 基础上进行改造（参考的基于springboot，这里用不到，我只是为了图省事直接在此基础上改了，其实引入dubbo相关依赖后，直接写普通的main方法就可以了）。源码 。1：rpc-service-provider-apiconfig删除application.yml,dubbo.xml配置文件，然后修改ProviderAppli

写在前面通过本文一起来看下如何使用sentinel来进行限流。在这篇文章 基础上进行改造。源码 。1：sentinel控制台在这里 下载控制台jar包（这是一个springboot项目）。 下载完毕后通过如下命令启动:java -jar sentinel-dashboard-1.7.0.jar --server.port=8010 --auth.username=sentinel --auth.password=sentinel，启动成功后通过http://192.168.10.119:8010

写在前面通过本文一起来看下如何使用nacos作为注册中心来注册dubbo服务提供者和服务消费者的信息。在这篇文章 基础上进行改造。nacos的简单安装参考这篇文章 。源码 。1：rpc-service-provider-03修改服务提供者模块。1.1：修改依赖修改zk依赖为nacos依赖：<!-- 使用 Zookeeper 作为注册中心 --><!--<dependency> <groupId>org.apache.curator<

写在前面dubbo给我们提供了很多的扩展点，异常过滤就是其中的一个，比如参数验证的ContraintViolationException异常需要我们在service方法上手动的throw，才能抛出去，不然会自动的封装为RuntimeException，我们来扩展异常过滤，抛出自定义的异常信息，从而以更加友好的方式来暴漏出现的问题。扩展的原理是利用SPI，SPI符合开闭原则，即，对修改关闭，对扩展开放，dubbo在jdk spi 的基础上进行了升级改造，定义了dubbo SPI。在这篇文章 基础上进行

写在前面本文在这篇文章 基础上改造进行测试。dubbo的参数验证基于JSR303规范就是定义了校验注解，错误信息如何提示等的规范，我们只需要使用规定的注解，并声明Filter就可以了。源码。1：改造rpc-service-api1.1：引入依赖<dependencies> <!-- 参数校验相关依赖 --> <!-- JSR303参数校验相关对应规范API --> <dependency> <gro

1：dubbo是什么？dubbo的是一个基于Java开发的高性能rpc框架，提供了3大功能，如下：1：基于接口的远程方法调用（依赖于netty）2：智能容错和负载均衡3：服务的注册和发现（依赖于zk，nacos等三方组件）2：dubbo有什么？在dubbo中一个有5大角色，分别是注册中心Registry，服务提供者Provider，服务消费者Consumer，监控中心Monitor，服务运行容器Container，三者的功能如下：Registry：服务提供者注册自己的服务，服务消费者发现服务