DevOps: объедините AWS и GC в один веб-сайт

Question

В настоящее время у нас есть более старый веб-сайт, работающий через партнера, который размещает этот сайт на AWS.Мы хотим получить больше контроля над devops и переходим в Google Cloud.Теперь мы создали одностраничное приложение, которое работает в Google Cloud, а остальная часть веб-сайта все еще работает в AWS.Теперь мы застряли на объединении двух.Мы не контролируем разработчиков нашего старого веб-сайта, так как партнер, с которым мы работаем, не является гибким, и только они имеют контроль.

Мы хотим интегрировать новое одностраничное приложение на старом веб-сайте, чтобы оба они работали в одном домене, а поисковые системы могли сканировать все страницы.Это действительно важно.Пользователю не должно быть заметно, что наши два сайта объединены в один.

Идея 1: Идея, которую мы предложили, заключается в том, чтобы настроить новый хостинг на уровне NGINX, чтобы решить, какие URL должныперейти на какой сервер (AWS или GC).Тем не менее, мы думаем, что могут быть некоторые преимущества.Первый - это задержка, поскольку все запросы сначала должны проходить через GC, и большинство из них затем перенаправляются на сервер AWS или в кэш CloudFront.Во-вторых, исходящий трафик GC будет большим, поэтому затраты возрастут.

Идея 2: Настройте наш старый веб-сайт на уровне приложения (PHP), чтобы перенаправить некоторые URL-адреса на новыйодностраничное приложение.В этом случае задержка снова является проблемой, поскольку веб-сайт должен перенаправить определенный трафик на новый сервер GC.В этом случае среда PHP загрузилась так, что это также увеличивает время ожидания для пользователя.

Идея 3: Старый сайт PHP должен загрузить новое одностраничное приложение JS, поэтомупользователь не перенаправлен.Не уверен, насколько технически это осуществимо.

Есть ли даже сценарий, в котором это может сработать, и какие будут недостатки?Какую дополнительную задержку мы можем ожидать, если перенаправим трафик с GC на AWS?Буду очень признателен за любые отзывы, советы или опыт.

Большое спасибо!

Answer 1

Казалось бы, очевидным решением было бы указать домен на CloudFront и позволить CloudFront делать выбор маршрута на основе пути для извлечения контента из CG или AWS на основе шаблонов поведения кэша.В конце концов, CloudFront - это глобально распределенный обратный прокси-сервер, а также кеш, и он не требует, чтобы фактические исходные серверы были в AWS.Вы будете платить за пропускную способность от GC до CloudFront, но только за пропуск кеша.Это похоже на ваш # 1, но ставит прокси в лучшее место ... 100+ разных мест (крайние местоположения CloudFront).У него не должно быть отрицательного влияния на задержку, и, вероятно, наоборот.

Answer 2

Для идей 1 и 2 - не нарушено ли условие, что старая страница и новый SPA должны быть запущены в одном домене?

Во-вторых, насколько я знаю в прошлом, сканер Google рассматривает разные субдомены как отдельные страницы (я не эксперт по SEO), но если это все еще так, весь код SPA должен обслуживаться старым сервером страниц.(однако может существовать некоторая хитрость, чтобы избежать этого)

Так что, возможно, Идея 3 - лучшая.Технически популярные серверы, такие как apache / nginx (где php-код), могут легко обслуживать SPA-код - просто поместите скомпилированный код в соответствующий публичный каталог и сделайте ссылку на этот ресурс в старом PHP-приложении.Вы также можете использовать GIT SUBMODULES, чтобы связать свой SPA-код со своим старым репозиторием приложения.