分布式环境下配置中心设计实现考虑问题

阅读导读：
1.设计过程中单点压力问题是如何解决的？
2.设计中单点故障问题是如何解决的？








配置中需要实现的功能：
1、服务动态注册和发现（包括负载均衡）
2、配置信息的读取和写入
3、配置信息、服务信息的监视（变化时通知）

针对配置中心有如下要求：
1、集群支撑
2、快速的写入和读取
3、强一致性
4、跨语言client支持

对于配置中心很难设计。
光用Zookeeper吧，发现一是跨语言支持不好，需要大量跨语言支持的开发，而且没办法在上面增加大量的算法和逻辑。
如果在Zookeeper前面加一层服务来作为辅助的话，又怕成为单点压力。

下面是我画的一个架构图，希望大家帮忙看看，踊跃讨论。
希望各位不管有什么意见和建议、都在下面评论里面留下自己的想法，帮助我改进，谢谢。



其实我想了想，单点压力并不是太大的问题。
可以为Java服务构造集群来解决，使用Nginx等负载均衡器做负载均衡，这样单点压力问题就没有了。

但是这样还有单点故障问题。一旦负载均衡器出现故障，配置中心便无法使用，整个系统也就无法使用。
这个问题也可以通过增加多个负载均衡器来实现，客户端维护一个负载均衡器地址列表，选定一个作为有效负载均衡器。
当请求达到一定超时时限时，就换一个来试，直到成功，并将新的负载均衡器的地址作为当前有效地址记录。
不过这样做稍微有些麻烦。

其实除了上面讲到的两点之外，在Zookeeper前面加一层服务还有两个非常关键的
缺点：
1、watch机制难以实现。
2、自动检测连接到Zookeeper 集群是否存活(Zookeeper中有短暂的znode的概念)无法实现，只能借用于定时向Java服务报告自己的状况这种传统的做法。

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

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






出处： 季义钦的博客

顶一个  谢谢

赞一个,好人那