转载注明出处： 季义钦的博客
最近在考虑分布式环境下配置中心实现。
我的配置中心需要如下功能：
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日补充======================
这里我的一片文章介绍我自己开发的分布式注册中心，配置中心作为其核心功能之一：