Apollo（阿波罗）
携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
下载地址：git clone https://github.com/ctripcorp/apollo.git
配置安装地址：https://github.com/ctripcorp/apollo/wiki/Quick-Start
统一管理不同环境&不同集群的配置
-
统一界面集中式管理
-
同代码，不同配置
-
通过名称空间可以支持不同应用同配置 支持应用对共享配置覆盖
特点摘要
配置的热发布 ， 版本发布管理 ，支持灰度发布， 权限管理等
python 用户的使用指南
-----------注意方便 python 接入配置中心框架 Apollo 所开发的 python 客户端 建议版本使用 python 2.7 & python 3.6
-
install PyApollo 安装 Apollo
-
客户端使用
a. 启动客户端长连接监听
client = ApolloClient ( app_id = < appId > , cluster = < clusterName > , config_server_url < configServerUrl > )
client.start()b. 获取Apollo的配置
client.get_value(Key, DefaultValue)
问题点：
1. 对 apollo 配置中心依赖较强 客户端配置无本地缓存
2. 配置文件命名规则，很麻烦，配置都在命名上，根据命名搜索，没有可视化的配置
3. 不支持多语言客户端，全家桶的问题
4. 如果要实现热部署配置文件 需要配合 springcloud bus ，在 github 上做webhook 依赖性很强，配置复杂，实时性一般，若不做热加载的配置下发，那配置中心则毫无意义
5. 配置复杂，且对代码有侵入，学习成本高
优点
1. 不需要过多的依赖 ，多语言客户端应用较好
2. 部署简单 实现动态加载配置 客户端配置简单
3. 支持多环境 可以dev fat uat等 提供分布式部署
配置发布：
大致流程：
-
用户在Portal操作配置发布
-
Portal调用Admin Service的接口操作发布
-
Admin Service发布配置后，发送ReleaseMessage给各个Config Service
-
Config Service收到ReleaseMessage后，通知对应的客户端
安装流程
-
下载依赖
-
方式一：从 https://github.com/ctripcorp/apollo/releases 页面下载最新版本的 apollo-configservice-x.x.x-github.zip、apollo-adminservice-x.x.x-github.zip 和 apollo-portal-x.x.x-github.zip 依赖包(需要 FQ 。不能 FQ 的同学建议使用第二种方式)。
-
方式二：从 https://github.com/ctripcorp/apollo 下载源码后在本地构建。构建步骤为:
-
下载项目所需依赖
-
使用 s 文件夹下的 build.bat 或 build.sh 构建
-
分别拷贝出 apollo-adminservice 、apollo-configservice 和 apollo-portal 三个文件夹下 target/apollo-xxx-x.x.x-github.zip 文件
-
-
-
创建数据库从https://github.com/ctripcorp/apollo/tree/master/s/sql下载apolloconfigdb.sqlapolloportaldb.sql数据库文件。使用apolloportaldb.sql文件创建apolloportaldb数据库，此数据库是我们管理各种环境等的通用数据库。使用apolloconfigdb.sql文件分别创建apolloconfigdb_dev和apolloconfigdb_fat数据库作为我们两个环境的数据存储。
ZooKeeper
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 一个集中式的服务，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。所有的这些服务第一以某种形式由分布式应用程序使用。
Zookeeper 是由 Java 语言实现，实现了强一致性（CP），并且是使用 Zab 协议在 ensemble 集群之间协调服务信息的变化。
Zookeeper 在 ensemble 集群中运行3个，5个或者7个成员。众多 client 端为了可以访问 ensemble ，需要使用绑定特定的语言。这种访问形式被显性的嵌入到了client 的应用实例以及服务中。
服务注册的实现主要是通过命令空间（namespace）下的 ephemeral nodes 。ephemeral nodes 只有在client建立连接后才存在。当 client 所在节点启动之后，该client 端会使用一个后台进程获取client的位置信息，并完成自身的注册。如果该 client 失效或者失去连接的时候，该 ephemeral node 就从树中消息。
服务发现是通过列举以及查看具体服务的命名空间来完成的。Client 端收到目前所有注册服务的信息，无论一个服务是否不可用或者系统新添加了一个同类的服务。Client 端同时也需要自行处理所有的负载均衡工作，以及服务的失效工作。
Zookeeper 的 API 用起来可能并没有那么方便，因为语言的绑定之间可能会造成一些细小的差异。如果使用的是基于 JVM 的语言的话，Curator Service Discovery Extension可能会对你有帮助。
由于 Zookeeper 是一个CP强一致性的系统，因此当网络分区（Partition）出故障的时候，你的部分系统可能将出出现不能注册的情况，也可能出现不能找到已存在的注册信息，即使它们可能在 Partition 出现期间仍然正常工作。特殊的是，在任何一个non-quorum 端，任何读写都会返回一个错误信息。
Doozer
Doozer 是一个一致的分布式数据存储系统，Go语言实现，通过 Paxos 算法来实现共识的强一致性系统。这个项目开展了数年之后，停滞了一段时间，而且现在也关闭了一些fork数，使得fork数降至160 。.不幸的是，现在很难知道该项目的实际发展状态，以及它是否适合使用于生产环境。
Doozer 在集群中运行3，5或者7个节点。和 Zookeeper 类似，Client端为了访问集群，需要在自身的应用或者服务中使用特殊的语言绑定。
Doozer 的服务注册就没有 ookeeper 这么直接，因为 Doozer 没有那些ephemeral node的概念。一个服务可以在一条路径下注册自己，如果该服务不可用的话，它也不会自动地被移除。
现有很多种方式来解决这样的问题。一个选择是给注册进程添加一个时间戳和心跳机制，随后在服务发现进程中处理那些超时的路径，也就是注册的服务信息，当然也可以通过另外一个清理进程来实现。
服务发现和 Zookeeper 很类似，Doozer 可以罗列出指定路径下的所有入口，随后可以等待该路径下的任意改动。如果你在注册期间使用一个时间戳和心跳，你就可以在服务发现期间忽略或者删除任何过期的入口，也就是服务信息。和 Zookeeper 一样，Doozer 是一个 CP 强一致性系统，当发生网络分区故障时，会导致同样的后果。
Etcd
Etcd 是一个高可用的K-V存储系统，主要应用于共享配置、服务发现等场景。Etcd 可以说是被 Zookeeper 和 Doozer 催生而出。整个系统使用Go语言实现，使用Raft算法来实现选举一致，同时又具有一个基于HTTP+JSON的API。
Etcd ，和 Doozer 和 Zookeeper 相似，通常在集群中运行3，5或者7个节点。client 端可以使用一种特定的语言进行绑定，同时也可以通过使用HTTP客户端自行实现一种。
服务发现环节设计到罗列在一个目录下的所有key值，随后等待在该目录上的所有变动信息。由于 API 接口是基于HTTP的，所以client应用会的 Etcd 集群保持一个 long-polling 的连接。
由于 Etcd 使用 Raft 一致性协议，故它应该是一个强一致性系统。Raft 需要一个leader被选举，然后所有的client请求会被该leader所处理。然而，Etcd 似乎也支持从non-leaders 中进行读取信息，使用的方式是在读情况下提高可用性的未公开的一致性参数。在网络分区故障期间，写操作还是会被leader处理，而且同样会出现失效的情况。