How to Manage Configuration - 关于配置的思考

http://www.zenlife.tk/%E5%85%B3%E4%BA%8E%E9%85%8D%E7%BD%AE%E7%9A%84%E6%80%9D%E8%80%83.md

下面看一些实际的跟分布式配置相关的东西。

基于etcd/zookeeper自己撸一套解决方案。这类开源软件提供的是灵活性，可以提供分布式锁，可以用于元数据存储，当然，也可以用于服务发现和中心化配置信息。灵活的代价就是不好用，需要自己做较多工作。

disconf/diamond分别是百度和淘宝开源的分布式配置中心。不过都是Java派系的，难以跟我们的Go的生态结合。

如果要有一个分布式的配置中心，我希望有哪些东西呢？

可用性是需要保证的。一旦配置中心挂了，读不了配置，所以服务就全部起不来了。这里有一篇为什么不要把ZooKeeper用于服务发现，指出需要的是一个AP的系统。而在CP之上构建AP系统，根本就是错误的。

可视化修改。用户友好性非常重要。

动态更新。一旦改了中心化的配置，各个客户端能获取到配置的变化并相应地进行更新。

library or not? 一般都会提供一套相应的库，封装好跟配置中心的交互。客户端使用时直接调库的方法来获取配置。从简单的角度，是比读本地配置文件变复杂了，引入了更多的依赖。原本可以在自己机器就可以跑测试，而后来离开公司环境就测不了了。

内部配置和外部配置。比如说业务对redis或者nsq的依赖，这种属于外部配置。而业务内部某个队列的长度，某个超时时间，或者缓存大小等等，这种属于内部配置。外部配置我希望写成服务发现，类似一层域名到ip的转换，必要场景下还可以高可用。

既然说到了服务发现，有个很有趣的idea是利用DNS来做，比如SkyDNS。DNS是算是互联网非常基础的部件，经过验证过的东西在云时代发挥新的作用。反对的声音也有，比如这里就有提到不靠谱，由于缓存更新是不够及时的，甚至传递过程的延迟多久生效都不可知。

最后说一个考虑中的方案consul+confd。

把配置使用的数据统一到一个地方，其实随便用什么数据库都可以存储。但是这样做有单点问题，可用性达不到要求。为了处理这个问题，可以用etcd或者zookeeper这样的项目来做这里的数据库，就可以解决单点问题了。但是接下来面临的问题，是需要自己做的工作比较多。像封装客户端，可视化方面。

使用consul替换etcd可以解决这个问题。一句话描述consul是什么："Service discovery and configuration made easy. Distributed, highly available, and datacenter-aware."

我们现在的项目是大量使用json配置文件的。改成写一个客户端库去读配置，工作量会比较大。最直接的方式，使用confd。依然维持原来的配置文件形式，不过数据却是从consul中获取得到。

http://www.infoq.com/cn/news/2014/12/zookeeper-service-finding

在ZooKeeper中，网络分区中的客户端节点无法到达Quorum时，就会与ZooKeeper失去联系，从而也就无法使用其服务发现机制。因此，在用于服务发现时，ZooKeeper无法很好地处理网络分区问题。作为一个协调服务，这没问题。但对于服务发现来说，信息中可能包含错误要好于没有信息。虽然可以通过客户端缓存和其它技术弥补这种缺陷，像Pinterest和Airbnb等公司所做的那样，但这并不能从根本上解决问题，如果Quorum完全不可用，或者集群分区和客户端都恰好连接到了不属于这个Quorum但仍然健康的节点，那么客户端状态仍将丢失。

更重要地，上述做法的本质是试图用缓存提高一个一致性系统的可用性，即在一个CP系统之上构建AP系统，这根本就是错误的方法。服务发现系统从设计之初就应该针对可用性而设计。

抛开CAP理论不说，ZooKeeper的设置和维护非常困难，以致Knewton多次因为错误的使用出现问题。一些看似很简单的事情，实际操作起来也非常容易出错，如在客户端重建Watcher，处理Session和异常。另外，ZooKeeper本身确实也存在一些问题，如ZOOKEEPER-1159、ZOOKEEPER-1576。

由于这些问题的存在，他们切换到了Eureka。这是一个由Netflix开发的、开源的服务发现解决方案，具有可用性高、恢复能力强的特点。相比之下，它有如下优点：

如果一个服务器出现问题，Eureka不需要任何类型的选举，客户端会自动切换并连接到一个新的Eureka服务器。当它恢复时，可以自动加入Eureka节点集群。而且，按照设计，它可以在零停机的情况下处理更广泛的网络分区问题。在出现网络分区的情况下，Eureka将继续接受新的注册并发布。这可以确保新增服务仍然可以供分区同侧的任意客户端使用。

Eureka有一个服务心跳的概念，可以阻止过期数据：如果一个服务长时间没有发送心跳，那么Eureka将从服务注册中将其删除。但在出现网络分区、Eureka在短时间内丢失过多客户端时，它会停用这一机制，进入“自我保护模式”。网络恢复后，它又会自动退出该模式。这样，虽然它保留的数据中可能存在错误，却不会丢失任何有效数据。

Eureka在客户端会有缓存。即使所有Eureka服务器不可用，服务注册信息也不会丢失。缓存在这里是恰当的，因为它只在所有的Eureka服务器都没响应的情况下才会用到。

Eureka就是为服务发现而构建的。它提供了一个客户端库，该库提供了服务心跳、服务健康检查、自动发布及缓存刷新等功能。使用ZooKeeper，这些功能都需要自己实现。

管理简单，很容易添加和删除节点。它还提供了一个清晰简洁的网页，上面列出了所有的服务及其健康状况。

Eureka还提供了REST API，使用户可以将其集成到其它可能的用途和查询机制。