Dubbo与微服务

　　http访问到服务器要经过的内容：Nginx —Tomcat –db，nginx就是一个负载均衡左右、又一次面试问到了我nginx的反向代理、现在想了想面试官要问的应该是 域名的反向代理，就是使用一个域名去指定某个端口

　　至于负载均衡就是 可以吧请过过来的 http分不到不同的tomcat上减缓tomcat压力了，然后再说Tomcat 一般开发的服务都是聚合服务，项目很大、项目分模块开发、基本都是这样子

　　比如说、用户模块、单独拿出来做一个服务、放到一个tomcat下、然后商品模块、订单模块、支付模块、等等、这样分开部署、第一能减少tomcat压力、第二：用户模块可能用的比较多、一个tomcat不够 、我可以再加一个、简单方便、而不需要连带着其他模块一起、

　　再到发展后期：一个模块也很庞大了、比如说订单模块，就有了分布式服务、把service层分离、使用dubbo远程调用，这时候就看出dubbo的作用了、书上说调用远程服务就像调用本地服务一样、开发者不需要关注service层逻辑实现了、直接给你个文档告诉你我这个service是干什么用的、然后找一些外包人员、初级人员、专门开发controller、那玩意不用动脑子、那么问题来了 dubbo是怎么做到的呢？ resource文件夹下创建一个spring-dubbo.xml ，在spirng.xml中加入项目启动加载这个dubbo文件的code 　　

　　然后再说下dubbo的配置 ，dubbo有一个provider 和consumer两种文件，一般提供服务方问件是spirng-dubbo-provider.xml

　　provider是配置服务提供方的就是写service逻辑服务上的、 
配置的是

　　<dubbo id="demoService" bean="com.csdn.demo.service.DemoService" ...>

　　…代表还有一些其他配置 
　　这样这个tomcat启动的时候 就会加载这个dubbo文件 dubbo就会加载这个service到dubbo中，然后呢在写controller的服务中、同样需要加入spring-dubbo-consumer.xml这个配置文件

内容也是这个文件

　　<dubbo id="demoService" bean="com.csdn.demo.service.DemoService" ...>

　　在这文件里我们指明了调用dubbo服务的哪个服务

　　在消费者这个服务中、我们只需要写一个service 映射到这个bean就行了 ，然后就可以直接调用里面的方法、就像调用本地服务一样、调用远程服务、

　　然后说一些zookeeper在这其中的作用 ，zookeeper呢一般放在dubbo配置文件中、用以表明dubbo的服务端口 ，利用了zookeeper的分布式、一个挂掉、另一个取代主节点作用、保证服务的稳定性、相关的还有其他的、hadoop中也用到了zookeeper分布式、技术么都是相结合使用的、哪个稳定我们用哪个　　

　　一般我们都会部署三个zookeeper服务节点 ，一个宕机还有两个提供服务　　

　　分布式现如今的发展，下一个节点是spingSource提出的 springcloud，springcloud是基于springboot的 ，相比较dubbo的有点呢 就是 开发简洁 支持restful开发 ，另外springcloud的更新也要比dubbo更新快的多 ，而现如今国内还是使用dubbo的比较多、有中文文档、技术比较成熟了 ，国外使用springcloud比较多 ，springcloud整合了大量的第三方组件、但是优点在于springboot的自动化配置 ，dubbo提供的rpc调用，springcloud支持restful调用：

两种的区别呢？

　　服务提供方与调用方接口依赖方式太强：我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。 服务对平台敏感，难以简单复用：通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。 相信这些痛点也是为什么当当网在dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一。