转载注明出处： 季义钦的博客

最近在考虑分布式环境下配置中心实现。

我的配置中心需要如下功能：

1、服务动态注册和发现（包括负载均衡）

2、配置信息的读取和写入

3、配置信息、服务信息的监视（变化时通知）

针对配置中心有如下要求：

1、集群支撑

2、快速的写入和读取

3、强一致性

4、跨语言client支持

对于配置中心很难设计。

光用Zookeeper吧，发现一是跨语言支持不好，需要大量跨语言支持的开发，而且没办法在上面增加大量的算法和逻辑。

如果在Zookeeper前面加一层服务来作为辅助的话，又怕成为单点压力。

下面是我画的一个架构图，希望大家帮忙看看，踊跃讨论。

希望各位不管有什么意见和建议、都在下面评论里面留下自己的想法，帮助我改进，谢谢

============================= 20140818晚补充==============================

其实我想了想，单点压力并不是太大的问题。

可以为Java服务构造集群来解决，使用Nginx等负载均衡器做负载均衡，这样单点压力问题就没有了。

但是这样还有单点故障问题。

一旦负载均衡器出现故障，配置中心便无法使用，整个系统也就无法使用。

这个问题也可以通过增加多个负载均衡器来实现，客户端维护一个负载均衡器地址列表，选定一个作为有效负载均衡器。

当请求达到一定超时时限时，就换一个来试，直到成功，并将新的负载均衡器的地址作为当前有效地址记录。

不过这样做稍微有些麻烦。

其实除了上面讲到的两点之外，在Zookeeper前面加一层服务还有两个非常关键的缺点：

1、watch机制难以实现。

2、自动检测连接到Zookeeper 集群是否存活(Zookeeper中有短暂的znode的概念)无法实现，只能借用于定时向Java服务报告自己的状况这种传统的做法。

其实可以换一种思路，同样是增加一个辅助服务，但是我们并不让其屏蔽掉后面的Zookeeper集群，而是做一些算法方面的工作，比如当客户端请求服务地址时，根据一定的负载均衡算法返回最合适的服务地址，然而这就需要为Zookeeper Server集群开发不同语言的客户端。

直到最近ETCD进入我的视线，其提供REST API接口，即使用HTTP请求即可与Server集群交互，在跨语言方面支持好像很好，有待继续深入了解。

====================== 2014年12月补充 ====================

Zookeeper对跨语言支持也比较成熟了，可以用于生产环境！

ETCD也可以用，两者都可以，但是相对来说Zookeeper应用较广，成熟度较高，社区比较活跃，性能也高不少。

====================== 2015年7月4日补充======================

这里我的一片文章介绍我自己开发的分布式注册中心，配置中心作为其核心功能之一：

http://blog.csdn.net/jiyiqinlovexx/article/details/43702035