微服务治理框架-Dubbo

众所周知，服务与服务之间的远程通信是分布式架构最基本的组成部分，传统意义上的远程通信，更多的时候是解决信息孤岛及数据互联与通问题的，它主要关注的是数据的共享。随着SOA生态的不断完善以及微服务架构思想的落地，服务与服务之间的远程通信需求更多来自服务的解耦。同时，业务规模的不断增长会使得微服务数量增加，那么问题也就随之产生了，比如:

• 如何协调线上运行的服务，以及保障服务的高可用性
• 如何根据不同服务的访问情况来合理地调控服务器资源，提高机器的利用率。
• 线上出现故障时，如何动态地对故障业务做降级、流量控制等。
• 如何动态地更新服务中的配置信息，比如限流闻值、降级开关等
• 如何实现大规模服务集群所带来的服务地址的管理和服务上下线的动态感知

为了解决这些问题，就需要一个统一的服务治理框架对服务进行统一、有效的管控，从而保障服务的高效、健康运行，而Dubbo就是一个这样的框架。

一 、1如何理解Apache Dubbo

ApacheDubbo是一个分布式服务框架，主要实现多个系统之间的高性能、透明化调用，简单来说它就是个RPC框架，但是和普通的RPC框架不同的是，它提供了服务治理功能，比如服务注册、监控、路由、容错等。
促使Apache Dubbo框架产生的原因有两个:

• 在大规模服务化之后，服务越来越多，服务消费者在调用服务提供者的服务时，需要在配置文件中维护服务提供者的URL地址，当服务提供者出现故障或者动态扩容时，所有相关的服务消费者都需要更新本地配置的URL地址，这种维护成本非常高。这个时候，实现服务的上下动态线感知及服务地址的动态维护就显得非常重要了。
• 随着用户的访问量增大，后端服务为了支撑更大的访问量，会通过增加服务器来扩容。但是，哪些服务要扩容，哪些服务要缩容，需要一个判断依据，也就是说需要知道每个服务的调用量及响应时间，这个时候，就需要有一种监控手段，使用监控的数据作为容量规划的参考值，从而实现根据不同服务的访问情况来合理地调控服务器资源，提高机器的利用率。

二 、Apache Dubbo实现远程通信

创建两个普通的Maven工程，分别为order-service和user-service，代表订单服务和用户服务，这两个服务之间在实际业务场景中会存在相互依赖的情况，比如订单服务中的某个功能可能需要查询用户信息时，就需要调用用户服务指定的接口来完成。

2.1 user-service的实现流程

• 创建配置文件resources/META-INF/spring/user-providerxml，把服务发布到网络上，让其他进程可以访问。因为Dubbo采用了Spring配置的扩展来实现透明化的服务发布和服务消费，所以它的配置基本上和以往通过XML形式描述Bean差不多。
  • dubbo:application用来描述提供方的应用信息，比如应用名称、维护人版本等，其中应用名称是必填项。开发者或者运维人员可以通过监控平台查看这些信息来更快速地定位和解决问题。
  • dubbo:registry 配置注册中心的地址，如果不需要注册中心，可以设置为N/A。Dubbo支持多种注册中心，比如ZooKeeper、Nacos等。
  • dubbo:protocol配置服务提供者的协议信息，Dubbo支持多种协议来发布服务，默认采用Dubbo协议，可选的协议有很多，比如HessianWebservice、Thrift等。这意味着如果公司之前采用的协议是Webservice，想切换到Dubbo上来，几乎没有太大的迁移成本
  • dubbo:service描述需要发布的服务接口，也就是这个接口可供本网络上的其他进程访问interface表示定义的接口，ref表示这个接口的实现。
    
• 加载Spring的XML文件，可以通过ClassPathXmApplicationContext来完成加载启动的过程，也可以通过Mainmain(args)来启动。两者在本质上没有区别，只是Dubbo做了一层封装，简化了开发者的使用。
• 启动之后，可以在控制台的日志中看到如下信息，说明服务已经发布成功，而且还打印了Dubbo发布的地址dubbo://19216813.1:20880/comgupaoedu.bookdubboUserService，这个地址是一个远程通信地址，服务调用者可以基于该地址来访问该服务完成远程通信的流程。

2.2 order-servce的实现流程

order-service的实现流程比较简单，大部分配置是相同的

• 添加user-api和Dubbo的Maven依赖，前者是用户访问IUserService接口的方法，后者通过远程代理完成远程通信过程。
  
  
  

三 Spring Boot集成Apache Dubbo

Apache Dubbo不需要依赖Spring Boot也是可以实现微服务的，集成到Spring Boot的好处是可以享受到Spring Boot生态的框架和技术支持，也就是基于Spring Boot实现了标准化，并统一了开发部署、运维的形态。在2015年的时候，笔者所在公司就开始以Spring Boot集成Dubbo来实现微服务，不过，那时候整个生态没有现在这么成熟。现在，咱们可以使用Dubbo Spring Boot组件轻松集成，它整合了Spring Boot的自动装配健康检查、外部化配置等功能。接下来通过一个案例来简单演示基于Spring Boot构建的Dubbo使用过程。

3.1 服务提供者开发流程

3.2 服务调用者的开发流程

服务调用者的开发流程相对来说也很简单

• 创建一个Spring Boot项目springboot-consumer，添加Jar包依赖
  
  

五、Apache Dubbo集成ZooKeeper实现服务注册

大规模服务化之后，在远程RPC通信过程中，会遇到两个比较尖锐的问题:

• 服务动态上下线感知。
• 负载均衡。

服务动态上下线感知，就是服务调用者要感知到服务提供者上下线的变化。按照以往传统的形式，服务调用者如果要调用服务提供者，必须要知道服务提供者的地址信息及映射参数。以Webservice为例，服务调用者需要在配置文件中维护一个http://ipport/service?wsdl地址，但是如果服务提供者是一个集群节点，那么服务调用者需要维护多个这样的地址。问题来了，一旦服务提供者的IP故障或者集群中某个节点下线了，服务调用者需要同步更新这些地址，但是这个操作如果人工来做是不现实的，所以需要一个第三方软件来统一管理服务提供者的URL地址，服务调用者可以从这个软件中获得目标服务的相关地址，并且第三方软件需要动态感知服务提供者状态的变化来维护所管理的URL，进而使得服务调用者能够及时感知到变化而做出相应的处理。

负载均衡这个概念大家都熟悉，就是当服务提供者是由多个节点组成的集群环境时，服务调用者需要通过负载均衡算法来动态选择一台目标服务器进行远程通信。负载均衡的主要目的是通过多个节点的集群来均衡服务器的访问压力，提升整体性能。实现负载均衡的前提是，要得到目标服务集群的所有地址，在服务调用者端进行计算，而地址的获取也同样依赖于第三方软件

第三方软件的主要功能其实就是服务注册和发现，如图4-4所示，可以看到引入服务注册中心后服务调用者和服务提供者之间的访问变化。Apache Dubbo支持多种注册中心，比如ZooKeeper、Nacos、Redis等。在开源版本中，官方推荐使用的注册中心是ZooKeeper，所以使用Apache Dubbo的公司大部分都用ZooKeeper来实现服务注册和发现，在本节中会简单介绍ZooKeeper，后续章节会详细分析Nacos。

5.1 ApacheDubbo集成ZooKeeper实现服务注册的步骤

由于Dubbo的关系，大家最早认识的ZooKeeper用于实现服务的注册和发现。在初步了解了ZooKeeper的特性之后，我们就可以将ZooKeeper集成进来实现Dubbo服务的注册和动态感知。还是以Spring Boot集成ApacheDubbo的案例作为演示，完整代码请去笔者提供的GitHub地址下载
在这个案例中，只需要非常简单的几个步骤就能完成服务注册的功能。

• 在springboot-provider项目的sample-provider模块中添加ZooKeeper相关依赖，其中curator-framework和curator-recipes是ZooKeeper的开源客户端
  

5.2 ZooKeeper注册中心的实现原理

Dubbo服务注册到ZooKeeper上之后，可以在ZooKeeper服务器上看到如图4-5所示的树形结构。当Dubbo服务启动时，会去Zookeeper服务上的/dubbo/com.gupaoedu.bookdubboIHelloService/providers目录下创建当前服务的URL，其中com.gupaoedu.bookdubbo.IHelloService是发布服务的接口全路径名称，providers表示服务提供者的类型，dubbo://ip;port表示该服务发布的协议类型及访问地址。其中，URL是临时节点，其他皆为持久化节点。在这里使用临时节点的好处在于，如果注册该节点的服务器下线了，那么这个服务器的URL地址就会从ZooKeeper服务器上被移除。

当Dubbo服务消费者启动时，会对/dubbo/com.gupaoedubookdubboIHelloService/providers节点下的子节点注册Watcher监听，这样便可以感知到服务提供方节点的上下线变化，从而防止请求发送到已经下线的服务器造成访问失败。同时，服务消费者会在dubbo/com.gupaoedu.bookdubbo.IHelloService/consumers下写入自己的URL，这样做的目的是可以在监控平台上看到某个Dubbo服务正在被哪些服务调用。最重要的是Dubbo服务的消费者如果需要调用IHelloService服务，那么它会先去/dubbo/com.gupaoedu.book.dubboIHelloService/providers路径下获得所有该服务的提供方URL列表，然后通过负载均衡算法计算出一个地址进行远程访问。

整体来看，服务注册和动态感知的功能用到了ZooKeeper中的临时节点、持久化节点、Watcher等，回过头看前面分析的ZooKeeper的应用场景可以发现，几乎所有的场景都是基于这些来完成的。另外，不得不提的是Dubbo还可以针对不同的情况来实现以下功能

• 基于临时节点的特性，当服务提供者宕机或者下线时，注册中心会自动删除该服务提供者的信息。
• 注册中心重启时，Dubbo能够自动恢复注册数据及订阅请求
• 为了保证节点操作的安全性，ZooKeeper提供了ACL权限控制，在Dubbo中可以通过dubbo.registry.username/dubbo.registry.password设置节点的验证信息
• 注册中心默认的根节点是/dubbo，如果需要针对不同环境设置不同的根节点，可以使用dubbo.registry.group修改根节点名称。

六、实战Dubbo Spring Cloud

SpringCloud为Java环境中解决微服务问题提供了非常完整的方案，所以在最近几年时间，Spring Cloud成了很多公司首选的技术方案。但是随着运用规模的扩大，Spring Cloud在服务治理领域的局限性逐步显露出来相对来说，在服务治理方面，Apache Dubbo有着非常大的优势，并且在Spring Cloud出现之前，它就已经被很多公司作为服务治理及微服务某础设施的首选框架。Dubbo Spring Cloud的出现，使得Dubbo既能够完全整合到Spring Cloud的技术栈中，享受Spring Cloud生态中的技术支持和标准化输出，又能够弥补Spring Cloud中服务治理这方面的短板

Dubbo Spring Cloud是Spring Cloud Alibaba的核心组件，它构建在原生的Spring Cloud标准之上，不仅覆盖了SpringCloud原生特性，还提供了更加稳定和成熟的实现。接下来，我们就通过一个案例来了解DubboSpring Cloud。

6.1实现Dubbo服务提供方

创建一个普通的Maven工程，并在该工程中创建两个模块:spring-cloud-dubbo-sample-apispring-cloud-dubbo-sample-provider。其中spring-cloud-dubbo-sample-api是一个普通的Maven工程，springcloud-dubbo-sample-provider是一个Spring Boot工程细心的读者应该会发现，对于服务提供者而言，都会存在一个API声明，因为服务的调用者需要访问服务提供者声明的接口，为了确保契约的一致性，Dubbo官方推荐的做法是把服务接口打成Jar包发布到仓库上。服务调用者可以依赖该Jar包，通过接口调用方式完成远程通信。对于服务提供者来说，也需要依赖该Jar包完成接口的实现。

6.2 实现Dubbo服务调用方

Dubbo服务提供方spring-doud-dubbo-sample已经准备完毕，只需要创建一个名为spring-cloud-dubbo-consumer的Spring Boot项目，就可以实现Dubbo服务调用了。

• 创建一个名为spring-cloud-dubbo-consumer的Spring Boot工程，添加如下依赖，与服务提供方所依赖的配置没什么区别。为了演示需要，增加了spring-boot-starter-web组件，表示这是一个Web项目。
  
  
  
  

七、Apache Dubbo的高级应用

Apache Dubbo的高级应用
在前面的章节中，我们只是了解了Apache Dubbo作为RPC通信框架的使用方法，以及服务注册中心的应用及原理，这仅仅是它的冰山一角。其实，Apache Dubbo更像一个生态，它提供了很多比较主流框架的集成，比如:

• 支持多种协议的服务发布，默认是dubbo://，还可以支持rest://、webservice://thrift://等
• 支持多种不同的注册中心，如Nacos、ZooKeeper、Redis，未来还将会支持Consul、EurekaEtcd等
• 支持多种序列化技术，如avro、fst、fastjson hessian2、kryo等

除此之外，Apache Dubbo在服务治理方面的功能非常完善，比如集群容错、服务路由、负载均衡、服务降级、服务限流、服务监控、安全验证等。接下来带着大家分析一些常用的功能配置，更多的功能可以关注ApacheDubbo官网，相比国外的官方资料来说，它最大的优势是支持中文，所以对读者来说也能够很好地理解。

7.1集群容错

在分布式架构的网络通信中，容错能力是必须要具备的。什么叫容错呢?从字面来看，就是服务容忍错误的能力。我们都知道网络通信中会存在很多不确定的因素导致请求失败，比如网络延迟、网络中断、服务异常等。当服务调用者(消费者)调用服务提供者的接口时，如果因为上述原因出现请求失败，那对于服务调用者来说需要一种机制来应对。Dubbo中提供了集群容错的机制来优雅地处理这种错误

7.1.1容错模式

Dubbo默认提供了6种容借模式，默认为Failover Cluster。如果这6种容模式不能满足你的实际需求，还可以自行扩展。这也是Dubbo的强大之处，几乎所有的功能都提供了插拔式的扩展。

• Failover Cluster，失败自动切换。当服务调用失败后，会切换到集群中的其他机器进行重试，默认重试次数为2，通过属性retries=2可以修改次数，但是重试次数增加会带来更长的响应延迟。这种容错模式通常用于读操作，因为事务型操作会带来数据重复问题。
• Failfast Cluster，快速失败。当服务调用失败后，立即报错，也就是只发起一次调用。通常用于一些幂等的写操作，比如新增数据，因为当服务调用失败时，很可能这个请求已经在服务器端处理成功，只是因为网络延迟导致响应失败，为了避免在结果不确定的情况下导致数据重复插入的问题，可以使用这种容错机制。
• Failsafe Cluster，失败安全。也就是出现异常时，直接忽略异常
• Failback Cluster，失败后自动回复。服务调用出现异常时，在后台记录这条失败的请求定时重发。这种模式适合用于消息通知操作，保证这个请求一定发送成功。
• Forking Cluster，并行调用集群中的多个服务，只要其中一个成功就返回，可以通过forks=2来设置最大并行数。
• Broadcast Cluster，广播调用所有的服务提供者，任意一个服务报错,则表示服务调用失败。这种机制通常用于通知所有的服务提供者更新缓存或者本地资源信息。

7.1.1.1 配置方式

配置方式非常简单，只需要在指定服务的@Service注解上增加一个参数即可。注意，在没有特殊说明的情况下，后续代码都是基于前面的Dubbo Spring Cloud的代码进行改造的。在@Service注解中增加cluster="failfast”参数，表示当前服务的容错方式为快速失败。

在实际应用中，查询语句容错策略建议使用默认的Failover Cluster，而增改操作建议使用Failfast Cluster或者使用Failover Cluster(retries=“0”)策略，防止出现数据重复添加等其他问题!建议在设计接口的时候把查询接口方法单独做成一个接口提供查询。

7.2负载均衡

负载均衡应该不是一个陌生的概念，在访问量较大的情况下，我们会通过水平扩容的方式增加多个节点来平衡请求的流量，从而提升服务的整体性能。简单来说，如果一个服务节点的TPS是100，那么如果增加到5个节点的集群，意味着整个集群的TPS可以达到500。
当服务调用者面对5个节点组成的服务提供方集群时，请求应该分发到集群中的哪个节点，取决于负载均衡算法，通过该算法可以让每个服务器节点获得适合自己处理能力的负载。负载均衡可以分为硬件负载均衡和软件负载均衡，硬件负载均衡比较常见的就是F5，软件负载均衡目前比较主流的是Nginx。
在Dubbo中提供了4种负载均衡策路，默认负载均衡策略是random。同样，如果这4种策略不能满足实际需求，我们可以基于Dubbo中的SPI机制来扩展

• Random LoadBalance，随机算法。可以针对性能较好的服务器设置较大的权重值，权重值越大随机的概率也会越大。
• RoundRobin LoadBalance，轮询。按照公约后的权重设置轮询比例。
• LeastActive LoadBalance，最少活跃调用书。处理较慢的节点将会收到更少的请求。
• ConsistentHash LoadBalance，一致性Hash。相同参数的请求总是发送到同一个服务提供者。
  配置方式
  在@Service注解上增加loadbalance参数:

@Service(cluster ="failfast",loadbalance ="roundrobin")

7.3服务降级

服务降级是一种系统保护策略，当服务器访问压力较大时，可以根据当前业务情况对不重要的服务进行降级，以保证核心服务的正常运行。所谓的降级，就是把一些非必要的功能在流量较大的时间段暂时关闭，比如在双11大促时，淘宝会把查看历史订单、商品评论等功能关闭，从而释放更多的资源来保障大部分用户能够正常完成交易。
降级有多个层面的分类:

• 按照是否自动化可分为自动降级和人工降级
• 按照功能可分为读服务降级和写服务降级

人工降级一般具有一定的前置性，比如在电商大促之前，暂时关闭某些非核心服务，如评价、推荐等。而自动降级更多的来自于系统出现某些异常的时候自动触发“兜底的流畅”，比如:

• 故障降级，调用的远程服务“挂了网络故障或者RPC服务返回异常。这类情况在业务允许的情况下可以通过设置兜底数据响应给客户端。
• 限流降级，不管是什么类型的系统，它所支撑的流量是有限的，为了保护系统不被压垮，在系统中会针对核心业务进行限流。当请求流量达到闻值时，后续的请求会被拦截，这类请求可以进入排队系统比如12306。也可以直接返回降级页面，比如返回“活动太火爆，请稍候再来”页面
  Dubbo提供了一种Mock配置来实现服务降级，也就是说当服务提供方出现网络异常无法访问时，客户端不抛出异常，而是通过降级配置返回兜底数据，操作步骤如下:

  • 在spring-cloud-dubbo-consumer项目中创建MockHelloService类，这个类只需要实现自动降级的接口即可，然后重写接口中的抽象方法实现本地数据的返回。
    

  • 在不启动Dubbo服务端或者服务端的返回值超过默认的超时时间时，访问/say接口得到的结构就是MockHelloService中返回的数据

7.4机绑定规则

主机绑定表示的是Dubbo服务对外发布的IP地址，默认情况下Dubbo会按照以下顺序来查找并绑定主机IP地

• 查找环境变量中DUBBOIPTOBIND属性配的IP地址
• 查找dubbo.protocol.host属性配置的IP地址，默认是空，如果没有配置或者IP地址不合法，则继续往下查找。
• 通过LocalHost.getHostAddress获取本机IP地址，如果获取失败，则继续往下查找
• 如果配置了注册中心的地址，则使用Socket通信连接到注册中心的地址后，使用for循环通过socket.getLocalAddress( ).getHostAddress()扫描各个网卡获取网卡IP地址
  上述过程中，任意一个步骤检测到合法的IP地址，便会将其返回作为对外暴露的服务IP地址。需要注意的是，获取的IP地址并不是写入注册中心的地址，默认情况下，写入注册中心的IP地址优先选择环境变量中DUBBO_IP_TO_REGISTRY属性配置的IP地址。在这个属性没有配置的情况下，才会选取前面获得的IP地址并写入注册中心。
  使用默认的主机绑定规则，可能会存在获取的IP地址不正确的情况，导致服务消费者与注册中心上拿到的URL地址进行通信，因为Dubbo检测本地IP地址的策略是先调用LcalHost.getHostAddress，这个方法的原理是通过获取本机的hostname映射IP地址，如果它指向的是一个错误的IP地址，那么这个错误的地址将会作为服务发布的地址注册到ZooKeeper节点上，虽然Dubbo服务能够正常启动，但是服务消费者却无法正常调用。按照Dubbo中IP地址的查找规则，如果遇到这种情况，可以使用很多种方式来解决:
• 在/etc/hosts中配置机器名对应正确的IP地址映射
• 在环境变量中添加DUBBO_IP_TO_BIND或者DUBBO_IP_TOREGISTRY属性，Value值为绑定的主机地址。
• 通过dubboprotocol.host设置主机地址除获取绑定主机IP地址外，对外发布的端口也是需要注意的，Dubbo框架中针对不同的协议都提供了默认的端口号:
• Dubbo协议的默认端口号是20880。
• Webservice协议的默认端口号是80

在实际使用过程中，建议指定一个端口号，避免和其他Dubbo服务的端口产生冲突。

八、 Apache Dubbo核心源码分析

突然跳跃到Dubbo的源码分析，显得有点突几。Apache Dubbo是一个非常成熟的RPC框架，对于开发者来说，即便是第一次接触，也能够很快上手。之所以要单独写一节来分析源码，主要还是因为Dubbo中有很多有意思的设计值得学习和借鉴。
Apache Dubbo的源码相对来说还是比较容易理解的，只需要理解几个点:

• SPI机制。
• 自适应扩展点
• IoC和AOP
• Dubbo如何与Spring集成

当然Dubbo里面还有很多值得分析的设计，在本书中就不全部展开了，大家如果有兴趣可以自己花时间以Debug的形式看一遍源码。

8.1 源码构建

源码下载
在编写本书时，Dubbo的最新版本是2.7.5所以我们分析的源码以这个版本作为基础下载地址: https://github.com/apache/dubbo/releases
源码构建
Dubbo源码构建依赖于Maven及JDK，Maven版本要求221以上JDK版本要求15以上进入Dubbo源码根目录下，执行mvninstall-Dmaven.test.skip命令来做一次构建
IDE支持
针对不同的开发工具，可以通过以下命令来生成IDE工程

• IntelliJ IDEA:mvn idea:idea.
• Eclipse:mvn edipse:eclipse.
  笔者采用的是IntelliJIDEA开发工具，所以执行完上述代码之后，直接导入IDEA中即可。

8.2 Dubbo的核心之SPI

在Dubbo的源码中，很多地方会存下面这样三种代码，分别是自适应扩展点、指定名称的扩展点、激活扩展点:

这种扩展点实际上就是Dubbo中的SPI机制。关于SPI，不知道大家是否还有印象，我们在分析Spring Boot自动装配的时候提到过SpringFactoriesLoader，它也是一种SPI机制。实际上，这两者的实现思想是类似的;

8.2.1JavaSPI扩展点实现

SPI全称是Service Proider Interface，原本是JDK内置的一种服务提供发现机制，它主要用来做服务的扩展实现。SPI机制在很多场景中都有运用，比如数据库连接，JDK提供了java.sql.Driver接口，这个驱动类在JDK中并没有实现，而是由不同的数据库厂商来实现，比如Oracle、MySQL这些数据库驱动包都会实现这个接口，然后JDK利用SPI机制从dasspath下找到相应的驱动来获得指定数据库的连接。这种插拔式的扩展加载方式，也同样遵循一定的协议约定。比如所有的扩展点必须要放在resources/META-INF/services目录下，SPI机制会默认扫描这个路径下的属性文件以完成加载

• 创建一个普通的Maven工程Driver，定义一个接口。这个接口只是一个规范，并没有实现，由第三方厂商来提供实现。
  
  

8.2.2Dubbo自定义协议扩展点

Dubbo或者SpringFactoriesLoader并没有使用JDK内置的SPI机制，只是利用了SPI的思想根据实际情况做了一些优化和调整，Dubbo SPI的相关逻被封装在了ExtensionLoader类中，通过ExtensionLoader我们可以加载指定的实现类。
Dubbo的SPI扩展有两个规则:

• 和JDK内置的SPI一样，需要在resources目录下创建任一目录结构:META-INF/dubboMETA-INF/dubbo/internal、META-INF/services，在对应的目录下创建以接口全路径名命名的文件，Dubbo会去这三个目录下加载相应扩展点。
• 文件内容和JDK内置的SPI不一样，内容是一种Key和Value形式的数据。Key是一个字符串，Value是一个对应扩展点的实现，这样的方式可以按照需要加载指定的实现类。实现步骤如下:
  

8.2.3 DubboSPI扩展点源码分析

前面我们用ExtensionLoadergetExtensionLoader.getExtension()来演示了Dubbo中SP的用法，下面我们基于这个方法来分析Dubbo源码中是如何实现SPI的。
这段代码分为两部分:首先我们通过ExtensionLoader.getExtensionLoader来获得一个ExtensionLoader实例，然后通过getExtension()方法获得指定名称的扩展点。先来分析第一部分

ExtensionLoader.getExtensionLoader