分布式系统中如何较好地做服务发现
前言
在分布式系统中的中心管理服务模式下，往往采用的模式是1个manager服务节点，多个worker节点，然后由manager来管控这些worker节点。但是本篇文章不是来讲manager如何管理的问题，而是woker识别发现manager服务的问题。目前一种比较简单的做法，通过worker节点本地配置的方式，来指定manager服务地址。这种方式实现较为容易，但是可维护性并不高。比如一个简单的场景，如果manager节点地址发生改变，其下worker节点内所标明的manager地址就得被动地一个个更新了。我们可以用一个专业的术语表示这个现象：Service Discovery（服务发现）。
服务发现的基本原则
服务发现说到底就是让客户端如何快速，高效地“找到”服务端。前面提到的通过本地配置直接指明地址的方式是一种，但是确切地来说，它并不高效。
一种更为高效的方式应该是下面这种：
客户端始终联系（通信）的是一个固定（共享）的地址，而不是实际的地址，通过这个共享的地址，我们能够找到实际的地址。
可能有人会说了，这不就是代理地址的意思嘛。但其实这并不完全等同于代理地址的意思。在后面的篇幅内，后具体介绍这里面的差异。
服务发现的现有解决方案
针对上节提到的大原则的前提下，我们有哪些可行的方案呢？从最近Hadoop社区讨论中，笔者归纳出了以下几种：
- 第一种，通过本地xml文件的方式，就是和现有HDFS指定hdfs-site.xml的配置方式类型。但是这个解析得到配置结果的途径改为统一走底层通用框架的模式，而不是原有直接在执行代码中解析配置。只是说，我们保留了一种与原先本地配置化读取一样效果的方式。
- 第二种，通过外部存储的方式。具体地来说，是引入一个外部Store来存储实际的地址，而客户端只需要看到的地址是这个Store地址。也就是说，客户端需要从这个Store中先查询实际的地址。这个Store可以是我们常见的比如ZK，HDFS或HBase等等。至于在查询过程潜在的性能问题，可以通过引入缓存机制来优化这个问题。
- 第三种，通过Router的方式。Router与上面提到的方式的一个不同点在于，Router帮我们免去了实际查询的动作，也就是说，客户端只需要知道Router地址，这就足够了。这种方式就可以理解为是完全一个代理地址的概念了。现有Router模式的例子，大家可以学习HDFS RBF特性。
- 第四种，DNS解析的方式。这是指我们引入一个共享地址host，这个host表明的是我们具体服务的地址。由于DNS服务器来做这个地址的解析。这种方案主要考虑的问题在于服务host地址的及时更新问题。
依赖外部存储Store的服务发现解决方案实现
下面笔者给出社区上被提出过的第二种方案的具体代码实现，大家可以仔细理解其中的解决过程（这里依赖的外部存储是ZK，分布式系统服务为HDFS）。
/**
* 服务发现抽象类.
*/
public abstract class NameserviceDiscovery implements Configurable, Closeable {
private static final Logger LOG =
LoggerFactory.getLogger(NameserviceDiscovery.class);
/** 针对每个服务发现实例，进行缓存构造. */
protected static final LoadingCache<Id, NameserviceDiscovery> CACHE =
CacheBuilder.newBuilder()
.expireAfterAccess(1, TimeUnit.MINUTES)
.removalListener(getRemover())
.build(getLoader());
/** Local configuration. */
private Configuration conf;
static class Id {
// 服务发现类
Class<? extends NameserviceDiscovery> clazz;
// 节点当前配置信息
Configuration conf;
Id(
Class<? extends NameserviceDiscovery> className,
Configuration config) {
this.clazz = className;
this.conf = config;
}
}
/**
* 从缓存中获得服务发现实例
*/
public static NameserviceDiscovery get(Configuration conf) {
Class<? extends NameserviceDiscovery> clazz = conf.getClass(
DFS_DISCOVERY_CLASS_KEY,
DFS_DISCOVERY_CLASS_DEFAULT,
NameserviceDiscovery.class);
try {
Id key = new Id(clazz, conf);
return CACHE.get(key);
} catch (ExecutionException e) {
LOG.error("Cannot get a nameservice discovery from the cache", e);
}
return ReflectionUtils.newInstance(clazz, conf);
}
private static CacheLoader<Id, NameserviceDiscovery> getLoader() {
return new CacheLoader<Id, NameserviceDiscovery>() {
@Override
public NameserviceDiscovery load(Id id) throws Exception {
return ReflectionUtils.newInstance(id.clazz, id.conf);
}
};
}
private static RemovalListener<Id, NameserviceDiscovery> getRemover() {
return new RemovalListener<Id, NameserviceDiscovery>() {
@Override
public void onRemoval(
RemovalNotification<Id, NameserviceDiscovery> notification) {
NameserviceDiscovery discovery = notification.getValue();
try {
discovery.close();
} catch (IOException e) {
LOG.error("Cannot close nameservice discovery");
}
}
};
}
@Override
public void setConf(Configuration config) {
this.conf = config;
}
@Override
public Configuration getConf() {
return this.conf;
}
/**
* 获取服务地址方法
*/
public abstract Collection<String> getNameServiceIds();
public abstract Map<String, Map<String, InetSocketAddress>>
public abstract Map<String, Map<String, InetSocketAddress>> getHttpAddresses();
public abstract Map<String, Map<String, InetSocketAddress>> getHttpsAddresses();
}
下面是基于ZK的服务发现实现类，
/**
* 基于ZK的服务发现实现类.
*/
public class ZookeeperBasedNameserviceDiscovery extends NameserviceDiscovery
implements DynamicNameserviceDiscovery {
private static final Logger LOG =
LoggerFactory.getLogger(ZookeeperBasedNameserviceDiscovery.class);
/** ZK管理器接口. */
private ZKCuratorManager zkManager;
/** 实际地址信息的ZK存储目录. */
private String baseZNode;
/**
* 初始化ZK连接操作
*/
public void init() {
if (zkManager == null) {
Configuration conf = getConf();
baseZNode = conf.get(
DFS_DISCOVERY_ZK_PARENT_PATH_KEY,
DFS_DISCOVERY_ZK_PARENT_PATH_DEFAULT);
try {
zkManager = new ZKCuratorManager(conf);
zkManager.start();
} catch (IOException e) {
LOG.error("Cannot initialize the ZK connection", e);
}
}
}
/**
* 关闭ZK连接
*/
public void close() throws IOException {
if (zkManager != null) {
zkManager.close();
zkManager = null;
}
}
/**
* 从ZK中获取地址的操作方法
*/
Map<String, Map<String, InetSocketAddress>> getAddresses(
final String attr) throws IOException {
Map<String, Map<String, InetSocketAddress>> ret = Maps.newLinkedHashMap();
try {
List<String> nsIds = zkManager.getChildren(baseZNode);
for (String nsId : nsIds) {
Map<String, InetSocketAddress> nsMap = Maps.newLinkedHashMap();
String pathNs = baseZNode + "/" + nsId;
List<String> nnIds = zkManager.getChildren(pathNs);
for (String nnId : nnIds) {
String pathNn = pathNs + "/" + nnId;
String pathAddress = pathNn + "/" + attr;
String addr = zkManager.getStringData(pathAddress);
InetSocketAddress sockAddr = NetUtils.createSocketAddr(addr);
nsMap.put(nnId, sockAddr);
}
ret.put(nsId, nsMap);
}
} catch (Exception e) {
LOG.error("Cannot get the addresses", e);
throw new IOException(e.getMessage());
}
return ret;
}
/**
* 其它类型方法
*/
@Override
public Collection<String> getNameServiceIds() {
init();
try {
return getAddresses("rpcAddress").keySet();
} catch (IOException e) {
// Fallback to the configuration based
return getConf().getTrimmedStringCollection(DFS_NAMESERVICES);
}
}
@Override
public Map<String, Map<String, InetSocketAddress>> getRpcAddresses() {
init();
try {
return getAddresses("rpcAddress");
} catch (IOException e) {
// Fallback to the configuration based
Configuration conf = getConf();
return DFSUtilClient.getAddresses(conf, null,
HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY);
}
}
@Override
public Map<String, Map<String, InetSocketAddress>> getHttpAddresses() {
init();
try {
return getAddresses("httpAddress");
} catch (IOException e) {
// Fallback to the configuration based
Configuration conf = getConf();
return DFSUtilClient.getAddresses(conf, null,
HdfsClientConfigKeys.DFS_NAMENODE_HTTP_ADDRESS_KEY);
}
}
@Override
public Map<String, Map<String, InetSocketAddress>> getHttpsAddresses() {
init();
try {
return getAddresses("httpsAddress");
} catch (IOException e) {
// Fallback to the configuration based
Configuration conf = getConf();
return DFSUtilClient.getAddresses(conf, null,
HdfsClientConfigKeys.DFS_NAMENODE_HTTPS_ADDRESS_KEY);
}
}
}
使用的方式很简单，调用底层NameserviceDiscovery的接口即可。在系统中将配置解析操作方法替换为上述接口方式的话，服务发现的方式就优化成了第二种方案了，可维护性也增强了许多。以上就是一个简单的依赖外部Store的服务发现的实现方案。
引用
[1].https://issues.apache.org/jira/browse/HADOOP-15774. Discovery of HA servers
[2].https://issues.apache.org/jira/browse/HDFS-13312. NameNode High Availability ZooKeeper based discovery rather than explicit nn1,nn2 configs
