Xml по сравнению с Базой данных для конфигурации приложения
Вы можете использовать соответствующий AWS SDK для вызова Lambda (даже если он находится в VPC). Однако лямбда, совершающая вызов, будет нуждаться в доступе в Интернет (шлюз NAT).
Лучший способ сделать это (IMO) - связать их через SNS. Итак, вот некоторые соответствующие ссылки:
4 ответа
У нас был очень хороший опыт с хранением конфигурации в базе данных для длинных запущенных приложений (как веб-сайты и сервисы). Преимущества:
- Можно отредактировать конфигурацию удаленно и надежно (пользователя/пароль)
- Просто для приложения взять изменения (
select max(lmod) from config) автоматически или сигналом (проверяют с помощью ping-запросов веб-страницу или создают пустой файл где-нибудь), - Для приложения только нужен единственный объект конфигурации на среду (dev, тест, напоминание): DB для использования. Если у Вас есть сервер приложений, Ваши приложения являются конфигурацией, свободной для всех сред.
Основной проблемой является редактирование, если у Вас есть сложная, иерархическая структура конфигурации со значениями по умолчанию, списками и наследованием. Наши решения:
- Таблица конфигурации имеет эти строки: Приложение varchar (32), Ключ varchar (512), Значение varchar (4096)
- Один дБ на среду (локальная машина разработчика, тест разработки, интеграционный тест, производство)
- Ключ является иерархическим (option.suboption.... называют),
- Значения по умолчанию используют "опцию.. назовите" (например, "jdbc.. драйвер", так как мы используем только один тип базы данных),
- Списки хранятся как строки, разделенные новой строкой.
- Карты являются хранилищами как строками, "name=value\n"
- Существует реализация, которая может считать конфигурацию из файла (для модульных тестов). Отобразите каждую иерархию ключа к элементу (......)
Объекты конфигурации скрывают эти детали, таким образом, приложение просто работает с объектами.
Специальный класс ответственен за перечитывание конфигурации в случае изменения. Обычно, мы обновляем конфигурацию, некоторое время в течение дня и синхронизированного задания перезагрузит ее после закрытия. Таким образом, мы никогда не должны синхронизировать методы конфигурации.
История резервного копирования и история изменений были проблемой, все же. Мы зафиксировали это при помощи XML-файлов в VCS, которые затем "загружаются" на DB. Таким образом, мы могли проверить производственную конфигурацию прежде, чем загрузить его (при помощи его со специальным набором модульных тестов на машине разработчика). Когда это было активировано в течение ночи, это обычно работало правильно далеко, и оператор, ответственный за приложение, должен будет просто сделать определенное тестирование.
По моему скромному мнению, конфигурация должна жить в файлах, файлы работают хорошо на людей, и они хорошо для компьютеров. DBS работает хорошо на большие данные, но они - излишество для человеческого материала. Эти два являются обычно взаимоисключающими, и когда Вы действительно пытаетесь объединить их, Вы получаете что-то как реестр - uggh.
Почему бы не оставить конфигурацию в файле и сборку DAL и уровень служб вокруг этого так, чтобы Ваши приложения могли использовать его. Это предполагает, что можно разместить на центральный сервер, если не имеют несколько копий файла в дикой природе.
Используя базу данных (возможно, для хранения этого XML-файла конфигурации, если Вы хотите сохранить формат) имеет преимущества - Вы можете регистрировать/контролировать изменения в конфигурации и также копируете и восстановление.
В основном Ваш вопрос (способ, которым я вижу его) смешивает две вещи,
- Каким форматом конфигурация должна быть в (xml, .ini файл, и т.д.)
- Где это должно быть сохранено (плоский файл на диске, столбце таблицы в базе данных)
Вы могли легко сохранить XML-файл конфигурации в базе данных и обеспечить интерфейс для редактирования/отображения информации.
Файлы конфигурации должны быть большинством самых легких вещей обработать - таким образом помещает их в файлы. Таким образом, кто-то может внести изменения там даже с блокнотом (при необходимости). База данных является действительно излишеством, если Вы не хотите свою конфигурацию, находятся в некотором глобальном сервере и всех экземплярах для совместного использования его.