以前的车马很慢，一生只够爱一个人
以前的网站人很少，一个单应用服务着一个人
————————————————————
现在，动不动就谈什么高并发，千万级访问。单应用？BOOM！分分钟爆炸。于是，技术随着业务的需求诞生了新的产物。
框架演变：
单一应用架构 :所有的功能部署在一个应用中。
垂直应用架构 ：将应用拆成互不相干的几个应用，以提升效率。
分布式服务架构 ：当垂直应用越来越多，应用之间交互不可避免，此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
OK！到此为止，我们今天的主要目标就是分布式服务架构之Dubbo。
在了解Dubbo之前，我们先了解两个概念：
什么是服务框架？
服务框架就是提供服务的，服务框架是基于业务对应SaaS分发模式的服务进行整合，以产生新的应用。服务框架中，与业务相关，但与业务功能的整合无关的组件以外部服务形式引入（也就是说把一些业务分离出来，变成一种服务，供其他人调用该服务）。
什么是RPC？
RPC全拼是（Remote Procedure CallProtocol）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。（理解：远程调用协议，为Dubbo实现远程接口调用做支持）
Dubbo，阿里巴巴的开源框架-分布式框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
简单的说，就是把一个应用分成几份，他负责各份应用之间的通信以及管理。
难道你不知道springCloud吗？
emmm！sprigcloud，I know，spring家族的一大分布式神器，在近两年随着微服务的风靡，他也是一大潮流。但是论目前使用度，springcloud还远远不如老牌的dubbo，而且最近阿里重新开始疯狂维护Dubbo，谁知道他到后面的发展不会比spring好呢？在都是找工作的压力下，还是会点dubbo没毛病吧。
既然你提到了springCloud，那我们也顺便来对比下两者之间的区别吧。
上图看得出，dubbo就是对应用做了管理，而springcloud继承了spring一如既往的特点，整合万物。一句话，没有我不整合，只有你用不到的。 当然啦，dubbo那些没有的功能就不能实现吗？NO！只是要自己结合第三方去实现而已。
所以说一句公道话，现在springcloud更具技术代表性，在大部分公司用springcloud的情况下，需要什么也能简单的实现，而dubbo，还得看阿里团队以后的努力。当然！技术流弊的，这些没什么大不了。 Dubbo通信协议
Dubbo这么强大的一个框架，通信协议也肯定十分强大，他支持多种协议，例如：
Dubbo协议【默认协议】
Hessian协议
HTTP协议
RMI协议
WebService协议
Thrift协议
Memcached协议
Redis协议
在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。
关于协议的选择，在后面的文章会有讲到，或者参考文章→dubbo多协议选择
服务定义：消费者消费服务者提供的服务。
服务注册：消费者和服务者都需要公开自己的身份，方便被寻找。常用zookeeper注册。
服务监控：对服务状态实时监控，方便改进质量。
远程通信与信息交换：服务者和消费者之间的交流，通过通信协议。
服务调用：消费者从zookeeper上找对服务者，然后享受他的服务。
注册/注销服务：服务者上班，和下班的状态。
服务订阅/取消：消费者按摩和不按摩的状态。
长话短说那么说了这么多，亲们越看越模糊，感觉博主像个傻逼一样BB了半天，却根本没让我们了解Dubbo，怎么办？
OK！
简单地说，例如
第一步：Dubbo把项目切割开来变成两个，然后项目一（action）留一个接口，告诉zookeeper我是消费者，项目二（service）实现那个接口，告诉zookeeper我是消费者。
第二部：当action被调用走到接口的时候，会去zookeeper询问，我的消费者在哪里啊，然后zookeeper告诉他service的IP地址和端口，找到接口的Impl实现类走完，然后返回给action结果。
没了~入门就这么简单。