Dubbo

众所周知，Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架。 从这段话中，我们提取 关键字：分布式、RPC 一、为什么需要使用分布式系统 1、单机系统 项目工程比较简单，可能全部代码就在一个工程中， 或者按照模块来划分工程结构。 将项目放入tomcat就可以直接运行。用户流量增多，那么就多部署几台tomcat服务器，外层做负载均衡，实现分流。如果一台服务器挂了，系统还可以正常使用，相对实现“高可用”。 弊端： 实现项目结构比较单一的项目，如何项目开发团队上10人，系统代码具有100万行代码，几十人共同维护一个项目，涉及冲突会让人崩溃。并且项目新模块A需要上线，需要测试全部模块才可以保证系统正常，很容易造成新模块影响原有功能。每次发布需要全部代码重新发布，费事又费力。 2、分布式系统 分布式系统：庞大系统分而治之。 在我的理解中，分布式系统就是一个不断拆分的过程。把一个大整系统分划为多个小的子系统。众多的子系统合在一起便过程整个系统。 一个大的系统拆分为很多小的系统，甚至很多小的服务，然后几个人组成一个小组就专门维护其中一个小系统，或者每个人维护一个小服务。 简单来说，就是分而治之，这样每个人可以专注维护自己的代码。 不同的小系统自己开发、测试和上线，都不会跟别人耦合在一起，可以自己独立进行，非常的方便，大大简化了大规模系统的开发成本。 当然使用分布式

前言 Dubbo 支持多种传输协议，可以有多种注册中心等等高扩展的功能，其原因就是 Dubbo SPI 提供的良好的扩展性，可以给开发者自己实现多样丰富的功能。Dubbo SPI在Java SPI的基础上发展而来，和Java SPI 一样，都是典型的 策略模式 实现，本文就主要介绍 Dubbo SPI 的使用方式和源码分析。 结合代码能够更深了解本文的内容，代码github地址：https://github.com/mikasaco/dubbo-study.git Dubbo SPI 和 Java SPI 的比较 Java SPI 的使用方式可以 参考博客 Dubbo SPI 相比于 Java SPI 有以下 3 个 优势： Java SPI 每次都会把所有实现类都加载并实例化(是在迭代器迭代的时候创建实例)，而 Dubbo SPI 是分两段创建实例，先进行类加载，然后在使用到具体实现的时候才实例化，并且 Dubbo SPI 大量使用缓存，会把 Class 对象和实例对象都缓存起来，性能更好； Java SPI 在类加载失败的时候难以定位异常； Dubbo SPI 还支持 IOC 和 AOP 。 补充一下JVM的类加载机制 类加载大的上来分有 加载、连接、初始化 3 个步骤。经常会误把加载等同于类加载，把加载包含初始化。 加载是把 class 文件读到方法区，并创建一个 Class

导读 从学习JavaWeb开始,Spring一直陪伴着我们. 一直到SpringCloud,大大简化了我们的开发. 可是自己学习过,但却在日常生活中,没有使用到,还是生疏了. 服务治理 OOP: 面向对象编程 AOP: 面向切面编程 SOA: 面向服务编程( 服务治理 ) 概念: 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现， 此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键 服务治理和微服务的差别: 远程通信 无论是微服务还是分布式服务（都是SOA，都是面向服务编程）， 都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？ RPC RPC：Remote Produce Call远程过程调用，类似的还有RMI （Remote Methods Invoke 远程方法调用，是JAVA中的概念，是JAVA十三大技术之一）。 自定义数据格式，基于原生TCP通信，速度快，效率高。 早期的webservice，现在热门的dubbo，都是RPC的典型 RPC的框架：webservie(cxf)、dubbo RMI的框架：hessian Http Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架。 一、Dubbo出现的背景 　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进； 　　 　　1.当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。 　　2.当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 　　3.接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 二、Dubbo架构 　　 　　 1.节点角色说明： 　　 Provider: 暴露服务的服务提供方。 　　 Consumer: 调用远程服务的服务消费方。 　　 Registry: 服务注册与发现的注册中心。 　 　Monitor: 统计服务的调用次调和调用时间的监控中心。 　 　Container: 服务运行容器。 　 　2.调用关系说明： 　　 0. 服务容器负责启动，加载，运行服务提供者 　　 1. 服务提供者在启动时，向注册中心注册自己提供的服务。 　　 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。 　　 3.

阿里P8架构师谈：如何设计淘宝亿级系统架构！ 优知学院 2018-09-20 18:31:30 类似淘宝这样的大型网站，需要涉及到如下架构设计技术 1.业务拆分 应用程序拆分，拆分后如何通讯、拆分步骤、拆分的原则等。 比如我以淘宝为例：根据业务属性进行垂直切分，划分为商品，订单系统、用户系统、购物车系统，支付系统，评论系统，客服系统等，系统拆分后会涉及到消息通讯机制，以及以下的集群部署。 2.应用集群部署（分布式部署，集群部署和负载均衡） 分布式部署：将业务拆分后的应用单独部署，应用直接通过类似Dubbo远程通信； 集群部署：电商网站的高可用要求，每个应用至少部署N台服务器进行集群部署； 负载均衡：是高可用系统必须的，一般应用通过负载均衡实现高可用，分布式服务通过内置的负载均衡实现高可用，关系型数据库通过主备方式实现高可用。 3.分布式中间件技术 分布式缓存：Redis为代表的，以及TFS、GFS、HDFS为代表的分布式文件存储等。 4.单点登录（分布式Session） 系统分割为多个子系统，独立部署后，不可避免的会遇到会话管理的问题。一般可采用Session同步，Cookies，分布式Session方式，大型网站一般采用分布式Session实现。 5.数据库集群（垂直拆分、读写分离，分库分表） 数据库的数据量过大之后，需要按照业务为单位进行数据库垂直拆分。淘宝为例，拆分为商品库

按照常理，直接去 https://github.com/alibaba/dubbo 下载，然后进入下面的dubbo-admin目录，进行mvn打包即可，但是不知道为何，却找不到dubbo-admin这个目录。 那就直接去下载他们打包好的源代码吧：https://github.com/alibaba/dubbo/releases 1、解压后，根目录里存在dubbo-admin，进入 mvn package -Dmaven.test.skip=true 安装完后，生成target目录，进入这个目录，找到dubbo-admin-2.6.0这个目录，把这个目录全部copy到tomcat的目录webapps下的ROOT下面（删除tomcat webapps目录下ROOT原有内容） 2、解压后，根目录里存在dubbo-admin，进入 mvn install -Dmaven.test.skip=true 安装完后，生成target目录，进入这个目录，找到dubbo-admin-2.6.0.war，把这个war包copy到tomcat的目录webapps下的ROOT下面（删除tomcat webapps目录下ROOT原有内容），然后使用jar xvf dubbo-admin-2.6.0.war解压war包，把解压后的内容全部放到ROOT目录下 启动tomcat，就可以看到dubbo

SpringBoot集成org.apache.Dubbo 一、前言 Dubbo作为一款优秀的RPC框架，在国内有着众多的使用者，自从2018年2月，Dubbo被阿里捐献给Apache基金会以后，Dubbo似乎以全新的名称 Apache Dubbo焕发了新的生命力。虽然有着同样优秀和优势的Spring Clould框架，但是Dubbo能焕发新生也是一件好事，期待着Dubbo能够完善机制，更新迭代出的更好。 所有代码我已上传到github，需要的可以自取测试，欢迎start，传送门 https://github.com/AggerChen/spring-boot-dubbo 二、项目简介 在Dubbo新的官网上查看资料，虽然也有很多demo发现要不还是旧包名com.alibaba.dubbo，要不就是集成的SpringBoot1.x，根本没法满足新的需要嘛，既然都已经是Apache Dubbo了，当然要使用最新的org.apache.dubbo和最新的SpringBoot2.x版本了~ 此篇文章就是以一下版本来展示示例： SpringBoot 2.2.2 org.apache.dubbo 2.7.5 zookeeper 3.4.14 三、项目开发 既然是Dubbo项目，那么我们的使用场景就是分布式微服务，多个service和一个consumer

最初引发这个问题的是我不理解为何使用dubbo来构建项目时，提供者需要Maven install来达到更新代码的目的，而同一项目不同的modul之间互相依赖只需在pom文件中增加相应对的依赖便可。 1. 在pom文件中添加了相对应的依赖后，在仓库中一定能找到相对应的jar包吗？ 我之前的答案是肯定的，我认为只要是在pom文件中添加了相对应的依赖，在我们的本地仓库中总能找到对应的jar包，本地仓库中没有的，也会从镜像服务器中下载，而若需要引用其他项目，也需要将被引用项目打包成jar包放入本地仓库中才可引用。 后来发现我并没有将被引用打包成jar包放入本地仓库，其他项目也可以依赖。 如果跟我有同样疑问的朋友们，可以看一下这个图。 下面的e3-common是文件夹的的图标，那么说明这是引用本地项目，并不是从本地仓库引用的jar包，如果你已经把e3-common，maven install导入到本地仓库了，那么你可以试着把e3-common close project 试试（在该项目上右键单击有一个close project的选项），你会发现在图片上的e3-common已经不见了，这时你可以上滑找找，你会发现你看到了e3-common的jar包。 2、为何使用dubbo时，提供者需要maven install一下，消费者才能接收到提供者更新后的代码？

Dubbo优雅停机 背景 对于任何一个线上应用， 如何在服务更新部署过程中保证客户端无感知是开发者必须要解决的问题 ，即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求。理想条件下，在没有请求的时候再进行更新是最安全可靠的，然而互联网应用必须要保证可用性，因此在技术层面上 优化应用更新流程来保证服务在更新时无损是必要的 。 传统的解决方式是通过将应用更新流程划分为手工摘流量、停应用、更新重启三个步骤，由人工操作实现客户端无对更新感知。这种方式简单而有效，但是限制较多：不仅需要使用借助网关的支持来摘流量，还需要在停应用前人工判断来保证在途请求已经处理完毕。这种需要人工介入的方式运维复杂度较高，只能适用规模较小的应用，无法在大规模系统上使用。 因此，如果在容器/框架级别提供某种自动化机制，来自动进行摘流量并确保处理完已到达的请求，不仅能保证业务不受更新影响，还可以极大地提升更新应用时的运维效率。 这个机制也就是 优雅停机 ，目前Tomcat/Undertow/Dubbo等容器/框架都有提供相关实现。下面给出正式一些的定义：优雅停机是指在停止应用时，执行的一系列保证应用正常关闭的操作。这些操作往往包括等待已有请求执行完成、关闭线程、关闭连接和释放资源等，优雅停机可以避免非正常关闭程序可能造成数据异常或丢失，应用异常等问题。 优雅停机本质上是JVM即将关闭前执行的一些额外的处理代码。

介绍Dubbo在开发中的一些常用配置，文中内容主要参考dubbo文档配置和示例两节，详细可移步访问 传送站 1. 属性配置方法及加载顺序 属性常用配置方法主要有三种： 第一种是通过启动时在虚拟机参数中加上相关信息 第二种也是最常用的是通过xml方式配置，随着springboot和dubbo的集成，这种方式在springboot项目中表现为通过application.properties来配置，两者优先级相同； 第三种是在classpath 根目录下的创建 dubbo.properties，dubbo启动时，如果没有其他配置文件，会自动加载该配置。 2. 启动检查 Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true" 。 可在xml和properties文件中进行配置，以显式关闭启动检查 <!-- 关闭所有服务的启动时检查 (没有提供者时报错) --> <dubbo:consumer check="false" /> dubbo.consumer.check=false 3. 超时设置 & 配置覆盖关系 由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。缺省使用<dubbo:consumer