У меня сложная архитектура, включающая 5 разных приложений:
Все эти приложения фактически размещены на одном выделенном сервере и работают в Node.js.
Я хочу внедрить свою архитектуру в облако Amazon AWS, но все еще сомневаюсь в том, какую новую архитектуру я хочу настроить.
Нужно ли мне разделять свои приложения и запускать один экземпляр EC2 для каждого приложения (и, возможно, 1 балансировщик нагрузки для каждой группы приложений), или я могу запускать все свои приложения в одном экземпляре и использовать один балансировщик нагрузки поверх него.
Хотел бы я быть более точным, но я не привык к технике масштабирования.
Хьюго.
Предполагая, что вас не волнует высокая доступность. Если один экземпляр может справиться с нагрузкой, поместите их всех в один экземпляр. Тем не менее, я бы поставил некоторый мониторинг этих конкретных сервисов, чтобы вы знали, когда им пора обзавестись собственным хостом (ами). Вы можете обнаружить, что для разных сервисов потребуется масштабирование с разной скоростью. Единственный хороший способ следить за этим - использовать хороший мониторинг и инструменты.
Позже вы сможете избавить себя от головной боли, введя некоторую абстракцию между сервисами. Например, убедитесь, что когда одна служба вызывает API, она вызывает его по какому-либо имени (DNS отлично подходит для этого). Что-то вроде api.myapp.com подойдет. Возможно, изначально все имена указывают на один и тот же хост. Но в будущем, когда вам потребуется масштабирование, вы можете указать это имя для Elastic Load Balancer с кучей экземпляров за ним, и ничего в вашем приложении не нужно будет изменять, чтобы взаимодействовать с новыми экземплярами.
Если вас интересует высокая доступность, вам понадобится более одного ящика. полная остановка.
Учитывая информацию, которую вы предоставили выше, я бы рекомендовал разделить или абстрагировать сервисы друг от друга, если вы собираетесь хранить их в одном ящике. Как системный администратор, я не хочу рекомендовать полагаться на единый блок для всей вашей архитектуры, но если вас не волнует высокая доступность и у вас есть подходящее решение для резервного копирования любых данных, которые вы хотите сохранить в случае сбой, тогда продолжайте (даже если вы распределяете свою архитектуру по одному ящику на службу, вы все равно должны делать резервные копии своих данных и конфигураций!)
Однако, если вы хотите распределить свои службы по нескольким экземплярам EC2 - что впоследствии поможет с масштабируемостью - не забудьте использовать DNS-имена или эластичные IP-адреса EC2, так как внутренние IP-адреса ящиков могут измениться. Поскольку трафик между внутренними IP-адресами дешевле, вы можете исследовать использование этих и динамического DNS, если вы собираетесь иметь большой межкомпонентный трафик.
Помните также, что если на каком-то этапе вам потребуется масштабирование за пределы одного экземпляра для каждой службы, в вашем проекте следует учитывать возможное будущее использование эластичных балансировщиков нагрузки и автоматического масштабирования AWS.
Если вам нужно, чтобы ваш генеральный директор мог быстро развернуть новый стек в случае возникновения проблем, я бы рекомендовал изучить сервис AWS Cloud Formation. Это позволяет использовать файлы конфигурации JSON для определения стека, состоящего из нескольких ресурсов AWS, а также запускать и прекращать работу вашего сервиса с минимальным взаимодействием.