Мы знакомы с конфигурационными файлами, которые дают нам возможность динамически изменять выполнение программы. Чтобы процитировать кого-то еще:
Динамическая регулировка положения в полете во время работы системы
Я мог бы назвать нашу работуРемонт деталей на быстролетящем самолете. Мы, люди, всегда были не в состоянии все контролировать и предсказывать. Для нашей системы нам всегда нужно резервировать некоторые линии управления, чтобы вносить коррективы, когда нам нужно контролировать направление системы (например, управление оттенками серого, настройка ограничения тока), что особенно важно для интернет-индустрии, которая принимает изменения. Для автономной версии мы называем этоконфиг (файл), для распределенной кластерной системы мы называем этоЦентр конфигурации (система);Давайте поговорим о нашем центре конфигурации.
Камень других гор
- Центр конфигурации Лев:Е Мин Что/27/11/2017/…
- Введение в Центр конфигурации Apollo:GitHub.com/C trip Corp/Ах…
- Центр конфигурации сборки QConf:сегмент fault.com/ah/119000000…
- Основа динамической настройки - центр конфигурации:applecore.net/2016/03/18/…
- Хорошая длинная статья TM о центре конфигурации:Джумей.Taobao.org/2016/09/28/…
Развивающаяся конфигурация
Когда мы являемся отдельной службой, наша конфигурация обычно записывается в файл.Когда код выпускается, файл конфигурации и программа передаются на компьютер.
Когда количество пользователей бизнеса увеличивается, мы обычно развертываем наши сервисы на нескольких машинах (кластерах). На этом этапе выпуск конфигурации выглядит следующим образом:
ОК, так что конфигурация также может быть принята Быстрое расширение бизнеса привело к тому, что автономная служба оказалась не в состоянии удовлетворить потребности бизнеса. В это время необходимо вырезать один большой сервис, и сервис будет двигаться в сторону SOA (микросервиса).
Развертывание конфигурации таким образом — кошмар, и ее нельзя настроить быстро и динамично. Утрачен один из основных смыслов конфигурации. В настоящее время необходим упомянутый сегодня единый центр конфигурации.
Простая версия центра конфигурации
Возможности Центра конфигурации
- Конфигурация CRUD
- Изоляция различных конфигураций среды (разработка, тестирование, предварительная версия, оттенки серого/онлайн)
- Высокая производительность и высокая доступность
- Много запросов и высокий параллелизм
- Больше читайте и меньше пишите
Мы можем разработать следующий упрощенный центр конфигурации
Примечания к дизайну:
- Через систему OA добавляйте, удаляйте, изменяйте и проверяйте каждую конфигурацию (каждая конфигурация имеет уникальный идентификатор конфигурации).
- Чтобы различать конфигурации разных сред, один и тот же идентификатор конфигурации в каждой среде соответствует разным записям базы данных.
- Наконец, конфигурация сохраняется в базе данных mysql в формате json (для удобства редактирования и понимания).
- Внедрите кластер Redis для кэширования конфигурации (например, вы можете настроить конфигурацию так, чтобы она вступала в силу через 1 минуту после модификации).
- Настройте внешние службы и разверните несколько компьютеров в соответствии с требованиями к производительности.
- При необходимости могут быть введены записи об изменении истории конфигурации.
Во многих случаях это может в основном удовлетворить наши основные потребности в системе конфигурации, а добавление, удаление, изменение и проверка конфигурации могут допускать несогласованность данных в течение определенного периода времени.
В этой схеме, поскольку все конфигурации хранятся в централизованном кеше, у централизованного кеша также будет узкое место в производительности. Кроме того, каждый настроенный доступ должен инициировать запрос rpc (сетевой запрос), поэтому рассмотрите возможность введения локального кэша (localCache, например Ehcache) на стороне клиента.
Локальный кеш может ссылаться на мою предыдущую статью:[180409] Выбор и принцип локального кэша
Повышение удобства использования производительности Центра конфигураций
Принимая во внимание фактор снижения сетевых запросов, на стороне клиента вводится локальный кеш для решения проблемы высокой доступности, высокой производительности и масштабируемости системы.
По сравнению с первой версией точкой улучшения является введение локального кеша на стороне клиента. Запустите поток для асинхронного вызова службы конфигурации для обновления локальной конфигурации. Это уменьшает количество вызовов rpc.
Основанный на принципе данных CAP, этот метод обеспечивает только AP.В течение определенного периода времени будет иметь место несогласованность данных, но окончательная согласованность конфигурации будет гарантирована в конце. Как решить эту проблему несоответствия данных?
Улучшения согласованности данных в Configuration Center
К счастью, конфигурация обычно имеет только одну модификацию записи, поэтому вы можете уведомить службу приложений об очистке локального кэша и распределенного кэша после модификации конфигурации. Здесь можно ввести mq или ZooKeeper.
Наконец, за счет комбинации push и pull достигается согласованность данных.
личный
Добро пожаловать в мой технический блог, мы растем и развиваемся вместе.
Тоторо в деревне Линван:woooooo.brief.com/U/5ah 327A Абу 7…