前言
前情概要
上一篇我们简单实现了一个自己的RPC框架，主要依托我们上两篇所提到的这个RPC的流程分析
1.客户端处理过程中调用client stub（就像调用本地方法一样），传入参数
2.Client stub将参数编组为消息，然后通过系统调用向服务端发送消息
3.客户端本地操作系统将消息从客户端机器发送到服务端机器
4.服务端操作系统将接收到的数据包传递给client stub
5.server stub解组消息为参数
6.server stub再调用服务端的过程，过程执行结果以反方向的相同步骤响应给客户端
stub：分布式计算中的存根是一段代码，它转换在远程过程调用期间Client和server之间传递的参数
我们还通过发现者的引入，对协议支持和网络层的提取进行了一些小的优化，结构如下：
PS:紫色代表客户端代理部分，浅绿色属于服务发现，浅蓝色属于协议部分
各个小块的代码基本已经给出，相信即使是自己需要跑一下的话也无需进行过多的代码填充工作了
以往链接
从零开始的高并发（二）--- Zookeeper实现分布式锁
从零开始的高并发（三）--- Zookeeper集群的搭建和leader选举
从零开始的高并发（四）--- Zookeeper的分布式队列
从零开始的高并发（五）--- Zookeeper的配置中心应用
从零开始的高并发（六）--- Zookeeper的Master选举及官网小览
dubbo概述
① dubbo的简介
和zookeeper类似，网址只需要记住，首先这个项目叫dubbo，然后它是属于apache下的，然后开源是非营利性组织，也就是org，所以网址就是：
可能小伙伴们要是留意这张图片的话，会发现一开始的时候，它的这张图片右上方是带有Incubating这个英文的，有这个英文说明当时的dubbo还是一个孵化项目，而且因为它是中国人开发的，所以对于中文的翻译支持非常全面，所以对于我们来说学起来应该算是最便利的
Apache Dubbo是一款高性能，轻量级的开源java RPC框架，提供了3大核心能力，面向接口的远程方法调用，智能容错和负载均衡，服务自动注册及发现。
这样一对比，好像我们上一篇写出来的小样就弱爆了哈哈哈
② dubbo能做什么
③ dubbo的架构
Provider：服务提供者，我们的service，实际执行业务逻辑的服务层
Consumer：服务消费者，对service进行调用，不关注service的具体实现的应用层
Register：注册中心，存储Provider，Consumer信息的中介
Monitor：监控中心，dubbo负责收集服务调用信息的监控中心
如果事先有了解过应该在官网上应该看过了，init是初始化，async是异步，sync是同步。我们不难发现所有的RPC框架都脱离不了三个基本要素，就是服务消费者和服务提供者，还有把这些角色们组合起来的网络，缺少一个都谈不上是一个完整的RPC了。
第一步就是我们的服务提供者通过初始化动作，把它的服务信息暴露给注册中心，比如端口号，协议，版本，参数，接口，方法或返回值等基本信息，注册中心register就可以视为一个媒人，服务提供者看作相亲对象女方，这些对象要把它们的基本信息给到媒人以便让服务消费者（男方）认识，此时我们男方是在这个中介所下了单的，让中介所帮忙留意他喜欢的女生，符合要求就通知他，所以subscribe订阅，就是男方让媒人帮忙留意合适的女方的动作
可是姑娘的状态信息不是一成不变的，所以男方也需要异步获得女方的动态，而这个动态也是媒人Registry来notify告知的，那这个机制在这里也是不难猜到，是使用zookeeper的watch机制来实现的，invoke就类似于他们交往沟通的过程了
Monitor就类似于国家的315消费者协议，这次的服务是个什么效果，来做个调研
④ dubbo的调用过程
1.服务容器负责启动，加载，运行服务提供者
2.服务提供者在启动时，向注册中心注册自己提供的服务
3.服务消费者在启动时，向注册中心订阅自己所需的服务
4.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
5.服务消费者从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选择另一台调用
6.服务消费者和服务提供者在内存中累计调用次数和调用时间，定时发送一次统计数据到监控中心
⑤ dubbo的架构特点
dubbo分别具有以下特点，连通性，健壮性，伸缩性和升级性
连通性：刚刚也提到异步操作主要是两个，一个是订阅服务地址的变化，另一个是监控中心的执行是异步的，这说明了一点，在我们程序运行过程中，注册中心或者监控中心挂掉，是不会对我们的程序流程造成影响的，就好比男方已经获取到女方的电话了，这样男方就自然可以和女方取得联系，而无所谓女方突然变胖一两斤或者感冒发烧。而监控中心挂掉只会影响我们的一些采集数据，也不会对程序造成影响
健壮性：这个在之前的zookeeper中已经无数次地被提到了，节点挂掉不影响集群其他节点的工作
升级性：就是一个服务治理方面的想法，达到自动增加服务器去消费突然增长的请求数的一个功能
⑥ dubbo的依赖
必须：JDK1.6+,理论上dubbo可以只依赖JDK，不依赖其他第三方库运行，需要配置JDK相关实现策略
缺省：
⑦ dubbo的使用方式
服务提供端：
1.独立的服务（普通的java程序形式）
2.集成在应用中（在应用中增加远程服务能力）
消费客户端
1.在应用中调用远程服务
2.在服务1提供者中调用远程服务
⑧ dubbo的三种配置方式
1.使用dubbo注解
使用相对简单，不过有侵入性，需要实现类中依赖dubbo提供的注解
2.集成Spring XML（使用较多）
使用相对麻烦，可以无侵入，方便以后改用其他RPC框架
3.使用原生API的方式
编程过程十分麻烦，一般仅用于测试，开放API的场景
⑨ dubbo的使用步骤
1.引入dubbo相关依赖
2.配置dubbo框架（也就是 ⑧ 提到的3个方式）
3.服务的开发与配置
4.启动和调用
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.1.32.Final</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.6</version>
</dependency>
finally
也是有小伙伴反映我贴代码贴的有点太多，也是因为这次的小样比较可有可无吧，所以就省事了。篇幅的问题大家诟病已久，更加详细的内容也是留下一篇再扯扯吧（很多代码···）
下一篇：dubbo的核心功能详解与配置
