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网关中配置映射关系和权限控制就可实现服务的复用了
一、Dubbo实现了服务治理的基础，可是要完成一个完备的微服务架构，还须要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增长出来的压力，这样才能让各环节人员真正的专一于业务逻辑。                     二、而Spring Cloud依然发扬了Spring Source整合一切的做风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特色，让本来复杂的架构工做变得相对容易上手一些          三、因此，若是选择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在文中反复提到，他又是什么，在这里透个小底，他是标配的小神器。除了普通的注册以外，他还能提供负载均衡等强大功能，并且添加和移除集群节点很是平滑哦！