Dubbo（一） 开始认识Dubbo，分布式服务框架

引言：

以前的车马很慢，一生只够爱一个人
以前的网站人很少，一个单应用服务着一个人
————————————————————
现在，动不动就谈什么高并发，千万级访问。单应用？BOOM！分分钟爆炸。于是，技术随着业务的需求诞生了新的产物。

框架演变：

• 单一应用架构 :所有的功能部署在一个应用中。

• 垂直应用架构 ：将应用拆成互不相干的几个应用，以提升效率。

• 分布式服务架构 ：当垂直应用越来越多，应用之间交互不可避免，此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
  

OK！到此为止，我们今天的主要目标就是分布式服务架构之Dubbo。

在了解Dubbo之前，我们先了解两个概念：

什么是服务框架？
服务框架就是提供服务的，服务框架是基于业务对应SaaS分发模式的服务进行整合，以产生新的应用。服务框架中，与业务相关，但与业务功能的整合无关的组件以外部服务形式引入（也就是说把一些业务分离出来，变成一种服务，供其他人调用该服务）。

什么是RPC？
RPC全拼是（Remote Procedure CallProtocol）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。（理解：远程调用协议，为Dubbo实现远程接口调用做支持）

Dubbo是什么

Dubbo，阿里巴巴的开源框架-分布式框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
简单的说，就是把一个应用分成几份，他负责各份应用之间的通信以及管理。
难道你不知道springCloud吗？
emmm！sprigcloud，I know，spring家族的一大分布式神器，在近两年随着微服务的风靡，他也是一大潮流。但是论目前使用度，springcloud还远远不如老牌的dubbo，而且最近阿里重新开始疯狂维护Dubbo，谁知道他到后面的发展不会比spring好呢？在都是找工作的压力下，还是会点dubbo没毛病吧。

既然你提到了springCloud，那我们也顺便来对比下两者之间的区别吧。

Name	Dubbo	Spring-cloud
OpenSource	Yes	Yes
Source	alibaba,目前已贡献给apache	Spring
Reputation	国内知名度高	国内知名度不高，但依托Sping强大技术体系
文档	完善	完善
社区活跃度	更新慢	比较活跃
架构性	只提供服务治理	提供微服务架构的方方面面功能
分布式配置	可以使用淘宝的diamond、百度的disconf来实现分布式配置管理	pring Cloud中的Config组件除了提供配置管理之外，由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来
服务跟踪	可以使用京东开源的Hydra
批量任务	可以使用当当开源的Elastic-Job
通讯	主RPC，Dubbox支持REST	REST
使用Dubbo的RPC来实现服务间调用的一些痛点	服务提供方与调用方接口依赖方式太强：我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。
	服务对平台敏感，难以简单复用：通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了
1、Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。                     2、而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些          3、所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

上图看得出，dubbo就是对应用做了管理，而springcloud继承了spring一如既往的特点，整合万物。一句话，没有我不整合，只有你用不到的。 当然啦，dubbo那些没有的功能就不能实现吗？NO！只是要自己结合第三方去实现而已。
所以说一句公道话，现在springcloud更具技术代表性，在大部分公司用springcloud的情况下，需要什么也能简单的实现，而dubbo，还得看阿里团队以后的努力。当然！技术流弊的，这些没什么大不了。

Dubbo通信协议

Dubbo这么强大的一个框架，通信协议也肯定十分强大，他支持多种协议，例如：

• Dubbo协议【默认协议】
• Hessian协议
• HTTP协议
• RMI协议
• WebService协议
• Thrift协议
• Memcached协议
• Redis协议

在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。
关于协议的选择，在后面的文章会有讲到，或者参考文章→dubbo多协议选择

Dubbo几大核心要点

1. 服务定义：消费者消费服务者提供的服务。

2. 服务注册：消费者和服务者都需要公开自己的身份，方便被寻找。常用zookeeper注册。

3. 服务监控：对服务状态实时监控，方便改进质量。

4. 远程通信与信息交换：服务者和消费者之间的交流，通过通信协议。

5. 服务调用：消费者从zookeeper上找对服务者，然后享受他的服务。

6. 注册/注销服务：服务者上班，和下班的状态。

7. 服务订阅/取消：消费者按摩和不按摩的状态。

长话短说

那么说了这么多，亲们越看越模糊，感觉博主像个傻逼一样BB了半天，却根本没让我们了解Dubbo，怎么办？
OK！
简单地说，例如
第一步：Dubbo把项目切割开来变成两个，然后项目一（action）留一个接口，告诉zookeeper我是消费者，项目二（service）实现那个接口，告诉zookeeper我是消费者。
第二部：当action被调用走到接口的时候，会去zookeeper询问，我的消费者在哪里啊，然后zookeeper告诉他service的IP地址和端口，找到接口的Impl实现类走完，然后返回给action结果。

没了~入门就这么简单。

至于zookeeper在文中反复提到，他又是什么，在这里透个小底，他是标配的小神器。除了普通的注册之外，他还能提供负载均衡等强大功能，而且添加和移除集群节点非常平滑哦！