Как мы перевели конфигурирование наших сервисов с XML на YAML

Предыстория вопроса

Нашей компанией, среди прочего, разработаны несколько сервисов (точнее — 12), работающих бэкендом наших систем. Каждый из сервисов представляет собой Windows-службу и выполняет свои специфические задачи.

Хочется все эти сервисы перенести под *nix-ОС. Для этого надо отказываться от обёртки в виде Windows-служб и переходить с .NET Framework на .NET Standard.

Последнее требование приводит к необходимости избавиться от некоторого Legacy-кода, который не поддерживается в .NET Standard, в т.ч. от поддержки конфигурирования наших серверов через XML, реализованного с использованием классов из System.Configuration. Заодно таким образом решается и давняя проблема, связанная с тем, что в XML-конфигах мы время от времени ошибались при изменении настроек (например, иногда не туда ставили закрывающий тэг или забывали его вовсе), а замечательная читалка XML-конфигов System.Xml.XmlDocument молча проглатывает такие конфиги, выдавая совсем непредсказуемый результат.

Было решено перейти на конфигурирование через модный YAML. Какие проблемы при этом перед нами встали, и как мы их решили — в этой статье.

Что имеем

Как мы читаем конфигурацию из XML

Читаем XML стандартным и для большинства других проектов способом.

В каждом сервисе есть файл настроек .NET-проектов, называется AppSettings.cs, содержит все требующиеся сервису настройки. Примерно так:

[System.Configuration.SettingsProvider(typeof(PortableSettingsProvider))]
internal sealed partial class AppSettings : IServerManagerConfigStorage, 
                                            IWebSettingsStorage,
                                            IServerSettingsStorage, 
                                            IGraphiteAddressStorage, 
                                            IDatabaseConfigStorage, 
                                            IBlackListStorage, 
                                            IKeyCloackConfigFilePathProvider,
                                            IPrometheusSettingsStorage,
                                            IMetricsConfig
{
}

Подобная техника разделения настроек на интерфейсы позволяет удобно использовать их в дальнейшем через DI-контейнер.

Вся основная магия по хранению настроек на самом деле скрыта в PortableSettingsProvider (см. атрибут класса), а также в файле дизайнера AppSettings.Designer.cs:

[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "14.0.0.0")]
internal sealed partial class AppSettings : global::System.Configuration.ApplicationSettingsBase {
        
        private static AppSettings defaultInstance = ((AppSettings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new AppSettings())));        
        public static AppSettings Default {
            get {
                return defaultInstance;
            }
        }
        
        [global::System.Configuration.UserScopedSettingAttribute()]
        [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
        [global::System.Configuration.DefaultSettingValueAttribute("35016")]
        public int ListenPort {
            get {
                return ((int)(this["ListenPort"]));
            }
            set {
                this["ListenPort"] = value;
            }
        }
...

Как видно, «за кулисами» скрыты все те свойства, которые мы добавляем в конфигурацию сервера, когда редактируем ее через дизайнер настроек в Visual Studio.

Наш класс PortableSettingsProvider, упомянутый выше, занимается непосредственно чтением XML-файла, а прочитанный результат уже используется в SettingsProvider для записи настроек в свойства AppSettings.

Пример XML-конфига, который мы читаем (большая часть настроек скрыта из соображений безопасности):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup">
      <section name="MetricServer.Properties.Settings" type="System.Configuration.ClientSettingsSection" />
    </sectionGroup>
  </configSections>
  <userSettings>
    <MetricServer.Properties.Settings>      
      <setting name="MCXSettings" serializeAs="String">
        <value>Inactive, ChartLen: 1000, PrintLen: 50, UseProxy: False</value>
      </setting>
      <setting name="KickUnknownAfter" serializeAs="String">
        <value>00:00:10</value>
      </setting>
      ...
    </MetricServer.Properties.Settings>
  </userSettings>
</configuration>

Какие YAML-файлы хотелось бы читать

Примерно такие:

VirtualFeed:
    MaxChartHistoryLength: 10
    Port: 35016
    UseThrottling: True
    ThrottlingIntervalMs: 50000
    UseHistoryBroadcast: True
    CalendarName: "EmptyCalendar"
UsMarketFeed:
    UseImbalances: True

Проблемы перехода

Во-первых, конфиги в XML — «плоские», а в YAML — нет (поддерживаются секции и подсекции). Это хорошо видно в приведенных выше примерах. При использовании XML мы решали проблему плоских настроек вводом собственных парсеров, которые умеют строки определенного вида преобразовывать в наши более сложные классы. Пример такой сложной строки:

<setting name="MCXSettings" serializeAs="String">
   <value>Inactive, ChartLen: 1000, PrintLen: 50, UseProxy: False</value>
</setting>

Заниматься такими преобразованиями при работе с YAML совсем не хочется. Но при этом мы ограничены существующей «плоской» структурой класса AppSettings: все свойства настроек в нем свалены в одну кучу.

Во-вторых, конфиги наших серверов — это не статичный монолит, мы их время от времени меняем прямо по ходу работы сервера, т.е. эти изменения надо уметь отлавливать «на лету», в рантайме. Для этого в XML-реализации мы наследуем наш AppSettings от INotifyPropertyChanged (на самом деле от него унаследован каждый интерфейс, который реализует AppSettings) и подписываемся на события обновления свойств настроек. Работает такой подход от того, что базовый класс System.Configuration.ApplicationSettingsBase «из коробки» реализует INotifyPropertyChanged. Подобное поведение надо сохранить и после перехода на YAML.

В-третьих, конфигов по каждому серверу у нас, на самом деле, не один, а целых два: один с дефолтными настройками, другой — с переопределенными. Это требуется для того, чтобы в каждом из нескольких инстансов серверов одного типа, слушающих разные порты и имеющих немного отличающиеся настройки, не приходилось полностью копировать весь набор настроек.

И еще одна проблема — доступ к настройкам идет не только через интерфейсы, но и прямым обращением к AppSettings.Default. Напомню как он объявлен в закулисном AppSettings.Designer.cs:

private static AppSettings defaultInstance = ((AppSettings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new AppSettings())));        
public static AppSettings Default {
 get {
   return defaultInstance;
 }
}

С учетом изложенного требовалось придумать новый подход к хранению настроек в AppSettings.

Решение

Инструментарий

Непосредственно для чтения YAML решили использовать готовые библиотеки, доступные через NuGet:

• YamlDotNet — github.com/aaubry/YamlDotNet. Из описания библиотеки (перевод):
  

  YamlDotNet — это .NET библиотека для YAML. YamlDotNet предоставляет низкоуровневые парсер и генератор YAML, а также высокоуровневую объектную модель, схожую с XmlDocument. Также сюда включена библиотека сериализации, которая позволяет читать и записывать объекты из/в YAML-потоков.

  
  
• NetEscapades.Configuration — github.com/andrewlock/NetEscapades.Configuration. Это непосредственно провайдер конфигураций (в смысле Microsoft.Extensions.Configuration.IConfigurationSource, активно используемого в ASP.NET Core приложениях), который читает YAML-файлы, используя как раз, упомянутый выше YamlDotNet.
  

Подробнее о том, как использовать указанные библиотеки можно почитать вот тут.

Переход к YAML

Сам переход мы осуществили в два этапа: сначала просто перешли от XML к YAML, но сохранив плоскую иерархию конфиг-файлов, а затем уже ввели секции в YAML-файлах. Эти этапы можно было, в принципе, объединить в один, и для простоты изложения я именно так и сделаю. Все описываемые далее действия применялись последовательно к каждому сервису.

Подготовка YML-файла

Сперва требуется подготовить сам YAML-файл. Назовем его именем проекта (полезно для будущих интеграционных тестов, которые должны уметь работать с разными серверами и различать их конфиги между собой), положим файлик прямо в корне проекта, рядом с AppSettings:



В самом YML-файле для начала сохраним «плоскую» структуру:

VirtualFeed: "MaxChartHistoryLength: 10, UseThrottling: True, ThrottlingIntervalMs: 50000, UseHistoryBroadcast: True, CalendarName: EmptyCalendar"
VirtualFeedPort: 35016
UsMarketFeedUseImbalances: True

Наполнение AppSettings свойствами настроек

Перенесем все свойства из AppSettings.Designer.cs в AppSettings.cs, попутно избавляясь от ставших лишними атрибутов дизайнера и самого кода в get/set-частях.

Было:

[global::System.Configuration.UserScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("35016")]
public int VirtualFeedPort{
  get {
    return ((int)(this["VirtualFeedPort"]));
  }
  set {
    this["VirtualFeedPort"] = value;
  }
}

Стало:

public int VirtualFeedPort { get; set; }

Удалим полностью AppSettings.Designer.cs за ненадобностью. Теперь, кстати говоря, можно полностью избавиться от секции userSettings в файле app.config, если он есть в проекте — там хранятся те самые дефолтные настройки, которые мы прописываем через дизайнер настроек.
Идем дальше.

Контроль изменения настроек «на лету»

Так как нам надо уметь ловить обновления наших настроек в рантайме, то требуется реализовать INotifyPropertyChanged в нашем AppSettings. Базового System.Configuration.ApplicationSettingsBase больше нет, соответственно, рассчитывать на какую-то магию не приходится.

Можно реализовать «в лоб»: добавив имплементацию метода, выкидывающего нужное событие, и вызывая его в сеттере каждого свойства. Но это лишние строки кода, которые к тому же надо будет копировать по всем сервисам.

Поступим красивее — введем вспомогательный базовый класс AutoNotifier, который фактически делает то же самое, но «за кулисами», прямо как делал ранее System.Configuration.ApplicationSettingsBase:

/// <summary>
/// Implements <see cref="INotifyPropertyChanged"/> for classes with a lot of public properties (i.e. AppSettings).
/// This implementation is:
/// - fairly slow, so don't use it for classes where getting/setting of properties is often operation;
/// - not for properties described in inherited classes of 2nd level (bad idea: Inherit2 -> Inherit1 -> AutoNotifier; good idea: sealed Inherit -> AutoNotifier)
/// </summary>
public abstract class AutoNotifier : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;    
    private readonly ConcurrentDictionary<string, object> _wrappedValues = new ConcurrentDictionary<string, object>(); //just to avoid manual writing a lot of fields 

    protected T Get<T>([CallerMemberName] string propertyName = null)            
    {
        return (T)_wrappedValues.GetValueOrDefault(propertyName, () => default(T));            
    }

    protected void Set<T>(T value, [CallerMemberName] string propertyName = null) 
    {
        // ReSharper disable once AssignNullToNotNullAttribute
        _wrappedValues.AddOrUpdate(propertyName, value, (s, o) => value);
           
        OnPropertyChanged(propertyName);
    }

    public object this[string propertyName]
    {
        get { return Get<object>(propertyName); }
        set { Set(value, propertyName); }
    }        
        
    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

Здесь атрибут [CallerMemberName] позволяет автоматически получать название свойства вызывающего объекта, т.е. AppSettings.

Теперь мы можем занаследовать наш AppSettings от этого базового класса AutoNotifier, а далее каждое свойство несколько видоизменить:

public int VirtualFeedPort { get { return Get<int>(); } set { Set(value); } }

С таким подходом наши классы AppSettings, даже содержащие довольно много настроек, выглядят компактно, и при этом полноценно реализовывают INotifyPropertyChanged.

Да, я знаю, что можно было бы ввести чуть больше магии, используя, например, Castle.DynamicProxy.IInterceptor, перехватывая изменения необходимых свойств и рейзя там события. Но такое решение показалось мне слишком перегруженным.

Чтение настроек из YAML-файла

Следующим шагом добавим саму читалку YAML-конфигурации. Это происходит где-то поближе к старту сервиса. Скрывая излишние детали, не относящиеся к рассматриваемой теме, получится нечто подобное:

public static IServerConfigurationProvider LoadServerConfiguration(IReadOnlyDictionary<Type, string> allSections)
{
  IConfigurationBuilder builder = new ConfigurationBuilder().SetBasePath(ConfigFiles.BasePath);
  foreach (string configFile in configFiles)
  {
    string directory = Path.GetDirectoryName(configFile);
    if (!string.IsNullOrEmpty(directory)) //can be empty if relative path is used
    {
       Directory.CreateDirectory(directory);
    }
    builder = builder.AddYamlFile(configFile, optional: true, reloadOnChange: true);
  }
  IConfigurationRoot config = builder.Build();

  // load prepared files and merge them
  return new ServerConfigurationProvider<TAppSettings>(config, allSections);
}

В представленном коде ConfigurationBuilder, наверное, особого интереса не представляет — вся работа с ним аналогична работе с конфигами в ASP.NET Core. Но интерес представляют следующие моменты. Во-первых, «из коробки» мы получили также возможность объединять настройки из нескольких файлов. Это обеспечивает требование иметь хотя бы два конфиг-файла на каждый сервер, о чем я упоминал выше. Во-вторых, весь прочитанный конфиг мы передаем в некий ServerConfigurationProvider. Зачем?

Секции в YAML-файле

Ответим на этот вопрос попозже, а сейчас вернемся к требованию хранения иерархически структурированных настроек в YML-файле.

В принципе, реализовать это достаточно просто. Сначала в самом YML-файле введем требующуюся нам структуру:

VirtualFeed:
    MaxChartHistoryLength: 10
    Port: 35016
    UseThrottling: True
    ThrottlingIntervalMs: 50000
    UseHistoryBroadcast: True
    CalendarName: "EmptyCalendar"
UsMarketFeed:
    UseImbalances: True

А теперь пойдем в AppSettings и научим его разделять наши свойства по секциям. Как-то так:

public sealed class AppSettings : AutoNotifier,                                       
                                      IWebSettingsStorage,
                                      IServerSettingsStorage,
                                      IServerManagerAddressStorage,
                                      IGlobalCredentialsStorage,
                                      IGraphiteAddressStorage, 
                                      IDatabaseConfigStorage, 
                                      IBlackListStorage, 
                                      IKeyCloackConfigFilePathProvider, 
                                      IPrometheusSettingsStorage,
                                      IHeartBeatConfig,
                                      IConcurrentAcceptorProperties,
                                      IMetricsConfig
{
  public static IReadOnlyDictionary<Type, string> Sections { get; } = new Dictionary<Type, string>
  {
    {typeof(IDatabaseConfigStorage), "Database"},
    {typeof(IWebSettingsStorage), "Web"},
    {typeof(IServerSettingsStorage), "Server"},
    {typeof(IConcurrentAcceptorProperties), "ConcurrentAcceptor"},
    {typeof(IGraphiteAddressStorage), "Graphite"},
    {typeof(IKeyCloackConfigFilePathProvider), "Keycloak"},
    {typeof(IPrometheusSettingsStorage), "Prometheus"},
    {typeof(IHeartBeatConfig), "Heartbeat"},
    {typeof(IServerManagerAddressStorage), "ServerManager"},
    {typeof(IGlobalCredentialsStorage), "GlobalCredentials"},
    {typeof(IBlackListStorage), "Blacklist"},
    {typeof(IMetricsConfig), "Metrics"}
  };   
...     

Как видно, мы добавили прямо в AppSettings словарик, где ключами выступают типы интерфейсов, которые реализовывает класс AppSettings, а значениями — заголовки соответствующих секций. Теперь мы можем сопоставить иерархию в YML-файле с иерархией свойств в AppSettings (хотя и не глубже, чем один уровень вложенности, но в нашем случае этого было достаточно).

Почему мы делаем это прямо здесь — в AppSettings? Потому что таким образом мы не размазываем информацию о настройках по разным сущностям, а кроме того, это самое естественное место, т.к. в каждом сервисе и, соответственно, в каждом AppSettings, свои секции настроек.

Если не нужна иерархия в настройках?

В принципе странный кейс, но у нас такое было именно на первом этапе, когда просто переходили от XML к YAML, без использования преимуществ YAML.

В этом случае весь этот список секций можно не хранить, да и ServerConfigurationProvider будет значительно проще (рассматривается далее).

Но важный момент — если мы решим оставить плоскую иерархию, то мы как раз-таки сможем выполнить требование о сохранении возможности обращаться к настройкам через AppSettings.Default. Для этого добавим вот такой простой публичный конструктор в AppSettings:

public static AppSettings Default { get; }

public AppSettings()
{
  Default = this;
}

Теперь мы везде можем продолжать обращаться к классу с настройками через AppSettings.Default (при условии, что настройки уже были ранее прочитаны через IConfigurationRoot в ServerConfigurationProvider и, соответственно, AppSettings был проинстанциирован).

Если же плоская иерархия недопустима, то, как ни крути, придется избавляться от AppSettings.Default везде по коду и работать с настройками только через интерфейсы (что в принципе хорошо). Почему так — станет ясно дальше.

ServerConfigurationProvider

Специальный класс ServerConfigurationProvider, упомянутый ранее, занимается той самой магией, которая позволяет полноценно работать с новым иерархическим YAML-конфигом при наличии лишь плоского AppSettings.

Если не терпится — вот он.


ServerConfigurationProvider параметризирован по классу настроек AppSettings:

public class ServerConfigurationProvider<TAppSettings> : IServerConfigurationProvider 
          where TAppSettings : new()

Это, как нетрудно догадаться, позволяет применять его сразу во всех сервисах.

В конструктор передается сам прочитанный конфиг (IConfigurationRoot), а также упомянутый выше словарик секций (AppSettings.Sections). Там же происходит подписка на обновления файла (мы ведь хотим в случае изменения YML-файла сразу подтягивать эти изменения к нам в рантайм?):

_configuration.GetReloadToken()?.RegisterChangeCallback(OnConfigurationFileChanged, null);

...

private void OnConfigurationFileChanged(object _)
{            
  foreach (string sectionName in _cachedSections.Keys)
  {
    Type sectionInterface = _interfacesBySections[sectionName];

    TAppSettings newSection = ReadSection(sectionName, sectionInterface);
    TAppSettings oldSection;
    if (_cachedSections.TryGetValue(sectionName, out oldSection))
    {
      UpdateSection(oldSection, newSection);
    }                
  }
}

Как видно, тут мы в случае обновления YML-файла пробегаемся по всем известным нам секциям и читаем каждую. Затем, если секция уже была прочитана ранее в кэш (т.е. она где-то в коде уже запрашивалась каким-то классом), то переписываем старые значения в кэше новыми.

Казалось бы — зачем читать каждую секцию, почему бы не читать только те, которые в кэше (т.е. востребованные)? Потому что в чтении секции у нас реализована проверка на корректность конфигурации. И в случае некорректных настроек выкидываются соответствующие алерты, логируются проблемы. О проблемах в изменениях конфига лучше узнавать как можно скорее, от того читаем все секции сразу же.

Обновление старых значений в кэше новыми значениями достаточно тривиально:

private void UpdateSection(TAppSettings oldConfig, TAppSettings newConfig)
{
  foreach (PropertyInfo propertyInfo in typeof(TAppSettings).GetProperties().Where(p => p.GetMethod != null && p.SetMethod != null))
  {                
    propertyInfo.SetValue(newConfig, propertyInfo.GetValue(oldConfig));
  }
}

А вот с чтением секций не всё так просто:

private TAppSettings ReadSection(string sectionName, Type sectionInterface)
{
  TAppSettings parsed;
  try
  {
    IConfigurationSection section = _configuration.GetSection(sectionName);

    CheckSection(section, sectionName, sectionInterface);

    parsed = section.Get<TAppSettings>();
    if (parsed == null)
    {
      //means that this section is empty or all its properties are empty
      return new TAppSettings();
    }

    ReadArrays(parsed, section);
  }
  catch (Exception ex)
  {
    Logger.Fatal(ex, "Something wrong during reading section {0} in config", sectionName.SafeSurround());
    throw;
  }

  return parsed;
}

Тут мы, прежде всего, читаем саму секцию, используя стандартный IConfigurationRoot.GetSection. Затем как раз-таки проверяем корректность прочитанной секции.

Далее прочитанную секцию биндим к типу наших сеттингов: section.GetТут мы сталкиваемся с особенностью YAML-парсера — он не различает пустую секцию (без параметров, т.е. отсутствующую) от секции, в которой все параметры пустые.

Вот подобный кейс:

VirtualFeed:
    Names: []

Тут в секции VirtualFeed есть параметр Names с пустым списком значений, но YAML-парсер, к сожалению, скажет, что секция VirtualFeed вообще полностью пустая. Печально.

Ну и напоследок в этом методе реализовано немного уличной магии для поддержки IEnumerable-свойств в настройках. Добиться нормального чтения списков «из коробки» у нас не получилось.

ReadArrays(parsed, section);

...

/// <summary>
/// Manual reading of array properties in config
/// </summary>
private void ReadArrays(TAppSettings settings, IConfigurationSection section)
{
  foreach (PropertyInfo propertyInfo in GetPublicProperties(typeof(TAppSettings), needSetters: true).Where(p => typeof(IEnumerable<string>).IsAssignableFrom(p.PropertyType)))
  {
    ClearDefaultArrayIfOverridenExists(section.Key, propertyInfo.Name);

	IConfigurationSection enumerableProperty = section.GetSection(propertyInfo.Name);
	propertyInfo.SetValue(settings, enumerableProperty.Get<IEnumerable<string>>());
  }
}

/// <summary>
/// Clears array property from default config to use overriden one.
/// Standard implementation merges default and overriden array by indexes - this is not what we need
/// </summary>
private void ClearDefaultArrayIfOverridenExists(string sectionName, string propertyName)
{
  List<IConfigurationProvider> providers = _configuration.Providers.ToList();
  if (providers.Count == 0)
  {
    return;
  }

  string propertyTemplate = $"{sectionName}:{propertyName}:";
  if (!providers[providers.Count - 1].TryGet($"{propertyTemplate}{0}", out _))
  {
    //we should use array from default config, because overriden config has no overriden array
    return;
  }

  foreach (IConfigurationProvider provider in providers.Take(providers.Count - 1))
  {
    for (int i = 0; ; i++)
    {
      string propertyInnerName = $"{propertyTemplate}{i}";
      if (!provider.TryGet(propertyInnerName, out _))
      {
        break;
      }

      provider.Set(propertyInnerName, null);
    }
  }
}

Как видно, мы находим все свойства, тип которых унаследован от IEnumerable и присваиваем в них значения из фиктивной «секции», именованной также как и интересующая нас настройка. Но перед этим не забываем проверить: а есть ли переопределенное значение этого перечислимого свойства во втором конфиг-файле? Если есть — то только его и берем, а настройки, прочитанные из базового конфиг-файла, зачищаем. Если этого не делать, то оба свойства (из базового файла и из переопределенного) будут автоматически слиты в один массив на уровне IConfigurationSection, причем ключами для объединения послужат индексы массивов. Получится какая-то мешанина вместо нормального переопределенного значения.

Показанный метод ReadSection в итоге используется и в главном методе класса: FindSection.

[CanBeNull]
public object FindSection(Type sectionInterface)
{
  string sectionName = FindSectionName(sectionInterface);
  if (sectionName == null)
  {                
    return null;
  }

  //we must return same instance of settings for same requested section (otherwise changing of settings will lead to inconsistent state)
  return _cachedSections.GetOrAdd(sectionName, typeName => ReadSection(sectionName, sectionInterface));
}

В принципе, тут и становится ясно, почему при поддержке секций мы никак не можем поддерживать AppSettings.Default: каждое обращение к новой (ранее непрочитанной) секции настроек через FindSection на самом деле будет выдавать нам новый инстанс класса AppSettings, хоть и прикастенный к нужному интерфейсу, и, соответственно, если бы мы использовали AppSettings.Default, то он бы переопределялся при каждом чтении новой секции и содержал бы означенными лишь те настройки, которые относятся к последней прочитанной секции (остальные имели бы дефолтные значения — NULL и 0).

Проверка корректности настроек в секции реализована следующим образом:

private void CheckSection(IConfigurationSection section, string sectionName, Type sectionInterface)
{
  ICollection<PropertyInfo> properties = GetPublicProperties(sectionInterface, needSetters: false);            

  var configProperties = new HashSet<string>(section.GetChildren().Select(c => c.Key));
  foreach (PropertyInfo propertyInfo in properties)
  {
    if (!configProperties.Remove(propertyInfo.Name))
    {
      if (propertyInfo.PropertyType != typeof(string) && typeof(IEnumerable).IsAssignableFrom(propertyInfo.PropertyType))
      {
        //no way to distinguish absent array and empty array :(
        Logger.Debug("Property {0} has no valuable items in configs section {1}", propertyInfo.Name, sectionName.SafeSurround());
      }
      else
      {
        Logger.Fatal("Property {0} not found in configs section {1}", propertyInfo.Name, sectionName.SafeSurround());
      }
    }
  }
  if (configProperties.Any())
  {
    Logger.Fatal("Unexpected config properties {0} in configs section {1}", configProperties.SafeSurroundAndJoin(), sectionName.SafeSurround());
  }
}

Тут прежде всего извлекаются все публичные свойства интересующего нас интерфейса (читай — секции настроек). И по каждому из этих свойств ищется соответствие в прочитанных настройках: если соответствие не найдено, то логируется соответствующая проблема, ведь это означает, что в файле конфига не хватает какой-то настройки. В конце дополнительно проверяется, остались ли какие-либо из прочитанных настроек несопоставленными с интерфейсом. Если такие есть, то опять же логируется проблема, т.к. это означает, что в файле конфига обнаружены свойства, не описанные в интерфейсе, чего тоже не должно быть в нормальной ситуации.

Возникает вопрос — а откуда у нас требование, что в прочитанном файле все настройки должны соответствовать имеющимся в интерфейсе по принципу «один-к-одному»? Дело в том, что на самом деле, как упоминалось выше, на этот момент прочитан не один файл, а сразу два — один с дефолтными настройками, а другой с переопределенными, и оба они смержены. Соответственно, на самом деле мы смотрим настройки не из одного файла, а полные. И в этом случае, конечно же, их набор должен соответствовать ожидаемым настройкам один к одному.

Также обратите внимание в приведенных выше исходниках на метод GetPublicProperties, который, казалось бы, всего лишь возвращает все публичные свойства интерфейса. Но он не так прост, как могло бы быть, по той причине, что иногда у нас интерфейс, описывающий настройки сервера, наследуется от другого интерфейса, и, соответственно, есть необходимость просматривать всю иерархию интерфейсов с тем, чтобы найти все публичные свойства.

Получение настроек сервера

С учетом изложенного выше для получения настроек сервера везде по коду мы обращаемся к интерфейсу следующего вида:

/// <summary>
/// Provides different configurations for current server
/// </summary>
public interface IServerConfigurationProvider
{
  TSettingsSectionInterface FindSection<TSettingsSectionInterface>() where TSettingsSectionInterface : class;
  object FindSection(Type sectionInterface);
  IEnumerable<Type> AllSections { get; }
}

Первый метод этого интерфейса — FindSection — позволяет обращаться к интересующей секции настроек. Как-то так:

IThreadPoolProperties threadPoolProperties = ConfigurationProvider.FindSection<IThreadPoolProperties>();

Зачем нужны второй и третий метод — объясню далее.

Регистрация интерфейсов настроек

У нас в проекте в качестве IoC-контейнера используется Castle Windsor. Именно он поставляет в том числе и интерфейсы настроек сервера. Соответственно, эти интерфейсы требуется в нем зарегистрировать.

С этой целью написан простой Extension-класс, позволяющий упростить эту процедуру, чтобы не писать регистрацию всего набора интерфейсов в каждом сервере:

public static class ServerConfigurationProviderExtensions
{        
  public static void RegisterAllConfigurationSections(this IWindsorContainer container, IServerConfigurationProvider configurationProvider)
  {
    Register(container, configurationProvider, configurationProvider.AllSections.ToArray());
  }

  public static void Register(this IWindsorContainer container, IServerConfigurationProvider configurationProvider, params Type[] configSections)
  {
    var registrations = new IRegistration[configSections.Length];
    for (int i = 0; i < registrations.Length; i++)
    {
      Type configSection = configSections[i];
      object section = configurationProvider.FindSection(configSection);                
      registrations[i] = Component.For(configSection).Instance(section).Named(configSection.FullName);
    }
    container.Register(registrations);
  }        
}    

Первый метод позволяет зарегистрировать все секции настроек (для этого и нужно свойство AllSections в интерфейсе IServerConfigurationProvider).

А второй метод используется в первом, и он автоматически читает заданную секцию настроек с использованием нашего ServerConfigurationProvider, тем самым записывает ее сразу в кэш ServerConfigurationProvider и регистрирует в Windsor.
Именно здесь и используется второй, непараметризированный, метод FindSection из IServerConfigurationProvider.

Остаётся лишь позвать в коде регистрации контейнера Windsor наш Extension-метод:

container.RegisterAllConfigurationSections(configProvider); 

Вывод

Что получилось

Представленным способом удалось достаточно безболезненно перевести все настройки наших серверов с XML на YAML, при этом произведя минимум изменений по существующему коду серверов.

YAML-конфигурации, в отличие от XML, получились более читаемыми за счет не только большей лаконичности, но и поддержки разбиения на секции.

Мы не изобретали собственных велосипедов для парсинга YAML, а использовали готовые решения. Тем не менее, для интеграции их в реалии нашего проекта потребовались некоторые ухищрения, описанные в этой статье. Надеюсь, они будут полезны и читателям.

Удалось сохранить возможность отлавливания изменений настроек в веб-мордах наших серверов «на лету». Более того, бонусом появилась возможность также налету отлавливать изменения в самом YAML-файле (ранее приходилось перезагружать сервер при любых изменений в конфиг-файлах).

Мы сохранили возможность мержа двух файлов конфигов — дефолтных и переопределенных настроек, причем сделали это с использованием сторонних решений «из коробки».

Что не очень получилось

Пришлось отказаться от имевшейся ранее возможности сохранения изменений, примененных из веб-морд наших серверов, в конфиг-файлы, т.к. поддержка такой функциональности потребовала бы больших телодвижений, а бизнес-задачи перед нами такой в общем-то не стояло.

Ну и также пришлось отказаться от обращений к настройкам через AppSettings.Default, но это скорее плюс, чем минус.