毫不犹豫的说，现代高速发展的互联网造就了一批又一批的网络红人，这一批批网红又极大的催生了特定平台的一大波流量，但是留给了程序员却是一地鸡毛，无论是运维还是开发，每天都会担心服务器崩溃，程序down机。还是怀念以前那些单机结构呀，甚至有点嫉妒那些做内网几乎没有访问量的应用的程序员，不用加班，不用提心吊胆，更不用每年买霸王洗发露。
提到单机架构，在互联网应用中肯定是吃不开的，流量高峰冲击的你可以怀疑人生。单机升级集群，带来的不止是技术上的挑战，在顶住流量高峰，迎合业务的同时，也引入了配置的复杂性。这也是我今天要谈的主题：配置管理。在单机时代，无论是什么语言，java也好，c#也罢，一个配置文件足以。随着所谓微服务这个看似能解决一切问题的方案诞生，同时也引入了更加复杂的配置问题：服务的信息，服务的各种参数，配置更新问题等。可想而知，假如你的服务有100台服务器，修改一个配置项，利用单体架构逐个更新的方式是一个多么蛋疼的事情，传统的配置文件方式已经无法满足开发人员对于配置管理的要求：
- 安全性。配置信息如果随代码一起发布，容易造成配置泄露。
- 实时性。修改配置，传统的单机架构必须重启服务才能生效。
- 局限性。无法支持动态调整，像最普通的日志开关功能，也不能做到。
- 环境区分。传统的配置文件方式，很难区分生产，开发，测试环境。
- 配置修改记录问题。静态配置文件方式，很难追踪这个配置文件的修改记录。
针对以上问题，有的公司采用数据库记录配置来解决问题，不是说不可以，只不过数据库并不能解决根本性问题，举个很简单的例子：有最新的记录修改，客户端怎么能实时得到通知呢？虽然可以利用其他方案来解决，但是基于数据库方式并非是最优的。
配置中心无论是采用数据库方式也好，还是采用其他方式也罢，最本质的出发点还是要看业务具体需求和相应的可以投入的人力物力。不是说像携程的apollo不好，而是说这样一套庞大的配置系统是否适用于你的公司，是否适用于你的业务。在很多情况下，公司的业务发展在一定阶段讲究的是短平快，没有必要也没有时间去投入精力去深研究一套庞大的系统，在业务慢慢发展起来之后可以慢慢迭代，这才是系统架构升级的过程，那些业务之初就要建立淘宝级架构的，最终会落得人人疲惫。
说了这么多，我就是想撸一套简约的，可落地的配置中心，要保证配置中心能正常工作，有几点是在设计之初要考虑的：
需要一个可靠的，强一致性的存储来支撑
在经过了多次技术调研之后，我最终选择了ETCD，并非因为我喜欢最求热点，而是ETCD在应对场景，功能上恰好对应我的需求，
- 简单：安装配置简单，而且提供了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 name="configKey">配置的名称</param>
/// <param name="version">版本号</param>
/// <returns></returns>
string GetConfig(string configKey);
}
抽象出这个操作接口之后，至于具体怎么样实现，可以是基于ETCD，可以是基于Consul，甚至可以基于DB，可见面向接口编程是多么的正确。
在网络故障等情况下需要能继续工作
在互联网应用中，始终存在一个真理：网络是不可靠的。配置中心作为公司的一个核心系统来说，要尽可能的保证能提供服务。但是，也要做好了预防措施，以防在配置中心短暂不可用的期间，不影响适用方。对于使用client端来说，既然服务端保证不了高可用，那就需要在本地动手脚：可以把获取到的配置信息在本地做存储，信息并随着watch机制做持久化。这样在配置中心网络不可用的情况下，尽量保证客户端程序可用。至于本地存储的方式，无所谓了，就算了文本文件，还是sqllite都可以。
性能要高
配置中心最显著的一个业务特点是变化不频繁，但是客户端使用频繁。所以我们可以把配置信息加载在内存中，内存中的数据随着watch机制改变而改变，这样就做到了内存数据和服务端数据高度一致。
以上啰嗦了那么多，相信你们也看累了，空谈理论谁都会，落地代码才是真理。
客户端配置中心接口
/// <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 name="configKey">配置的名称</param>
/// <param name="version">版本号</param>
/// <returns></returns>
string GetConfig(string configKey);
}
/// <summary>
/// 环境的定义
/// </summary>
public enum EnvEnum
{
/// <summary>
/// 本地环境
/// </summary>
Local=1,
/// <summary>
/// 开发环境
/// </summary>
DEV,
/// <summary>
/// 仿真环境
/// </summary>
UAT,
/// <summary>
/// 生产环境
/// </summary>
PRO
}
public class ConfigCenterETCDProvider : ConfigCenterBaseProvider, IConfigCenterClient
{
//配置发生改变的通知事件
public event Action<string, string, string> ConfigValueChangedEvent;
//有异常发生的时候的事件
public override event Action<Exception> ErrorOccurredEvent;
//etcd的配置
private ConfigCenterETCDOption option { get; set; }
private EtcdClient client = null;
internal ConfigCenterETCDProvider(ConfigCenterBaseOption _option) : base(_option)
{
if (_option == null)
{
throw new Exception("config is null!");
}
option = _option as ConfigCenterETCDOption;
if (option == null)
{
throw new Exception("option type is wrong!");
}
if (string.IsNullOrWhiteSpace(option.ConnectionString))
{
//默认地址
option.ConnectionString = "http://127.0.0.1";
}
client = new EtcdClient(option.ConnectionString, option.Port, option.Username, option.Password, option.CaCert, option.ClientCert, option.ClientKey, option.PublicRootCa);
client.WatchRange(WatchPath, ETCDWatchEvent, exceptionHandler: e =>
{
ErrorOccurredEvent?.Invoke(e);
Thread.Sleep(1000);
});
//读取本地文件只初始化读取一次
InitConfigMapFromLocal();
}
#region 实现的接口方法
//设置某个配置的值
public bool SetConfig(string configKey, string configValue)
{
string key = FillConfigKey(configKey);
try
{
var putRet = client.Put(key, configValue);
}
catch (Exception e)
{
ErrorOccurredEvent?.Invoke(e);
return false;
}
return true;
}
//删除某个配置的值
public bool DeleteConfig(string configKey)
{
string key = FillConfigKey(configKey);
try
{
client.Delete(key);
}
catch (Exception e)
{
ErrorOccurredEvent?.Invoke(e);
return false;
}
return true;
}
#endregion
#region 基类 方法
//etcd 组织key
protected override string FillConfigKey(string configKey)
{
return $"{WatchPath}/{configKey}";
}
//etcd 获取远程key
protected override (bool isSuccess, string value) GetValueFromServer(string configKey)
{
try
{
var value = client.GetVal(configKey);
return (true, value);
}
catch (Exception e)
{
ErrorOccurredEvent?.Invoke(e);
return (false, null);
}
}
#endregion
#region 私有方法
//监控value 变化的事件
private void ETCDWatchEvent(WatchEvent[] response)
{
lock (ConfigCenterBaseProvider.ObjLock)
{
foreach (WatchEvent e in response)
{
if (e.Type == Mvccpb.Event.Types.EventType.Delete)
{
if (ConfigMap.ContainsKey(e.Key))
{
ConfigMap.Remove(e.Key);
}
}
else
{
ConfigMap[e.Key] = e.Value;
}
Console.WriteLine(JsonConvert.SerializeObject(ConfigMap));
if (ConfigValueChangedEvent != null)
{
ConfigValueChangedEvent.Invoke(e.Key, e.Value, e.Type.ToString());
}
}
if (response != null && response.Any())
{
//把最新的值写会本地文件
FlushLocalFileFromMap();
}
}
}
#endregion
}
鉴于代码有点多，这里不再贴出，有兴趣的小伙伴，可以添加菜菜微信或者公众号"架构师修行之路"回复“配置中心”，基于ETCD完整的简约版配置中心全部代码奉上，最后来看张测试的图