一、Dubbo的启动方式
依赖容器:Tomcat容器
使用main方法，代码如下：
import org.springframework.context.support.ClassPathXmlApplicationContext;import java.io.IOException;publicclassMainThreadStart{publicstaticvoid main(String[] args) throws IOException{ClassPathXmlApplicationContext context =newClassPathXmlApplicationContext("classpath:spring/spring-context.xml");context.start();// 阻塞主线程System.in.read();}}
运行的结果如下：这就把服务注册到zk上了。
使用内置的main方法：如果用内置的main方法启动的话必须在resources文件夹下创建META-INF/spring的文件夹
源代码中：运用上面的方式必须在resources文件夹下创建META-INF/spring/*.xml对文件。
运行如下：也把服务注册到zk上了。
二、Dubbo的容器
dubbo默认支持的是spring容器，还有日志的log4j，logback的。还有api的。
三、如何去搭建控制台：看服务的调用和整个服务的状态
①、需要从网上去下载这样的项目：这个用来创建管控台和监控台。
总共有三个项目：主要的是下面两个
dubbo-admin:管控台 dubbo-monitor-simple:监控台
②、进行编译：必须需要jdk1.8才能够进行编译
③、部署dubbo的管控台
④、在打包后的application.properties文件中修改对应的配置信息：
通过localhost:7001访问即可：默认账号和密码相同
管控台可以用来做服务的降级，路由，负载均衡，可以查看服务与服务之间的关系
部署监控台
解压上面的.gz文件，进行相应的配置
3、启动监控台：(通过start.bat/start.sh启动)
有相应的注册服务
如果想要让服务能够被监控到，并且生成对应的图表，需要加上上面的配置信息。这样才能在监控中心上显示。
四、服务检查
当启动每一个服务的时候，去检查这个服务能否被订阅上，如果订阅不上这里就会报错。
所以一般将消费端的服务检查给取消掉。主要用于服务的循环依赖的时候。
check默认为true。
五、多协议支持
dubbo(默认)单一连接(一个一个的来进行处理)，长连接协议(可靠性的协议)。[操作过程中数据量比较小的传输),不适用大文件，视频等的传输。因为tcp主要是靠滑动窗口来保证数据的安全的。很耗时间
hessian:短连接协议(传输数据量比较大的情况，在项目开发中会针对不同流量来进行协议的设定)。
webService协议，rmi协议，http协议，thirft协议。
如何添加多协议支持
①、加相应的配置
②、加入相应的依赖:因为hessian协议是需要jetty容器支持的
<dependency><groupId>com.caucho</groupId><artifactId>hessian</artifactId><version>4.0.7</version></dependency><dependency><groupId>org.mortbay.jetty</groupId><artifactId>jetty</artifactId><version>6.1.26</version></dependency>
运行的结果如下：这时就有dubbo和hessian协议的，不指定的话每个服务都会注册两个协议的数据。
在zk上就相应的配置信息
指定服务暴漏哪个协议上：可以指定一个服务一个协议，一个服务多个协议
六、多注册中心：比如有三个服务，A,C,D服务分别注册到三个注册中心上去。解决不同服务之技的依赖的关系。
这时有一个E服务，上面的三个A,C,D服务都依赖E服务，因为注册中心无法跨服务进行通信的，所以把E服务分别注册到三个注册中心上
配置的信息如下：
指定服务注册到哪个注册中心上去：
七、多版本支持
服务的开发会随着业务的不同而迭代版本：
启动下该服务：
消费端去指定：
八、消费端的异步调用：只支持dubbo协议，异步的调用就是消费不会马上返回效果。当子线程没有返回结果的时候，主线程就已经结束了。用的是java中的Future的异步对象。
只针对dubbo协议有效的，非dubbo协议是没有效的
九、主机问题(解决注册中心上面注册的是服务器名称问题)
源码：ServiceConfig->findConfigedHosts
例如：WeizhoYang:8080/=> 192.168.124.241:8080
默认是动态分配ip地址的可以改为静态的
为true就是动态的，false就是静态的。
下面的就可以指定ip地址了。
十、直连/服务只订阅/服务只注册(针对测试)[开发环境]
服务只订阅：不需要把自己的服务注册上去，只是订阅zk其他的服务
场景：在开发中服务在测试的时候不能直接注册到注册中心上的
本地的服务和服务器上的服务将会形成为一个集群，这个集群就会形成负载，有可能负载到刚好你这台服务器上的时候，然后你把本地的服务给关掉了。
上面的图是场景，首先有两个服务A(开发中)，服务A(完善的服务)，它俩个服务是同一个接口。如果不只订阅的话都会注册到注册中心上去。这时由消费端去订阅服务端，因为dubbo有自身的负载均衡的策略的，随机获取可用的服务列表，当获取到url2的时候，这时消费端可能会报错的情况，因为开发的服务的可能会在不停的调试。所以用服务只订阅的方式来解决这个问题。
那么这时开发的服务A不会注册到注册中心上，这时消费端如何去测试服务端升级的功能呢？
消费端直连到开发的服务A就可以解决了。
①、在服务的配置文件中添加register="false"就可以了。
②、通过消费端去直连服务端暴漏出接口的url，这样就可以测试开发中的服务。
总结：直连就是绕过了注册中心，而是直接去查找服务。
服务只注册：意思服务只能注册，不能订阅
多的环境下，外部的消费者不能直接消费到里面的注册服务的，只有zk的内部的服务才能够进行调用。由于在A环境和B环境，而在A环境中和B环境中都有注册中心，而在A环境中的注册中心上有A服务和B服务还有C服务，而C服务是依赖A服务的，这时B环境可以依赖C服务的，但是A服务没有在B环境下注册，所以这时B环境去依赖C服务会报错的。所以只需要让C服务只注册就可以了。
服务端的配置
总结：这就是双环境下的问题。因为每个服务既是消费者，又是服务者，两个身份。因为不管多注册中心，和单个注册中心的话，都会找相同的服务进行负载的。服务只注册针对的是测试环境，B环境对C服务只是直连的关系，B环境消费C服务是消费不了的，但是可以依赖C服务，所以在只订阅和只注册中直连都会用到。
负载均衡(配置实现)
在dubbo中负载均衡的几种方式：
所有的负载均衡的策略：父类AbstractLoadBalance ①、static int calculateWarmupWeight(int uptime, int warmup, int weight) 这个方法主要计算负载均衡的权重的。
②、publicInvokerselect(List<invoker> invokers, URL url, Invocation invocation) 这个方法主要用来根据invokers和url通过负载均衡算法机制选择一个调用器Invoker。这个类中用了模板的设计模式，抽像类的，抽象类中可以定义抽象方法的。
③、protected abstractInvokerdoSelect(List<invoker> invokers, URL url, Invocation invocation); 这个方法由在具体的负载均衡的类中进行实现的，通过调用select方法然后调用doSelect方法来选择具体的负载均衡机制。
④、protected int getWeight(Invoker invoker, Invocation invocation) 这个方法是调用权重的方法 具体的负载均衡的类中：有一致性hash(通过接口中不同的方法名来进行hash，然后从中选择一个可用的服务来进行实现)，最小的响应时间，随机的负载，轮询的方式负载。
演示负载均衡：
启动两个provider的服务
启动第一台的时候就把provider的服务给注册上去。
启动第二台的时候就发现dubbo服务下面多出来一个链接
随便启动一台的消费端，下面的结果就是随机的负载均衡。
默认的负载均衡策略是RandomLoadBalance->random
RoundRobinLoadBalance ->roundrobin 轮询负载均衡
LeastActiveLoadBalance->leastactive 最小的响应时间进行负载，这个性能最高
ConsistentHashLoadBalance->consistenthash 一致性hash负载(环形结构，虚拟结点)
当其中一个命中的话，其他的都会命中这个因为是个环形结构为了保证高可用性，也可以保证数据的不丢失。在环上按照均匀的去分布。
消费端配置负载均衡策略：
测试下：
十一、服务调用超时问题
1、建议开发的服务都设置重试的次数和超时时间，一般设置不大于5秒，写个3000ms就可以了。
2、在集群中配置集群容错的策略：
Failover cluster:失败的时候将自动切换并重试其他的服务器，通过retries=2来设置重试的次数，在消费端配置。
Failfast:快速失败，只发起一次调用，写操作，比如新增记录，非幂等的请求。
Failsafe cluster:失败安全，出现异常信息直接忽略掉异常，主要用于日志操作出现异常情况。
Failback cluster:失败自动恢复，后台记录失败请求，定时重发这个消息(主要用于消息推送)
Forking cluster:并行调多个服务，只要一个成功就返回，只应用在读数据的时候。
BroadCast cluster:广播调用所有服务提供者，逐个调用，只要有一个报错就返回异常。
