День девятьсот двадцать второй. #DesignPatterns #Microservices
Паттерны в Микросервисах
9. Внешняя конфигурация
Каждое бизнес-приложение имеет множество параметров конфигурации для различной инфраструктуры (например, база данных, сеть, адреса подключенных служб, учетные данные, путь к сертификату). Кроме того, в корпоративной среде приложение обычно развёртывается в различных средах выполнения (локальной, тестовой, производственной). Один из способов добиться этого - использовать конфигурацию внутри каждого приложения в каждом случае, что является фатальной плохой практикой. Это может привести к серьёзным угрозам безопасности, поскольку производственные учётные данные могут быть легко скомпрометированы. Кроме того, при любом изменении параметра конфигурации необходимо пересобрать приложение. Это ещё более важно в микросервисной архитектуре, поскольку у нас потенциально есть сотни сервисов.

Лучшим подходом является экстернализация всех конфигураций. В результате процесс сборки отделён от среды выполнения. Кроме того, это сводит к минимуму риск безопасности, поскольку файл конфигурации используется только во время выполнения или через переменные среды.

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

Минусы
- Нам нужно выбрать фреймворк, поддерживающий внешнюю конфигурацию.

Когда использовать
- Любое серьезное производственное приложение должно использовать внешнюю конфигурацию.

Когда не использовать
- В тестовых приложениях.

Включение технологий
Практически все современные фреймворки корпоративного уровня поддерживают внешнюю конфигурацию.

Подробнее
- Microservices Pattern: Externalized configuration
- Build Once, Run Anywhere: Externalize Your Configuration

Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41