1. Dubbo的生产者需要配置dubbo service标签，这里面有几个核心参数要配置：
   1. Id名
   2. Interface 接口路径
   3. Ref 接口名
   4. Registry 注册zk上的地址
   5. Group分组
   6. Check 检查服务是否是可用的 默认check是true的，设置为true的话，默认服务在启动时，检查到不可用时会抛出异常，防止spring将服务加载进容器中，可以最快速的发现问题。。我们组的话在测试环境上一般会配置成false的
   7. Retries 超时尝试重连。Dubbo在超时后未配置的情况下，默认的重连次数是2次，我们的实际配置是0次
   8. Timeout，dubbo响应超时时间，这个根据实际业务情况设定，未设置的情况下默认是1000毫秒

1. Dubbo的消费者需要配置dubbo reference标签，核心参数与生产端一致
2. Dubbo默认是使用dubbo协议的，我们使用的也是dubbo协议，可以根据dubbo  protocol标签来配置切换协议。
   1. 链接个数：单链接
   2. 链接方式：长连接
   3. 传输协议：TCP
   4. 传输方式：NIO异步传输
   5. Dubbo适用于请求入参数据较小的情况，对于文件、超大字符串不建议使用
   6. Dubbo的消费者数量是远大于提供者的，此时通过NIO保证稳定（单一长连接防止阻塞）
3. Dubbo的通信过程

首先我们已经知道了dubbo是采用socket长连接双工的模式来处理通信的，那从客户端发起请求，到远程服务端响应，这是一个异步的过程，这个过程是如何实现的呢

1. 首先，客户端发起dubbo调用请求，此时呢dubbo会根据内置机制生成一个唯一的识别标识id
2. 将调用信息（接口名称、入参、接口方法）以及callback相应信息全部封装成一个Object对象
3. 将id和object放进一个全局的concurrentHashMap(客户端和服务端都在用)中的put方法中
4. 然后再把这个id和Object封装成一个conRequest类，使用IOsession.write(conRequest)异步发送出去
5. 然后客户端发完请求以后，会使用callback方法的get方法试图去获取远程服务端的响应结果，此时先要通过synchronized获取锁，然后开始检查是否有响应结果，如果没有的话，就通过wait方法，先把锁释放掉，让线程继续去等待
6. ===============客户端的活动暂时到这，接下来开始服务端的表演=============
7. 服务端开始处理业务逻辑，处理完以后，把处理结果放进Object对象里的callback中，然后通过id找到concurrentHashmap，把结果put进去。同时将结果回传给客户端
8. 客户端是专门有一个监听消息的线程，当他监听到有结果返回时，使用synchronized获取回调对象callback的锁（因为前面调用过wait()，那个线程已释放callback的锁了），再notifyAll()，唤醒前面处于等待状态的线程继续执行（callback的get()方法继续执行就能拿到调用结果了）。