Разверните микро сервисы Springboot на AWS ECS

Question

В настоящее время я занимаюсь разработкой решения для облачного резервного копирования, которое включает в себя до 8 микросервисов, разработанных в Spring-boot, и использующих атлас mon go DB в качестве постоянного слоя.

Микросервисы используют шлюз Netflix ZUUL API и Netflix Eureka в качестве механизма обнаружения услуг. Микросервисы, очевидно, должны общаться друг с другом.

Микросервисы докернизированы. До сих пор я развертывал их в экземпляре EC2, используя docker -компонентный файл, в котором перечислены все службы и средства связи, используя docker networking

. Теперь я пытался использовать ECS для развертывания микросервисов. Я перешел по ссылке ниже для создания кластера et c. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-cli-tutorial-ec2.html

У меня следующие вопросы:

1. Должен ли я создать определение задачи для микросервиса и развернуть его в общем кластере или следует Есть ли одна задача, в которой все микросервисы должны быть коагулированы вместе с использованием файла docker? Как работает обнаружение службы в таком случае?

2. В настоящее время службы общаются друг с другом с помощью симметричного прокси-сервера и сервера eureka. Каков наилучший способ сохранить его как есть или что вы предлагаете? Ранее я использовал Fargate и развернул микросервисы, но обнаружение и регистрация службы не удавались

Пожалуйста, расскажите, как лучше всего разработать развертывание такого приложения в ECS

Answer 1

Файлы компоновки определяют только связь между контейнерами, работающими на одном узле. Обнаружение служб обычно считается желательной функцией распределенных систем, поэтому я предполагаю, что вы используете свой стек на нескольких узлах и каким-то образом распределяете нагрузку между ними, чтобы обеспечить устойчивость и высокую доступность (HA). В противном случае вы просто используете EC2 и устанавливаете docker.

. Вам необходимо запустить ваши контейнеры / службы на узле, чтобы вы могли продолжать использовать файлы Compose для этого. Вы не должны использовать это для определения связи между сервисами, так как вы хотите, чтобы это проходило через ваш service-me sh (services + discovery + proxy == service-me sh). В качестве альтернативы было бы относительно легко заменить Compose набором docker container run операторов в сценарии bash.

Ваш выбор службы 1011 * (возможно) устарел. Я бы посмотрел на консула и консула-коннекта в эти дни, а не на эврика, с доверенным лицом посланника - эта технология через пару поколений от Юрики и намного проще.