为什么用dubbo

#需求

特点
错综复杂的引用关系，配置特别容易出错

#为什么使用不使用开源RPC框架
  跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用，能够支持大部分的语言进行语言无关的调用，非常适合多语言调用场景。但这类框架没有服务发现相关机制，实际使用时需要代理层进行请求转发和负载均衡策略控制。
  国内比较大的互联网公司都会有自己的RPC框架，要不针对每个服务都进行服务发现和负载均衡的处理确实很麻烦。包括：dubbo，基于dubbo扩展的doubbx，微博的Motan RPC，天猫hsf，京东的，聚美优品。

#服务调用的发展过程
##第一阶段：简单集群

特点
1.增加一台ServerM-N都需要配置ServerM-1的集群地址
2.增加一台ServerM-N需要在F5增加一个节点，并且设置检查心跳脚本
3.配置项：
K+2K(N-1)其中：
K：为M-1集群服务F5配置；
2K(N-1)：F5配置其他机器服务K(N-1)，每一层调用上一层K，总计K(N-1)
缺点
F5/Haproxy/Nginx/DNS负载器都一样，一个内部服务需要提供负载均衡，一定要在入口处负载，
1、浪费入口资源;
2、不支持动态部署生效;
3、配置项多，容易出错；
4、完全依懒于设备或者前端软件的负载均衡策略

##第二阶段：集群+服务注册发现

特点
1.增加一个服务中不只需要配置zookeeper地址即可，之间的调用自动发现
2.内部服务不依懒于负载均衡设备，节省负载均衡设备的资源
3.配置项：2K项。
##现实中的情况：服务发现+负载均衡

特点：
1.外网通过DNS负载来做，F5/Nginx/Haproxy做二层负载
2.内网调用复杂，类zookeeper的服务注册管理的来实现
#总结
负载根据自己的业务发展来做，一般小网站在第一个阶段就可以满足很多需求。
#参考文档

http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547134&idx=1&sn=44b97d6a5105498abd7aa3bba406157a&scene=23&srcid=0510CLC9lFT89Y2ESdkbcg58#rd
http://dubbo.io/