У меня есть веб-архитектура, использующая Apache в качестве внешнего интерфейса и Nodejs как серверную часть. Я хочу перенести эту архитектуру на AWS. Node.js будет Elastic Beanstalk, а Apache будет храниться на Amazon S3 (он хранит только статические файлы).
Я использую эти директивы для сопоставления URL-пути / api с серверной частью в Apache:
<Location /api>
ProxyPass http://localhost:8081/api
</Location>
Я хотел бы использовать такой же механизм в AWS. Я выяснил, что Amazon S3 не сможет этого сделать, поскольку это всего лишь служба хранения.
я узнал что Amazon CloudFront можно использовать кратные Amazon CloudFront Истоки, которые могут быть Amazon S3 ведра или Amazon Elastic Load Balancers. Тогда я бы использовал Amazon EC2 разместить серверную часть моего приложения Node.js с Amazon Load Balancer
Окончательная архитектура тогда будет
- Amazon Elastic Load Balancer -> Amazon EC2
/api /
/
-->Amazon CloudFront-<
\
else \
- Amazon S3
Возможен ли такой тип архитектуры? Если да, то это лучший способ создать такую архитектуру в AWS?
Спасибо всем за ответы!
Да ... используйте CloudFront.
Его официальная цель, конечно, заключается в кэшировании CDN, но у него есть встроенная возможность выборочно маршрутизировать запросы в соответствующую исходную систему на основе пути.
Итак, вы должны настроить свой путь по умолчанию как S3, и запросы будут отправляться в вашу корзину. Настройте второй источник, указывающий на Elastic Load Balancer, перед развертыванием Elastic Beanstalk. Установите шаблон пути /api/* для маршрутизации запросов к этому второму источнику.
Поведение кеширования можно отключить, если оно не требуется или не требуется.
Развертывание CloudFront называется «распределением».
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web.html
Это «лучший» подход? Это зависит от вашего опыта и творческих способностей ... но если вы хотите использовать доступные компоненты AWS, тогда да, вероятно, это правильный путь. Это единственный компонент, который обеспечивает практически не требующую обслуживания маршрутизацию запросов по пути на http. (Разумеется, шлюз Amazon API также выполняет маршрутизацию по путям, но он не подходит для этого приложения с S3 в качестве места назначения с «подстановочными знаками».)