Как я могу иметь сверхбыструю динамическую конфигурацию?

Question

Мы планируем перейти от серии статических файлов конфигурации, связанных с каждым развертыванием клиента.

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

Мы хотим отойти от этих статических конфигурационных файлов & mdash; в настоящее время они представляют собой нечто большее, чем просто пары ключ-значение, и использовать хеши и массивы Perl, но могут быть упрощены таким образом с некоторыми усилиями & mdash; и использовать что-то другое. который может жить в быстро отвечающей базе данных, LDAP или другом хранилище. Гибкие структуры LDAP - которые позволяют вложение / иерархию данных, я думаю, выглядят привлекательно, но мне было интересно, есть ли другие советы о том, как лучше всего это сделать, я не думаю, что LDAP действительно был разработан для этого, и это был вокруг в течение долгого времени.

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

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

Любой совет?

Geoff

Answer 1

Моим решением было поместить конфиг в ту же базу данных, что и приложение. Таким образом, я мог бы просто передать один коннектор БД в приложение, и он использовал бы правильную конфигурацию.

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

Для других приложений я использую локальный файл. Когда файл существует, данные конфигурации перечитываются. Вы можете сделать это во втором потоке или просто проверять файл каждый раз. Поскольку путь статический, ОС может оптимизировать этот доступ, пока он не займет очень мало времени. После прочтения конфига файл удаляется, поэтому я знаю, что перезагрузка произошла.

Answer 2

Это может быть своего рода «не ответ», но подумайте о следующем: пытаетесь ли вы решить обнаруженную проблему таким образом, чтобы в будущем появилось еще больше проблем? Вы упомянули свою зависимость от структур данных Perl, которые находятся внутри конфигурационных файлов. Предположим на мгновение, что все эти данные конфигурации находятся в РСУБД. Как бы вы пошли на репликацию функциональности, которую вы получаете «бесплатно» с вашим существующим подходом, в системе, которая предоставляет совершенно другой набор функций? Не могли бы вы в какой-то момент получить столбцы CLOB, содержащие ваши старые добрые структуры данных Perl?

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

Answer 3

отказ от ответственности: я работаю над инструментом, чтобы помочь развертыванию (но я не защищаю его использование для вас)

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