Dubbo

概念 在dubbo的整体结构中，除了service层和config层，其他各层都支持自定义扩展。而自定义扩展的实现，就是dubbo实现的一套类似SPI的扩展点加载机制。在这个机制中，ExtensionLoader是核心类。 组件 ExtensionLoader dubbo SPI机制的主要使用入口，基本就是通过这个类来使用和实现SPI机制的 ExtensionFactory dubbo的SPI机制，具备Ioc的功能特性。其实现主要由ExtensionFactory支持。大概的逻辑就是，如果某个组件具有setXX方法，则会通过ExtensionFactory为其注入依赖。ExtensionFactory在dubbo中，就类似与spring的BeanFactory，算是一种容器。 接口定义 @SPI //本身也支持dubbo的扩展点机制 public interface ExtensionFactory { //获取扩展类 < T > T getExtension ( Class < T > type , String name ) ; } 子类 SpringExtensionFactory：关联了spring的ApplicationContext SpiExtensionFactory：通过dubbo自己的SPI机制，读取指定目录下的文件

http://blog.kazaff.me/2015/02/02/dubbo%E7%9A%84%E6%9C%8D%E5%8A%A1%E6%B2%BB%E7%90%86%E7%BB%86%E8%8A%82/ 如果说单单只完成远程调用的话，dubbo还算不上是一个合格的SOA服务架构，而它之所以那么碉堡，是因为它还提供了服务治理的功能，今天就让我们来研究一下关于服务治理，dubbo都做了什么。 听起来服务治理挺高大上的，但其实做的都是一些非常琐碎的事儿，了解了dubbo的做法，你就会发觉其实一切并没有想的那么复杂。远程调用要解决的最本质的问题是通信，通信就好像人和人之间的互动，有效的沟通建立在双方彼此了解的基础上（我们团队在沟通上就有死穴），同样道理，服务提供方和消费方之间要相互了解对方的基本情况，才能做到更好的完成远程调用。这里面就要提到dubbo的做法： URL 。 前几篇中大量提到dubbo的分层之间是依靠什么纽带工作的：invoker，没错，比invoker更low的就是URL，这是dubbo带给我的另一个非常重要的经验。才疏学浅，并不知道dubbo是借鉴的哪里，但影响了全世界的WEB就是依赖URL机制建立了互联网帝国的！ 依赖URL机制，dubbo不仅打通了通信两端，而且还靠URL机制完成了服务治理的任务。我们可以先看一下这些内容： 路由规则 配置规则 服务降级 负载均衡

【可】 1、Spring boot之application.yml、application-dev.yml、application-pro.yml yml也是配置文件，之前我们所熟知的配置文件是xml和properties文件。 xml文件自不必多说，格式要求规范，内容比较繁杂，各种的标签充斥其中； properties文件虽然没有了标签，但是没有层级结构之后你会发现会用重复代码，每一条信息都要形容一下他的层级结构等。 【据说】 yml/yaml文件就结合了xml与properties文件的优点。具体是什么样的呢？请瞧代码样例： 【注意】：配置的值和键之间务必要加一个空格。 application.yml ：一般配置访问端口、地址、连接池等； application-dev.yml ：一般配置dubbo、redis、日志、其他对接平台... dubbo redis 日志 PS：日志配置文件 其他接口：完全样例数据 application-pro.yml ：可能更正式一点、内容差不多。 【飞】 Dubbo的配置文件xxx-web.xml或者xxxxxx.properties 前面咱们讲yml文件与properties文件的区别，这里刚好用到。 1、如果用xxxxx.properties文件来进行配置的话 consumer方 provider方 2、如果使用xxxx.xml进行配置 <

Caused by: com.alibaba.dubbo.remoting.RemotingException: Failed to bind NettyServer on /10.200.12.227:20896, cause: Failed to bind to: /0.0.0.0:20896 at com.alibaba.dubbo.remoting.transport.AbstractServer.<init>(AbstractServer.java:68) at com.alibaba.dubbo.remoting.transport.netty.NettyServer.<init>(NettyServer.java:61) at com.alibaba.dubbo.remoting.transport.netty.NettyTransporter.bind(NettyTransporter.java:31) at com.alibaba.dubbo.remoting.Transporter$Adaptive.bind(Transporter$Adaptive.java) at com.alibaba.dubbo.remoting.Transporters.bind(Transporters.java:56) at com.alibaba.dubbo.remoting

前沿：在当下流行的分布式架构中Dubbo是非常流行的一门技术，借着这几天有空学习学习，并在后面的项目中进行实战，为后面的分布式项目做铺垫。 Dubbox简介 Dubbox 是一个分布式服务框架，其前身是阿里巴巴开源项目Dubbo ，被国内电商及互联网项目中使用，后期阿里巴巴停止了该项目的维护，当当网便在Dubbo基础上进行优化，并继续维护，为了与原有的Dubbo区分，故将其命名为Dubbox。 Dubbox 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbox就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbox这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。 节点角色说明： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 调用关系说明： 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推

此文章针对对dubbo有基本了解的人观看 yml文件 pom文件 启动类 Service层 引用dubbo服务的注解 最后 yml文件 如果只作为服务的消费者不用暴露端口号，扫描的包名根据自己service改 dubbo : application : name : springboot - dubbo - demo #应用名 registry : address : zookeeper : / / 127.0 .0 .1 : 2181 #zookeeper地址 # port : 2181 #提供注册的端口 protocol : name : dubbo port : "20889" #dubbo服务暴露的端口 scan : com . bw . ssm . service . impl #扫描的包名 pom文件 springboot我用的2.1.4建议和我用一样的，不一样的话引入dubbo依赖版本也需要更改 < dependencies > < dependency > < groupId > com . bw < / groupId > < artifactId > interface - api < / artifactId > < version > 1.0 - SNAPSHOT < / version > < / dependency > < dependency > <

Dubbo(读音[ˈdʌbəʊ])是阿里巴巴公司开源的一个高性能优秀的 服务框架 ，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 [1] Spring 框架无缝集成。 Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 主要核心部件： Remoting: 网络通信框架，实现了 sync-over-async RPC: 一个 远程过程调用 的抽象，支持 负载均衡 、 容灾 和 集群 功能 Registry: 服务目录框架用于服务的注册和服务事件发布和订阅 工作原理： Provider 暴露服务方称之为“服务提供者”。 Consumer 调用 远程服务 方称之为“服务消费者”。 Registry 服务注册与发现的中心目录服务称之为“服务注册中心”。 Monitor 统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。 (1) 连通性： 注册中心负责服务地址的注册与查找，相当于 目录服务 ，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

SpringCloud和Dubbo都是当下流行的RPC框架，各自都集成了服务发现和治理组件。SpringCloud用Eureka做注册中心，Dubbo用Zookeeper注册中心。 注册服务 Dubbo是基于java接口及Hession2序列化的来实现传输的，Provider对外暴露接口，Consumer根据接口的规则调用。也就是Provider向Zookeeper注册的是接口信息，Consumer从Zookeeper发现的是接口的信息，通过接口的name，group，version来匹配调用。Consumer只关注接口是否匹配，而对此接口属于什么应用不关心。当然接口的注册信息里会包含应用的ip，hostname等。 SpringCloud的服务发现是基于Http协议来实现的，Provider对外暴露的是应用信息，比如应用名称，ip地址等等，Consumer发现的是应用的信息，当调用的时候随机选择一个Provider的IP地址，应用名称，然后依据Http协议发送请求。Consumer关注的是应用名称，根据应用名称来决定调用的是哪个服务集群，然后对此名称对应的服务集群做负载均衡。Provider接受到请求后，根据内置的SpringMVC来匹配路由处理请求。 SpringCloud是一套目前比较网站微服务框架了，整合了分布式常用解决方案遇到了问题注册中心Eureka

D irectory： 集群目录服务 Directory， 代表多个Invoker, 可以看成List<Invoker>,它的值可能是动态变化的比如注册中心推送变更。集群选择调用服务时通过目录服务找到所有服务 StaticDirectory: 静态目录服务， 它的所有Invoker通过构造函数传入， 服务消费方引用服务的时候， 服务对多注册中心的引用，将Invokers集合直接传入 StaticDirectory构造器，再由Cluster伪装成一个Invoker ； StaticDirectory的list方法直接返回所有invoker集合； RegistryDirectory: 注册目录服务， 它的Invoker集合是从注册中心获取的， 它实现了NotifyListener接口实现了回调接口notify(List<Url>) 通俗的来说，就是一个缓存和更新缓存的过程 Directory目录服务的更新过程 RegistryProtocol.doRefer 方法，也就是消费端在初始化的时候，这里涉及到了 RegistryDirectory这个类。然后执行cluster.join(directory) 方法。这些代码在上篇博客有分析过。 cluster.join 其实就是将 Directory中的多个Invoker伪装成一个Invoker, 对上层透明，包含集群的容错机制

提起 Spring Cloud 的限流降级组件，一般首先想到的是 Netflix 的 Hystrix。 不过就在2018年底，Netflix 宣布不再积极开发 Hystrix，该项目将处于维护模式。官方表示 1.5.18 版本的 Hystrix 已经足够稳定，可以满足 Netflix 现有应用的需求，所以接下来其会把焦点转向对于自适应的实现，更多关注对应用程序的实时性能做出响应。对于新应用的熔断需求，将采用其它项目实现，Netflix 推荐了 Resilience4j。 作为 Spring Cloud Netflix 重要套件，Hystrix已经成为保障微服务稳定性的首选应用。其实除了 Netflix 和 Resilience4j，限流降级还有一个新的选择，就是阿里巴巴的Sentinel组件。 一、阿里开源 Sentinel 简介 2018年8月，阿里巴巴宣布将 Sentinel 进行开源，同时推出了结合 Dubbo 的适配器，捐赠给了Apache Dubbo社区。 1.Sentinel 的历史 2012 年，Sentinel 诞生，主要功能为入口流量控制。 2013-2017 年，Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。 2018 年，Sentinel 开源，并持续演进。