springBoot+Dubbo+Zookerper相关注解和核心知识点，作为程序员你必须知道！
@component （把普通pojo实例化到spring容器中，相当于配置文件中的
泛指各种组件，就是说当我们的类不属于各种归类的时候（不属于@Controller、@Services等的时候），我们就可以使用@Component来标注这个类。
@SpringBootConfiguration继承自@Configuration，二者功能也一致，标注当前类是配置类，并会将当前类内声明的一个或多个以@Bean注解标记的方法的实例纳入到srping容器中，并且实例名就是方法名。
@EnableAutoConfiguration的作用启动自动的配置，@EnableAutoConfiguration注解的意思就是Springboot根据你添加的jar包来配置你项目的默认配置，比如根据spring-boot-starter-web ，来判断你的项目是否需要添加了webmvc和tomcat，就会自动的帮你配置web项目中所需要的默认配置。在下面博客会具体分析这个注解，快速入门的demo实际没有用到该注解。
@ComponentScan，扫描当前包及其子包下被@Component，@Controller，@Service，@Repository注解标记的类并纳入到spring容器中进行管理。是以前的
@Aspect
作用是把当前类标识为一个切面供容器读取
切入点指示符用来指示切入点表达式目的，，在Spring AOP中目前只有执行方法这一个连接点，Spring AOP支持的AspectJ切入点指示符如下：
execution：用于匹配方法执行的连接点；
@Around定义了此方法为 Around增强处理方法；
@annotation(around)：参数around应该与增强处理方法中的参数名保持一致，该声明指定了pointcut连接点，也可以使用其他方式。
@Configuration标注在类上，相当于把该类作为spring的xml配置文件中的
@Configuration启动容器+@Bean注册Bean，@Bean下管理bean的生命周期
@Bean标注在方法上(返回某个实例的方法)，等价于spring的xml配置文件中的
@Bean 支持两种属性，即 initMethod 和destroyMethod，这些属性可用于定义生命周期方法。
@Conditional(TestCondition.class)
这句代码可以标注在类上面，表示该类下面的所有@Bean都会启用配置，也可以标注在方法上面，只是对该方法启用配置。
spring框架还提供了很多@Condition给我们用
@ConditionalOnBean（仅仅在当前上下文中存在某个对象时，才会实例化一个Bean）
@ConditionalOnClass（某个class位于类路径上，才会实例化一个Bean）
@ConditionalOnExpression（当表达式为true的时候，才会实例化一个Bean）
@ConditionalOnMissingBean（仅仅在当前上下文中不存在某个对象时，才会实例化一个Bean）
@ConditionalOnMissingClass（某个class类路径上不存在的时候，才会实例化一个Bean）
@ConditionalOnNotWebApplication（不是web应用）
@ConditionalOnClass：该注解的参数对应的类必须存在，否则不解析该注解修饰的配置类；
@ConditionalOnMissingBean：该注解表示，如果存在它修饰的类的bean，则不需要再创建这个bean；可以给该注解传入参数例如@ConditionOnMissingBean(name = "example")，这个表示如果name为“example”的bean存在，这该注解修饰的代码块不执行。
1.通过@PropertySource注解将properties配置文件中的值存储到Spring的 Environment中，Environment接口提供方法去读取配置文件中的值，参数是properties文件中定义的key值。
2.2 用法2-通过Environment设置
指定dubbo扫描路径
注意 @DubboComponentScan(basePackages = "com.wang.test.service.impl") 填写接口实现类的包名
@RabbitListener 用法
-
使用 @RabbitListener 注解标记方法，当监听到队列 debug 中有消息时则会进行接收并处理
@RabbitListener 和 @RabbitHandler 搭配使用
-
@RabbitListener 可以标注在类上面，需配合 @RabbitHandler 注解一起使用
-
@RabbitListener 标注在类上面表示当有收到消息的时候，就交给 @RabbitHandler 的方法处理，具体使用哪个方法处理，根据 MessageConverter 转换后的参数类型
从Java EE5规范开始，Servlet增加了两个影响Servlet生命周期的注解（Annotation）：@PostConstruct和@PreConstruct。这两个注解被用来修饰一个非静态的void()方法.而且这个方法不能有抛出异常声明。
dubbo原理
3.Dubbo的主要应用场景？
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo系统分为五个部分：远程服务运行容器（Container），远程服务提供方（Provider）、注册中心（Register）、远程服务调用者（Consumer）、监控中心（Monitor）。
Dubbo服务调用过程：
流程说明：
Provider(提供者)绑定指定端口并启动服务
指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储
Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心
注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。
Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。
Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer
设计的原因：
Consumer 与Provider 解偶，双方都可以横向增减节点数。
注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台
去中心化，双方不直接依懒注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用
服务提供者无状态，任意一台宕掉后，不影响使用。
Dubbo支持哪些协议，每种协议的应用场景，优缺点？
dubbo： 单一长连接和NIO异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议TCP，异步，Hessian序列化；
rmi： 采用JDK标准的rmi协议实现，传输参数和返回参数对象需要实现Serializable接口，使用java标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议TCP。 多个短连接，TCP协议传输，同步传输，适用常规的远程服务调用和rmi互操作。在依赖低版本的Common-Collections包，java序列化存在安全漏洞；
webservice： 基于WebService的远程调用协议，集成CXF实现，提供和原生WebService的互操作。多个短连接，基于HTTP传输，同步传输，适用系统集成和跨语言调用；
http： 基于Http表单提交的远程调用协议，使用Spring的HttpInvoke实现。多个短连接，传输协议HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器JS调用；
hessian： 集成Hessian服务，基于HTTP通讯，采用Servlet暴露服务，Dubbo内嵌Jetty作为服务器时默认实现，提供与Hession服务互操作。多个短连接，同步HTTP传输，Hessian序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；
memcache： 基于memcached实现的RPC协议
redis： 基于redis实现的RPC协议
11.Dubbo有些哪些注册中心？
Multicast注册中心： Multicast注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现；
Zookeeper注册中心： 基于分布式协调系统Zookeeper实现，采用Zookeeper的watch机制实现数据变更；
redis注册中心： 基于redis实现，采用key/Map存储，住key存储服务名和类型，Map中key存储服务URL，value服务过期时间。基于redis的发布/订阅模式通知数据变更；
Simple注册中心
12.Dubbo默认采用注册中心？
采用Zookeeper。
14.Dubbo的注册中心集群挂掉，发布者和订阅者之间还能通信么？
可以的，启动dubbo时，消费者会从zookeeper拉取注册的生产者的地址接口等数据，缓存在本地。
每次调用时，按照本地存储的地址进行调用。
15.Dubbo与Spring的关系？
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
16.Dubbo使用的是什么通信框架?
默认使用NIO Netty框架
17.Dubbo集群提供了哪些负载均衡策略？
Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；
RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题；
LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
ConstantHash LoadBalance: 一致性Hash策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动；
18.Dubbo的集群容错方案有哪些？
Failover Cluster
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。
21.Dubbo超时时间怎样设置？
Dubbo超时时间设置有两种方式：
服务提供者端设置超时时间，在Dubbo的用户文档中，推荐如果能在服务端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。
服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会定制，会产生警告。
22.服务调用超时问题怎么解决？
dubbo在调用服务不成功时，默认是会重试两次的。
23.Dubbo在安全机制方面是如何解决？
Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。
25.Dubbo和Spring Cloud的关系？
Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。
服务提供方（Provider）所在的应用在容器中启动并运行（这个容器可以说是该应用部署的tomcat）
服务提供方（Provider）将自己要发布的服务注册到注册中心（Registry）
服务调用方（Consumer）启动后向注册中心订阅它想要调用的服务
注册中心（registry）存储着Provider注册的远程服务，并将其所管理的服务列表通知给服务调用方（Consumer），且注册中心和提供方和调用方之间均保持长连接，可以获取Provider发布的服务的变化情况，并将最新的服务列表推送给Consumer
Consumer根据从注册中心获得的服务列表，根据软负载均衡算法选择一个服务提供者（Provider）进行远程服务调用，如果调用失败则选择另一台进行调用。（Consumer会缓存服务列表，即使注册中心宕机也不妨碍进行远程服务调用）
监控中心（Monitor）对服务的发布和订阅进行监控和统计服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（Monitor）;Monitor可以选择Zookeeper、Redis或者Multiast注册中心等，后序介绍。
Dubbo可以用Zookeeper作为注册中心，存储Provider注册的远程服务信息。
Zookeeper采用树形的目录结构来存储信息。
服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地 址
服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地 址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址
监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地 址。
支持以下功能：
当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
当注册中心重启时，能自动恢复注册数据，以及订阅请求
当会话过期时，能自动恢复注册数据，以及订阅请求
当设置
可通过设置
可通过
支持 * 号通配符
4.Dubbo + Redis
Redis是一个基于内存的，以Key-Value形式存储数据的高性能Nosql数据库，可以用来存储远程服务信息用作注册中心
使用 Redis 的 Key—Map 结构存储数据结构：
主键 Key 为服务名和服务类型：比如./dubbo/com.foo.BarService/providers或./dubbo/com.foo.BarService/providers，相当于Zookeeper中的第三层目录
值 Map 中的 Key 为 URL 地址 ，Map 中的 Value 为过期时间，用于判断脏数据，脏数据由监控中心删除
使用 Redis 的 Publish/Subscribe 事件通知数据变更：
通过事件的值区分事件类型： register , unregister , subscribe , unsubscribe
普通消费者直接订阅指定服务提供者的 Key，只会收到指定服务的 register , unregister 事件
监控中心通过 psubscribe 功能订阅 /dubbo/* ，会收到所有服务的所有变更事件
调用过程：
服务提供方启动时，向 Key:/dubbo/com.foo.BarService/providers 下，添加当前提供者的地址， 并向 Channel:/dubbo/com.foo.BarService/providers 发送 register 事件
服务消费方启动时，从 Channel:/dubbo/com.foo.BarService/providers 订阅 register 和 unregister 事件 ， 并向 Key:/dubbo/com.foo.BarService/providers 下，添加当前消费者的地址
服务消费方收到 register 和 unregister 事件后，从 Key:/dubbo/com.foo.BarService/providers 下获取提供者地址列表
服务监控中心启动时，从 Channel:/dubbo/* 订阅 register 和 unregister ，以及subscribe 和 unsubsribe 事件
服务监控中心收到 register 和 unregister 事件后，从 Key:/dubbo/com.foo.BarService/providers 下获取提供者地址列表
服务监控中心收到 subscribe 和 unsubsribe 事件后，从 Key:/dubbo/com.foo.BarService/consumers 下获取消费者地址列表