在线实时数据清洗架构(2)——server选型 Dubbo

对于我这种菜鸟，第一个问题就是为什么不选择tomcat?
根据我的反思和对项目的理解，原因如下：
1，这是一个纯后台项目，在整个公司的定位是中间层组件的概念，一个用户的请求会跳到公司各种系统里，例如
用户申请——>web站点——>后台业务站点——>我们站点
其主要调用逻辑控制在后台业务站点，在这期间可能
后台业务站点——>我们站点A
后台业务站点——>站点B
后台业务站点——>站点C
…
Tomcat内有很大一部分是servlet container，一般需要用到jsp或web-后台耦合时，用到的多。
所以纯粹的通信就可以满足需要，这个时候我想到了RMI。
关于RMI
http://haolloyin.blog.51cto.com/1177454/332426/
可是使用RMI有以下几个问题：
1，集群怎么办？
2，怎么控制负载均衡？
想想还是头皮发麻，rmi太过原始，使用起来会有大量的开发量，也很考验程序员的开发功底，稍有不慎会埋下很多隐患。

主角登场——dubbo
关于dubbo的一篇文章
http://www.importnew.com/19732.html

因为dubbo其底层通信采用的是nio，（为什么nio比传统io好？文章内有答案）所以贴出关于nio的一篇文章
http://www.importnew.com/22623.html

dubbo的注册中心一般采用zookeeper管理，为什么用zookeeper管理好，我理解是zookeeper有很好的容灾机制和很好的分布式锁机制（可以解决多台并发注册时产生的问题），具体博客:
http://www.importnew.com/24411.html

面试中问到：你对dubbo调优有什么了解？
上面关于dubbo的文章内提到
“如服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？为了解决这个问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量“
具体操作：
http://blog.csdn.net/tototuzuoquan/article/details/72765540

在看看dubbo的核心内容
“其核心部分包含:
1》远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2》集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3》自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。“
完美

一句话总结dubbo:
Provider服务提供者，注册到注册中心（zookeeper），Consumer消费者也把要调用的接口注册到注册中心，当消费者调用某A方法的接口时，dubbo监听到，并去注册中心找配置，找到后 底层rpc调用到生产者相应方法接口，调用方法实例返回数据给消费者。其中，monitor控制调用生产者的负载。