配置的同步[设计篇]
本节所谓的“配置同步”主要体现在两个方面：其一，如何监控配置源并在其变化的时候自动加载其数据，其目的是让应用中通过Configuration对象承载的配置与配置源的数据同步；其二、当Configuration对象承载的配置放生变换的时候如何向应用程序发送通知，最终让应用程序使用最新的配置。
一、配置与配置源的同步
配置模型提供了三个原生ConfigurationProvider（JsonConfigrationProvider、XmlConfigurationProvider和IniConfigurationProvider）使我们可以将三种格式（JSON、XML和INI）的文件作为配置原始数据的来源，所以针对物理文件的配置同步是配置同步机制的一个主要的应用领域。在上面演示的实例中，基于物理文件的同步是通过调用ConfigurationRoot的扩展方法ReloadOnChanged来实现的。
这个扩展方法定义在NuGet包“Microsoft.Extensions.Configuration.FileProviderExtensions”之中，除了在我们演示的实例中使用的那个方法之外，这个ReloadOnChanged方法还具有如下两个额外的重载。对于这三个ReloadOnChanged方法重载来说，最终的实现均落在第三个重载上。至于最本质的物理文件监控的功能则由一个名为FileProvider的对象负责。
1: public static class FileProviderExtensions
2: {
3: public static IConfigurationRoot ReloadOnChanged(
4: this IConfigurationRoot config, string filename);
5:
6: public static IConfigurationRoot ReloadOnChanged(
7: this IConfigurationRoot config, string basePath, string filename);
8:
9: public static IConfigurationRoot ReloadOnChanged(this IConfigurationRoot config,
10: IFileProvider fileProvider, string filename);
11: }
这里所谓的FileProvider是对所有实现了IFileProvider接口的类型及其对象的统称。IFileProvier接口定义在命名空间“Microsoft.AspNet.FileProviders”下，它通过定义其中的方法提供抽象化的目录与文件信息，针对文件监控相关的方法也定义在这个接口下。如下面的代码片段所示，IFileProvier具有三个方法，其中GetDirectoryContents和GetFileInfo用于提供目录和文件的相关信息，我们只需要关注旨在监控文件变化的Watch方法。
1: public interface IFileProvider
2: {
3: IDirectoryContents GetDirectoryContents(string subpath);
4: IFileInfo GetFileInfo(string subpath);
5: IChangeToken Watch(string filter);
6: }
一个FileProvider总是针对一个具体的目录，Watch方法的参数filter旨在帮助筛选出需要监控的文件。这个参数是一个可以携带通配符（“*”）的字符串，比如 “ *.*”则表示所有文件，而“ *.json”则表示所有扩展名为“ .json”的文件。如果我们需要监控当前目录下某个确定的文件，直接将文件名作为参数即可。Watch方法的返回类型为具有如下定义的IChangeToken接口，我们可以将它理解为一个用于传递数据变换通知的令牌。
1: public interface IChangeToken
2: {
3: bool HasChanged { get; }
4: bool ActiveChangeCallbacks { get; }
5:
6: IDisposable RegisterChangeCallback(Action<object> callback, object state);
7: }
IChangeToken的只读属性HasChanged表示目标数据是否发生改变。我们可以通过调用它的RegisterChangeCallback方法注册一个在数据发生变化时需要执行的回调操作。该方法返回的对象对应的类型必须实现IDisposable接口，回调注册的接触可以通过Dispose方法来完成。至于IChangeToken接口的另个只读属性ActiveChangeCallbacks表示当数据发生变化时是否需要主动执行注册的回调操作。实际上IConfiguration的GetReloadToke方法的返回类型就是这么一个接口，至于该方法具体返回一个怎样的对象，我们会在下一节予以介绍。
当我们指定一个具体的FileProvider对象调用ConfigurationRoot的扩展方法ReloadOnChanged时，后者会调用这个FileProvider的RegisterChangeCallback方法以注册一个在指定文件发生变化时的回调。至于这个注册的回调，它会调用ConfigurationRoot的Reload方法实现对配置数据的重新加载。由于注册了这样一个回调，该方法只需要调用FileProvider的Watch方法监控指定文件的变化即可，如下所示的代码片段基本上体现了ReloadOnChanged方法的逻辑。
1: public static IConfigurationRoot ReloadOnChanged(
2: this IConfigurationRoot config, IFileProvider fileProvider, string filename)
3: {
4: Action<object> callback = null;
5: callback = _ =>
6: {
7: config.Reload();
8: fileProvider.Watch(filename).RegisterChangeCallback(callback, null);
9: };
10: fileProvider.Watch(filename).RegisterChangeCallback(callback, null);
11: return config;
12: }
如果我们通过指定目录和文件名调用另一个ReloadOnChanged方法重载，后者会根据指定的目录创建一个PhysicalFileProvider对象并作为参数调用上面这个重载。顾名思义，PhysicalFileProvider是一个针对具体物理文件的FileProvider，它实际上是借助一个FileSystemWatcher对象来监控指定的文件。这个ReloadOnChanged方法的实现逻辑体现在如下所示的代码片段中。当我们仅仅指定监控文件名调用第一个ReloadOnChanged方法重载时，该方法会将当前应用所在的目录作为参数调用上面一个重载。
1: public static class FileProviderExtensions
2: {
3: public static IConfigurationRoot ReloadOnChanged(
4: this IConfigurationRoot config, string basePath, string filename)
5: => config.ReloadOnChanged(new PhysicalFileProvider(basePath), filename);
6: //其他成员
7: }
二、应用重新加载的配置
ConfigurationRoot通过扩展方法ReloadOnChanged方法与一个具体的物理文件绑定在一起，针对该文件的任何修改操作都会促使Reload方法的调用，进而保证自身承载的数据总是与配置源保持同步。现在我们来讨论配置同步的另一个话题，即如何在不重启应用程序的情况下使用新的配置。要了解这个问题的解决方案，我们得先来聊聊定义在IConfiguration接口中这个一直刻意回避的方法GetReloadToken。
1: public interface IConfiguration
2: {
3: //其他成员
4: IChangeToken GetReloadToken();
5: }
如上面的代码片段所示，这个GetReloadToken方法的返回类型为上面讨论过的IChangeToken接口，我们说可以将后者视为一个传递数据变化信息的令牌。对于一个Configuration对象来说，它所谓的数据变换体现作为配置根节点的ConfigurationRoot对象的重新加载，所以这个方法返回的ChangeToken对象体现了最近一次加载引起的配置变化。
1: public class ConfigurationReloadToken : IChangeToken
2: {
3: public void OnReload();
4: public IDisposable RegisterChangeCallback(Action<object> callback,
5: object state);
6:
7: public bool ActiveChangeCallbacks { get; }
8: public bool HasChanged { get; }
9: }
对于实现了IConfiguration接口的两个默认类型（ConfigurationRoot和ConfigurationSection）来说，它们的GetReloadToken方法返回的是一个ConfigurationReloadToken对象。如上面的代码片段所示，除了实现定义在IConfiguration接口中的所有成员之外，ConfigurationReloadToken还具有另一个名为OnReload的方法。当配置数据发生变化，也就是调用通过ConfigurationRoot的Reload方法重新加载配置的时候，这个方法会被调用用以发送“配置已经发生变化”的信号。
实现在ConfigurationReloadToken之中用于传递配置变化的逻辑其实很简单，具体的逻辑是借助于一个CancellationTokenSource对象来完成。如果读者朋友们了解针对Task的异步编程，相信对这个类型不会感到陌生。总的来说，我们可以利用CancellationTokenSource向某个异步执行的Task发送“取消任务”的信号。
1: public class ConfigurationReloadToken : IChangeToken
2: {
3: private CancellationTokenSource tokenSource = new CancellationTokenSource();
4:
5: public void OnReload() => tokenSource.Cancel();
6: public IDisposable RegisterChangeCallback(Action<object> callback, object state)
7: => tokenSource.Token.Register(callback, state);
8:
9: public bool ActiveChangeCallbacks { get; } = true;
10: public bool HasChanged
11: {
12: get { return tokenSource.IsCancellationRequested; }
13: }
14: }
如上面的代码片段所示，ConfigurationReloadToken本质上就是一个CancellationTokenSource对象的封装。当OnReload方法被调用的时候，它直接调用CancellationTokenSource的Cancel方法发送取消任务的请求，而HasChanged属性则通过CancellationTokenSource的IsCancellationRequested属性通过判断任务取消请求是否发出来判断配置数据是否发生变化。通过RegisterChangeCallback注册的回调最终注册到由CancellationTokenSource创建的CancellationToken对象上，所以一旦OnReload方法被调用，注册的回调会自动执行。ConfigurationReloadToken的ActiveChangeCallbacks属性总是返回True。
ConfigurationRoot和ConfigurationSection这两个类型分别采用如下的形式实现了GetReloadToken方法。我们从给出的代码片段不难看出所有的ConfigurationSection对象和作为它们根的ConfigurationRoot对象来说，它们的GetReloadToken方法在同一时刻返回的是同一个ConfigurationReloadToken对象。当ConfigurationRoot的Reload方法被调用的时候，当前ConfigurationReloadToken对象的OnReload方法会被调用，在此之后一个新的ConfigurationReloadToken对象会被创建出来并代替原来的对象。
1: public class ConfigurationRoot : IConfigurationRoot
2: {
3: private ConfigurationReloadToken reloadToken = new ConfigurationReloadToken();
4:
5: public IChangeToken GetReloadToken()
6: {
7: return reloadToken;
8: }
9:
10: public void Reload()
11: {
12: //省略重新加载配置代码
13: Interlocked.Exchange<ConfigurationReloadToken>(ref this._reloadToken,
14: new ConfigurationReloadToken()).OnReload();
15: }
16: //其他成员
17: }
18:
19: public class ConfigurationSection : IConfigurationSection, IConfiguration
20: {
21: private readonly ConfigurationRoot root;
22: public IChangeToken GetReloadToken()
23: {
24: return root.GetReloadToken();
25: }
26: //其他成员
27: }
正是因为GetReloadToken方法并不能保证每次返回的都是同一个ConfigurationReloadToken对象，所以当我们注册配置加载回调时，需要在回调中完成针对新的ConfigurationReloadToken对象的回调注册，实际上我们上面演示的实例就是这么做的。除此之外，调用RegisterChangeCallback方法会返回一个类型实现了IDisposable 接口的对象，不要忘记调用它的Dispose方法以免产生一些内存泄漏的问题。
1: public class Program
2: {
3: private static IDisposable callbackRegistration;
4: private static void OnSettingChanged(object state)
5: {
6: callbackRegistration?.Dispose();
7: IConfiguration configuration = (IConfiguration)state;
8: Console.WriteLine(configuration.Get<ThreadPoolSettings>());
9: callbackRegistration = configuration.GetReloadToken()
10: .RegisterChangeCallback(OnSettingChanged, state);
11: }
12: }
ASP.NET Core的配置（1）：读取配置信息
ASP.NET Core的配置（2）：配置模型详解
ASP.NET Core的配置（3）： 将配置绑定为对象[上篇]
ASP.NET Core的配置（3）： 将配置绑定为对象[下篇]
ASP.NET Core的配置（4）：多样性的配置源[上篇]
ASP.NET Core的配置（4）：多样性的配置源[中篇]
ASP.NET Core的配置（4）：多样性的配置源[下篇]
ASP.NET Core的配置（5）：配置的同步[上篇]
ASP.NET Core的配置（5）：配置的同步[下篇]
微信公众账号：大内老A