DevOps: объедините AWS и GC в один веб-сайт
В настоящее время у нас есть старый веб-сайт, который работает через партнера, который размещает этот сайт на AWS. Мы хотим больше контролировать девопов и перейти на Google Cloud. Теперь мы создали одностраничное приложение, которое работает в Google Cloud, а остальная часть веб-сайта все еще работает в AWS. Теперь мы застряли на объединении двух. У нас нет контроля над разработчиками нашего старого веб-сайта, так как партнер, с которым мы работаем, не является гибким, и только они имеют контроль.
Мы хотим интегрировать новое одностраничное приложение на старом веб-сайте, чтобы оба запускались в одном домене, и поисковые системы могли сканировать все страницы. Это действительно важно. Пользователю не должно быть заметно, что наши два сайта были объединены в один.
Идея 1:
У нас была идея настроить новый хостинг на уровне NGINX, чтобы решить, какие URL-адреса должны идти на какой сервер (AWS или GC). Тем не менее, мы думаем, что могут быть некоторые преимущества. Первый — это задержка, поскольку все запросы сначала должны проходить через GC, и большинство из них затем перенаправляются на сервер AWS или в кэш CloudFront. Во-вторых, исходящий трафик GC будет большим, поэтому расходы возрастут.
Идея 2:
Настройте наш старый веб-сайт на уровне приложения (PHP), чтобы перенаправить некоторые URL-адреса в новое одностраничное приложение. В этом случае задержка снова является проблемой, поскольку веб-сайт должен перенаправить определенный трафик на новый сервер GC. В этом случае PHP-фреймворк загрузился, так что это также увеличивает время ожидания для пользователя.
Идея 3:
Старый сайт PHP должен загрузить новое одностраничное приложение JS, чтобы пользователь не перенаправлялся. Не уверен, насколько это технически возможно.
Есть ли даже сценарий, в котором это может сработать, и какие будут недостатки? Какую дополнительную задержку мы можем ожидать, если перенаправим трафик с GC на AWS? Любые отзывы, советы или опыт по этому поводу будут высоко оценены.
Спасибо!
Решение
Для Идеи 1 и Идеи 2 — не нарушено ли условие, что старая страница и новый SPA должны быть запущены в одном домене?
Второе — насколько я знаю в прошлом, сканер Google рассматривает разные субдомены как отдельные страницы (я не эксперт по SEO), но если это все еще верно, весь ваш SPA-код должен обслуживаться старым сервером страниц (однако некоторые Хитрость, чтобы избежать этого)
Так что, может быть, идея 3 самая лучшая. Технически популярные серверы, такие как apache / nginx (где php-код), могут легко обслуживать SPA-код — просто поместите скомпилированный код в соответствующий публичный каталог и сделайте ссылку на этот ресурс в старом приложении PHP. Вы также можете использовать GIT SUBMODULES, чтобы связать свой SPA-код со своим старым репозиторием приложения.
Другие решения
Казалось бы, очевидным решением было бы указать домен на CloudFront и позволить CloudFront делать выбор маршрута на основе пути для извлечения контента из CG или AWS на основе шаблонов поведения кэша. В конце концов, CloudFront — это глобально распределенный обратный прокси-сервер, а также кеш, и он не требует, чтобы фактические исходные серверы были в AWS. Вы будете платить за пропускную способность от GC до CloudFront, но только за пропуск кеша. Это похоже на ваш # 1, но ставит прокси в лучшее место … 100+ разных мест (крайние местоположения CloudFront). У него не должно быть отрицательного влияния на задержку, и, вероятно, наоборот.