毫不犹豫的说，现代高速发展的互联网造就了一批又一批的网络红人，这一批批网红又极大的催生了特定平台的一大波流量，但是留给了程序员却是一地鸡毛，无论是运维还是开发，每天都会担心服务器崩溃，程序down机。还是怀念以前那些单机结构呀，甚至有点嫉妒那些做内网几乎没有访问量的应用的程序员，不用加班，不用提心吊胆，更不用每年买霸王洗发露。
提到单机架构，在互联网应用中肯定是吃不开的，流量高峰冲击的你可以怀疑人生。单机升级集群，带来的不止是技术上的挑战，在顶住流量高峰，迎合业务的同时，也引入了配置的复杂性。这也是我今天要谈的主题：配置管理。在单机时代，无论是什么语言，java也好，c#也罢，一个配置文件足以。随着所谓微服务这个看似能解决一切问题的方案诞生，同时也引入了更加复杂的配置问题：服务的信息，服务的各种参数，配置更新问题等。可想而知，假如你的服务有100台服务器，修改一个配置项，利用单体架构逐个更新的方式是一个多么蛋疼的事情，传统的配置文件方式已经无法满足开发人员对于配置管理的要求：
安全性。配置信息如果随代码一起发布，容易造成配置泄露。
实时性。修改配置，传统的单机架构必须重启服务才能生效。
局限性。无法支持动态调整，像最普通的日志开关功能，也不能做到。
环境区分。传统的配置文件方式，很难区分生产，开发，测试环境。
配置修改记录问题。静态配置文件方式，很难追踪这个配置文件的修改记录。
针对以上问题，有的公司采用数据库记录配置来解决问题，不是说不可以，只不过数据库并不能解决根本性问题，举个很简单的例子：有最新的记录修改，客户端怎么能实时得到通知呢？虽然可以利用其他方案来解决，但是基于数据库方式并非是最优的。
配置中心无论是采用数据库方式也好，还是采用其他方式也罢，最本质的出发点还是要看业务具体需求和相应的可以投入的人力物力。不是说像携程的apollo不好，而是说这样一套庞大的配置系统是否适用于你的公司，是否适用于你的业务。在很多情况下，公司的业务发展在一定阶段讲究的是短平快，没有必要也没有时间去投入精力去深研究一套庞大的系统，在业务慢慢发展起来之后可以慢慢迭代，这才是系统架构升级的过程，那些业务之初就要建立淘宝级架构的，最终会落得人人疲惫。
说了这么多，我就是想撸一套简约的，可落地的配置中心，要保证配置中心能正常工作，有几点是在设计之初要考虑的：
需要一个可靠的，强一致性的存储来支撑在经过了多次技术调研之后，我最终选择了ETCD，并非因为我喜欢最求热点，而是ETCD在应对场景，功能上恰好对应我的需求，
etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。
简单：安装配置简单，而且提供了HTTP API进行交互，使用也很简单
安全：支持SSL证书验证
快速：根据官方提供的benchmark数据，单实例支持每秒2k+读操作
可靠：采用raft算法，实现分布式系统数据的可用性和一致性
Watch机制：ETCD支持针对某个Key或者某组Key的Watch机制，一旦有数据发生变化，会实时通知Client。
需要支持多环境的配置虽然很多存储的显示参数都没有环境这样的参数，但是都提供了类似目录存储这样的功能，就像windows的文件目录一样，这就为我们自定义功能提供了很强的应变能力，例如，我们存储A应用开发环境可以是这样的： /A/DEV/ ，这个目录就代表了A应用的开发环境配置。
配置项发生变化，需要实时通知客户端基于第一点选择的ETCD天生就支持Watch机制，所以配置项发生变化实时通知客户端这点是很好做到的，就算了通知失败，我们也可以自定义时间来延迟更新配置。稍后请看以下代码。
使用要简单对于使用者来说，配置中心提供的业务接口最终只有：获取某个key的配置，这里的key可以是应用+环境等参数的合集。为了辅助跟踪，可以暴露出程序异常时候的处理事件，就像以下程序：
/// <summary> /// 配置中心客户端,应用，子应用，环境、版本、灰度、 /// </summary> public interface IConfigCenterClient { /// <summary> /// 配置信息发生变化时候的事件，参数：key/new value /动作（put /delete）， 是etcd /consul watch的事件。每个key 的value发生变化都会触发,每个key会触发一条 /// </summary> event Action<string, string, string> ConfigValueChangedEvent; /// <summary> /// 发生异常时候的事件 /// </summary> event Action<Exception> ErrorOccurredEvent; /// <summary> /// 获取相应的配置 /// </summary> /// <param>配置的名称</param> /// <param>版本号</param> /// <returns></returns> string GetConfig(string configKey); }