dubbo专注于服务治理，Dubbo是RPC的一种实现
本课重点：
SPI扩展机制 注解方式和xml方式 Service和Reference 缓存 异步调用 路由规则

疑问：
1、SOA（面向服务的架构）和微服务架构有什么区别?
2、引入的jar包完全相同，是通过Service还是Reference来区分是消费端还是服务提供者端的吗？
3、为什么负载均衡可以在客户端做，也可以在服务端做？
4、路由规则中，condition后面的ip、=>前面的ip、=>后面的ip，具体是怎么剔除的？
5、单例模式，什么时候用懒汉式，什么时候用饿汉式？
懒汉式虽然可能有问题，但应该还是有使用场景的吧，看dubbo的源码里面用到了懒汉式。

变化：
1、服务提供者和消费者都要向注册中心注册自己。

0 拉勾讲义

重试：

1. 注意提供者是否有幂等，否则可能出现数据一致性问题
2. 注意提供者是否有类似缓存机制，如出现大面积错误时，可能因为不停重试导致雪崩

Dubbo处理流程

虚线——异步调用
实线——同步访问
蓝色虚线—— 是在启动时完成的功能
红色虚线——程序运行中执行的功能
Provider：暴露服务的服务提供方
Consumer： 调用远程服务的服务消费方
Registry： 服务注册与发现的注册中心
Monitor： 统计服务的调用次数和调用时间的监控中心
Container： 服务运行容器 负责启动 加载 运行服务提供者

调用流程:
服务提供者在服务容器启动时 向注册中心 注册自己提供的服务
服务消费者在启动时 向注册中心订阅自己所需的服务
注册中心返回服务提供者地址列表给消费者 如果有变更 注册中心会基于长连接推送变更数据给消费者
服务消费者 从提供者地址列表中 基于软负载均衡算法 选一台提供者进行调用 如果调用失败 则重新选择一台
服务提供者和消费者 在内存中的调用次数 和 调用时间 定时每分钟发送给监控中心

Dubbo管理控制台 dubbo-admin（从github下载,启动）
作用：服务管理 、 路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能

SPI (Service Provider Interface) :是一种动态替换实现的机制。使用SPI机制的优势是实现解耦，使得第三方服务模块的装配控制逻辑与调用者的业务代码分离。

jdk的SPI遵循如下约定：
1、当服务提供者提供了接口的一种具体实现后，在META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
2、接口实现类所在的jar包放在主程序的classpath中；
3、主程序通过java.util.ServiceLoader动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名，把类加载到JVM；
4、SPI的实现类必须携带一个无参构造方法；

dubbo自己做SPI的目的

1. JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源
2. 如果有扩展点加载失败，则所有扩展点无法使用
3. 提供了对扩展点包装的功能(Adaptive)，并且还支持通过set的方式对其他的扩展点进行注入

Dubbo中的Adaptive功能，主要解决的问题是如何动态的选择具体的扩展点。通过
getAdaptiveExtension 统一对指定接口对应的所有扩展点进行封装，通过URL的方式对扩展点来进行
动态选择。 (dubbo中所有的注册信息都是通过URL的形式进行处理的。)这里同样采用相同的方式进行实现。

Dubbo的Filter机制
是专门为服务提供方和服务消费方调用过程进行拦截设计的，每次远程方法执行，该拦截都会被执行。这样就为开发者提供了非常方便的扩展性，比如为dubbo接口实现ip白名单功能、监控功能 、日志记录等。

1 配置dubbo

1.1 xml配置

配置之间的关系 dubbo-config
标签 用途 解释
<dubbo:service/> 服务配置 用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心
<dubbo:reference/> 引用配置 用于创建一个远程服务代理，一个引用可以指向多个注册中心
<dubbo:protocol/> 协议配置 用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受
<dubbo:application/>应用配置 用于配置当前应用信息，不管该应用是提供者还是消费者
<dubbo:module/> 模块配置 用于配置当前模块信息，可选
<dubbo:registry/>注册中心配置 用于配置连接注册中心相关信息
<dubbo:monitor/> 监控中心配置 用于配置连接监控中心相关信息，可选
<dubbo:provider/> 提供方配置 当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选
<dubbo:consumer/>消费方配置 当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选
<dubbo:method/> 方法配置 用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息
<dubbo:argument/> 参数配置 用于指定方法参数配置

配置覆盖关系
以 timeout 为例，显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似：

• 方法级优先，接口级次之，全局配置再次之。
• 如果级别一样，则消费方优先，提供方次之。
• 其中，服务提供方配置，通过 URL 经由注册中心传递给消费方。
  理论上 ReferenceConfig 的非服务标识配置，在 ConsumerConfig，ServiceConfig, ProviderConfig 均可以缺省配置。
  注意：只有 group，interface，version 是服务的匹配条件，三者决定是不是同一个服务，其它配置项均为调优和治理参数。

1.2 dubbo.properties属性配置

如果公共配置很简单，没有多注册中心，多协议等情况，或者想多个 Spring 容器想共享配置，可以使用 dubbo.properties 作为缺省配置。一般情况下 properties 都是用来配置一些公共的信息，比如可能一个应用需要调用多个注册中心的服务，这时候它们的 application.name、dubbo.protocol.name等都是相同的，那么你可以用 properties 来配置这些公共信息。

Dubbo 将自动加载 classpath 根目录下的 dubbo.properties，可以通过JVM启动参数 -Ddubbo.properties.file=xxx.properties 改变缺省配置位置。

映射规则
将 XML 配置的标签名，加属性名，用点分隔，多个属性拆成多行

• 比如：dubbo.application.name=foo等价于<dubbo:application name="foo" />
• 比如：dubbo.registry.address=10.20.153.10:9090等价于<dubbo:registry address="10.20.153.10:9090" />

如果 XML 有多行同名标签配置，可用 id 号区分，如果没有 id 号将对所有同名标签生效

• 比如：dubbo.protocol.rmi.port=1234等价于<dubbo:protocol id="rmi" name="rmi" port="1099" />
• 比如：dubbo.registry.china.address=10.20.153.10:9090等价于<dubbo:registry id="china" address="10.20.153.10:9090" />

覆盖策略

1. JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。
2. XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。
3. Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

Dubbo提供的线程池策略(from 链接1)
扩展接口 ThreadPool 的SPI实现有如下几种：

1. fixed：固定大小线程池，启动时建立线程，不关闭，一直持有（缺省）。
2. cached：缓存线程池，空闲一分钟自动删除，需要时重建。
3. limited：可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然带来大流量引起性能问题。

链接：
0、dubbo概述
1、[dubbo线程池]（https://www.cnblogs.com/xhj123/p/9095278.html）
2、[dubbo中的url]（https://www.cnblogs.com/Cubemen/p/12312981.html）
3、dubbo中的路由规则
4、dubbo中的spi系列
5、dubbo的四种配置系列~
6、dubbo中的url、invoker、invocation概念
7、[dubbo支持的9种协议]（https://blog.csdn.net/xiaojin21cen/article/details/79834222）