Dubbo的Container详解模块，是一个独立的容器，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。
服务容器只是一个简单的Main方法，并加载一个简单的Spring容器，用于暴露服务
Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check="true"，可以通过 check="false" 关闭检查
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数
-
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
-
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大
-
一致性Hash，相同参数的请求总是发到同一提供者。
-
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议
当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可
多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用
Dubbo 提供了声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量
dubbo提供了三种结果缓存机制：
lru：基于最近最少使用原则删除多余缓存，保持最热的数据被缓存
threadlocal：当前线程缓存
jcache：可以桥接各种缓存实现
Dubbo服务之间的调用默认是同步等待结果阻塞的，支持异步调用。
Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对象
Dubbo 2.2.0 以上版本支持服务降级
服务降级就是当服务响应超时或连接请求超时，不用继续等下去，而采用降级措施，意思就是返回一个planB，返回一个我们自己定义好的提示。
而为什么要使用服务降级，这是防止分布式服务发生雪崩效应，什么是雪崩？就是蝴蝶效应，当一个请求发生超时，一直等待着服务响应，那么在高并发情况下，很多请求都是因为这样一直等着响应，直到服务资源耗尽产生宕机，而宕机之后会导致分布式其他服务调用该宕机的服务也会出现资源耗尽宕机，这样下去将导致整个分布式服务都瘫痪，这就是雪崩。如果你要问为什么不做集群？集群当然做，但是一台服务宕机之后，其他流量分发到其他集群机器上，压力也会随之加大，时间久了整个集群也会垮了，这只是个时间问题。为了防止产生了雪崩效应那么就该对服务配置降级，一旦请求超过规定时间立即返回自定义好的提示，无需继续等待
dubbo中有提供一个叫做mock的配置，mock只在出现非业务异常(比如超时，网络异常等)时执行。mock的配置支持两种，一种为boolean值，默认的为false。如果配置为true，则缺省使用mock类名，即类名+Mock后缀；另外一种则是配置"return null"，统一返回
服务读写推荐的容错策略是怎样的？
读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。
写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。
SpringCloud与Dubbo区别
最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。而SpringCloud是基于Http协议+rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑
模块区别：1、Dubbo主要分为服务注册中心，服务提供者，服务消费者，还有管控中心；2、相比起Dubbo简单的四个模块，SpringCloud则是一个完整的分布式一站式框架，他有着一样的服务注册中心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，消息总线，以及服务追踪等
在Dubbo中使用高效的Java序列化（Kryo和FST）
[java]序列化框架性能对比（kryo、hessian、java、protostuff）
