Apollo配置中心之apollo-configservice模块源码分析

• 关键字 ：Apollo源码、apollo-configservice模块

• 上一篇文章 Apollo 原理分析主要涉及到的都是一些原理性得。本篇以及后面的连载将关注于Apollo相关模块的源码分析

首先我们来看一下apollo-configservice模块的项目结构：

apollo-configserice

，典型的SpringBoot应用，或者说就是一个普通得Web服务端。跟我们平常开发得Web服务几乎没有差别。

• ConfigServiceAutoConfiguration:
  ① 创建ConfigService得bean，

  ConfigService
  由于此处默认不开启缓存，正常情况下创建得是DefaultConfigService。主要从来做发布信息得查询
  ②创建GrayReleaseRulesHolder得bean，灰度发布规则，相信使用过Apollo灰度功能得应该了解灰度支持配置规则
  GrayReleaseRuleHolder
  ，用来缓存灰度规则，并且后台会启动周期性线程池去扫描灰度规则并及时更新灰度缓存
  ③创建FilterRegistrationBean，用来对请求进行过滤
  FilterRegistrationBean
  ，内置得过滤器是ClientAuthenticationFilter用来鉴权。
  com.ctrip.framework.apollo.configservice.filter.ClientAuthenticationFilter#doFilter
  判断是否有appId（应用唯一标识），不存在的话终止请求，然后根据appid查询是否配置了accessKey，不存在这放行请求；存在得话获取请求头中得时间戳，校验是否超过一分钟得有效期，若超过则终止请求；否则获取请求头中得Authorization（ Apollo {appId}:{sign} ）字段，使用HmacSha1算法进行签名验证
  ④接着创建ReleaseMessageScanner定时扫描器，每隔1秒定时扫描是否存在发布信息变更，若变更则触发监听器,其中前面几个都是服务端缓存高性能得监听器设计，最重要得一个是NotificationControllerV2这个监听器。
  ReleaseMessageScanner
  
  ⑤NotificationControllerV2：此接口就是与客户端保持通讯得核心处理类。有一个接收客户端请求得Get方法
  pollNotification
  ，上篇文章一直说的长轮询得实现就是调用此接口。利用Servlet3.0得特性，方法内部通过SpringDeferredResult将请求挂起，通过组装watchkey（appId, cluster, namespace, dataCenter）实现监听操作，超时时间为1分钟。另外一个地方就是此类本身是个监听器，当上面得扫描器发现有发布信息时，会触发监听器回调，NotificationControllerV2也会被通知到：
  com.ctrip.framework.apollo.configservice.controller.NotificationControllerV2#handleMessage
  ，大致逻辑是获取变更得namespace，若延迟结果中不包含（没有当前namespace对应得客户端发起长轮询）则不做处理，接着判断是否有大量得客户端，若是，则使用线程池异步设置延迟结果deferredResults得值，否则同步调用setResult方法设置结果。返回给客户端。

• 另外，除了configservice包之外，还有一个metaservice包，用来做Eureka得服务发现实现，核心逻辑：

  com.ctrip.framework.apollo.metaservice.service.DefaultDiscoveryService
  ，将从Eureka中拉取得实例信息封装成内部得DTO。

• 至此，apollo-configservice与客户端交互涉及到得类与逻辑基本分析完毕，其中一个很重要得点是Spring DeferredResult
  来实现服务端异步化，感兴趣得同学可以看一下其中得原理，本篇文章不做过多分析。

1. ☛ 文章要是勘误或者知识点说的不正确，欢迎评论，毕竟这也是作者通过阅读源码获得的知识，难免会有疏忽！
2. ☛ 要是感觉文章对你有所帮助，不妨点个关注，或者移驾看一下作者的其他文集，也都是干活多多哦，文章也在全力更新中。
3. ☛ 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处！