职场打拼那些事？

作为程序员，当然是不断学习，才能使自己慢慢变强大！

在无数个“撑不下去”的时候，我的“治愈系”当然也是学习了！

之前有人问我，你用过dubbo吗？嗯，额，我说，没了解过。

那你知道SpringCloud吗？嗯，额，我说，我听说过，好像是微服务用到的一种技术框架。

哎，为了下次有人跟我聊起dubbo，我能不再像便秘一样，嗯……额……于是，我决定学习dubbo！先去B站看了视频，然后网上找来资料，终于把dubbo是什么以及怎么用了解清楚了。今天就把新学的dubbo的那些事和大家一起探讨一下。

Dubbo是什么

Dubbo是一个分布式、高性能、透明化的RPC服务框架，提供服务自动注册、自动发现等高效服务治理方案，可以和Spring框架无缝集成。

这句话有5个点要掌握：

  1. 分布式：即应用场景是系统拆分，A系统和B系统需要通讯的情况下，需要一个RPC框架；
  2. 高性能：要支持集群、负载均衡及容错机制；
  3. 透明化：即远程方法调用，就像调用本地方法一样，只需简单配置，没有任何API侵入；
  4. 自动注册：默认使用zookeeper，提供：配置维护、域名服务、分布式同步、组服务等；
  5. 服务治理：这个原理有些抽象，我还没了解透，先不说了。

Dubbo的主要应用场景

透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。(F5负载均衡器我也是百度来的)。

服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo服务注册与发现的流程

这张图是在dubbo官网上下载的：




dubbo nacos接口级注册_dubbo yml配置


流程说明：

0.Provider(提供者)绑定指定端口并启动服务；

1.提供者连接注册中心，并发送本机IP、端口、应用信息和提供服务信息至注册中心存储；

2.Consumer(消费者)，订阅注册中心 ，并发送应用信息、所求服务信息至注册中心；

3.注册中心根据消费者所求服务信息匹配对应的提供者列表发送至Consumer应用缓存。

4.Consumer在发起远程调用时基于缓存的提供者列表择其一发起调用；

5.消费者调用服务次数count等信息，定时发送到监控中心用于监控。

注意两点：

第3步，Provider状态变更会实时通知注册中心、注册中心是基于长连接推送变更给Consumer。

注册中心始终不代替调用者发送请求到服务提供者，它只是告诉调用者服务方地址，调用方根据具体地址请求服务，即第4步的invoke。

思考：Dubbo的注册中心集群挂掉，发布者和订阅者之间还能通信么？

答案是：可以的。

因为启动dubbo时，消费者会从zookeeper拉取注册的生产者的地址接口等数据，缓存在本地。实际上每次调用时，都是按照本地缓存中存储的地址进行调用，此时并没有用到注册中心。

所以说注册中心集群全部挂掉是不要紧的，但前提是服务提供者没有增加新的服务，如果要调用新的服务，本地缓存是办不到的。

Dubbo有些哪些注册中心？

  • Multicast注册中心： Multicast注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现。
  • Zookeeper注册中心： 基于分布式协调系统Zookeeper实现，采用Zookeeper的watch机制实现数据变更。这种也是dubbo默认采用的注册中心。
  • redis注册中心： 基于redis实现，采用key/Map存储，住key存储服务名和类型，Map中key存储服务URL，value服务过期时间。基于redis的发布/订阅模式通知数据变更。
  • Simple注册中心。

Dubbo的集群容错方案有哪些？

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试

  • Failover Cluster：失败自动切换，当出现失败，在地址列表中重试其它服务器。通常用于读操作，但重试会带来更长延迟。
  • Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
  • Failsafe Cluster：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作
  • Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
  • Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
  • Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。

Dubbo和Spring Cloud的区别？

提到Dubbo，一般都会和Spring Cloud作比较，因为他们两个都能解决RPC问题。Dubbo是一个分布式服务框架，而SpringCloud是一个分布式的整体解决方案。两者区别如下：


dubbo nacos接口级注册_zookeeper_02


Dubbo和SpringCloud最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。

而SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。

SpringBoot整合Dubbo和Zookeeper如何开发

1)、服务提供者：

1.创建一个服务提供者provider

2.引入dubbo和zookeeper依赖

org.apache.dubbo        dubbo-spring-boot-starter        2.7.7com.github.sgroschupf    zkclient    0.1

3.在application.yml中配置dubbo的扫描包和注册中心地址(zookeeper我用的是公司服务，具体安装启用这里不做介绍)：

Dubbo.application.name=ticket#地址写zookeeper服务地址，我用的公司的服务，这里随便写一下Dubbo.registery.address=zookeeper://127.0.0.1:2181Dubbo.scan.base.package=com.bill99.ticket.service

4.将provider注册到注册中心zookeeper中，provider的服务提供者添加dubbo的@service注解

public interface TicketService{public String getTicket();}@Component//注册到Spring容器中@Service//注意是dubbo的Service，不是Spring的Servicepublic class TicketServiceImpl implements TicketService{@Overridepublic String getTicket() {return "《八佰》";}}

2)、调用方：

1.创建一个客户端consumer，和provider一样，引入dubbo和zookeeper依赖

2.consumer引用服务，添加@Reference注解

@Servicepublic class UserService{@Referenceprivate TicketService ticketService;//注意：前面说dubbo对代码有强依赖，就是指这里  //实际应用中provider和consumer是在两个工程，那么两边都必须有相同类路径的TicketService接口public void hello(){System.out.println("买到票了，"+ticketService.getTicket());}}

3.在application.yml中配置注册中心地址

Dubbo.application.name=userDubbo.registery.address=zookeeper://127.0.0.1:2181

3)、编写测试类，调用UserService.hello()方法。

完结撒花！！！

#程序员##Dubbo#