Как обрабатывать конфигурацию, когда сам сервер конфигурации Spring Boot не работает?
Я новичок в конфигурационном сервере весеннего облака. Рассмотрим сценарий, в котором у нас есть 10 конфигураций микросервиса Spring Boot, извлекающих конфигурации из Spring Boot Cloud Config. Мне было интересно, как будут работать 10 микросервисов весенней загрузки, когда сама конфигурация Spring Boot Cloud не работает?
Может ли кто-нибудь ответить на следующие вопросы:
- Если сервер конфигурации не работает, будет ли время простоя для всех подключенных к нему микросервисов?
- Допустим, у нас есть файл конфигурации application.properties в GitHub, а конфигурация загрузки Spring ссылается на файл application.properties в GitHub. Что если имя пользователя и пароль для доступа к самому файлу application.properties изменятся?
- Что касается аварийного восстановления, нужна ли нам какая-либо резервная копия сервера конфигурации? Если да, то как мы можем добиться того же?
Ответы 1
Если сервер конфигурации не работает, будет ли время простоя для всех подключенных к нему микросервисов?
В реальном приложении будет несколько экземпляров вашего сервера конфигурации, развернутых в нескольких зонах доступности, с балансировщиком нагрузки или шлюзом API, или даже вы можете зарегистрировать несколько экземпляров на сервере eureka, чтобы не было единой точки отказа. Итак, как будет выглядеть конфигурация, если экземпляр 1 находится в us-east-1 экземпляр 2 в us-west-2, поэтому даже если одна зона доступности не работает, это не повлияет на ваши услуги.
Что касается GitHub или внешнего репозитория, вы можете настроить сервер конфигурации для чтения свойств изначально, но я не буду предлагать это !!
Допустим, у нас есть файл конфигурации application.properties в GitHub, а конфигурация загрузки Spring ссылается на файл application.properties в GitHub. Что если имя пользователя и пароль для доступа к самому файлу application.properties изменятся?
Прежде всего, вы не должны фиксировать пароль в Github для общедоступного репо, во-вторых, пароль должен динамически извлекаться из Idvault, или AWS secret Manager, или других служб, в зависимости от того, что вы предпочитаете. Так что даже если вы смените пароль, это не повлияет на какие-либо службы.
Что касается аварийного восстановления, нужна ли нам какая-либо резервная копия сервера конфигурации? Если да, то как мы можем добиться того же?
Сервер конфигурации просто считывает свойства/конфигурацию из репозитория, который вы предоставляете, поэтому для вас важен репозиторий, в котором размещен ваш код. Github может позаботиться об этом за вас!
Да, вы можете, но ключ, используемый конечными точками /encrypt/decrypt, должен храниться где-то в безопасном месте.
Большое спасибо Джей за ваш ответ. У меня есть один вопрос. Могу ли я использовать конечные точки /encrypt и decrypt, предоставленные сервером конфигурации, вместо использования AWS Secret Manager?