apollo源码(2)-client

1.概述

Client 通过轮询的方式，从 Config Service 读取配置。Client 的轮询包括两部分：

1.RemoteConfigRepository ，定时轮询 Config Service 的配置读取

2.RemoteConfigLongPollService ，长轮询 Config Service 的配置变更通知 /notifications/v2 接口

• 当有新的通知时，触发 RemoteConfigRepository ，立即轮询 Config Service 的配置读取 /configs/{appId}/{clusterName}/{namespace:.+} 接口。

整体流程图：

说明：

• 一个 Namespace 对应一个 RemoteConfigRepository 。

• 多个 RemoteConfigRepository ，注册到全局唯一的 RemoteConfigLongPollService 中。

2. ConfigRepository

配置 Repository 接口。代码如下：

抽象方法

public interface ConfigRepository {    / / 配置读取接口    Properties getConfig();  // 设置上游Repository  void setUpstreamRepository(ConfigRepository upstreamConfigRepository);  // 设置changeListener  void addChangeListener(RepositoryChangeListener listener);  // 去除changeListener  void removeChangeListener(RepositoryChangeListener listener); }

类的继承体系：

2.1AbstractConfigRepository

1.实现 ConfigRepository 接口，配置 Repository 抽象类

2.1.1 同步配置

//尝试同步  * @return 是否同步成功 protected boolean trySync() ; // 同步配置 protected abstract void sync();

2.1.2 监听器

1.当有配置更新时，会触发注册的RepositoryChangeListener

@Override public void addChangeListener(RepositoryChangeListener listener) ;   @Override public void removeChangeListener(RepositoryChangeListener listener) ; /**  * 触发监听器们  */ protected void fireRepositoryChange(String namespace, Properties newProperties) ;

3. RemoteConfigRepository&RemoteConfigLongpollService

 

 

5.本地文件缓存目录

客户端的aplllo配置缓存文件可以通过四种方式生成：

1.可以通过设置System的jvm参数来为apollo.cacheDir制定缓存目录

通过System.getProperty("apollo.cacheDir")获取

2.通过设置环境变量制定缓存目录

通过System.getenv("APOLLO_CACHEDIR")获取

3.配置文件设置apollo.cacheDir制定缓存目录

通过Foundation.server().getProperty("apollo.cacheDir", null)获取

4.系统默认的文件路径 ／opt/data/${appId}

4.1 获取顺序

 

5.SPI机制

SPI ，全称为 Service Provider Interface，是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。

这一机制为很多框架扩展提供了可能，比如在Dubbo、JDBC中都使用到了SPI机制

在1.0.0版本中，Apollo提供了MetaServerProvider SPI，用户可以注入自己的MetaServerProvider来自定义Meta Server地址定位逻辑。

由于使用典型的Java Service Loader模式，所以实现起来还是比较简单的。有一点需要注意的是，apollo会在运行时按照顺序遍历所有的MetaServerProvider，直到某一个MetaServerProvider提供了一个非空的Meta Server地址，因此用户需要格外注意自定义MetaServerProvider的Order。规则是较小的Order具有较高的优先级，因此Order=0的MetaServerProvider会排在Order=1的MetaServerProvider的前面。