Как масштабировать такую ​​систему?

Question

В настоящее время у меня есть один экземпляр приложения, развернутого в Европе. Он предоставляет некоторые функции через веб-службы (SOAP). Есть много клиентов (несколько тысяч), которые используют его во всем мире (в основном в Северной Америке, Европе и Азии). В текущей настройке некоторые из клиентов должны сделать WS-вызов для приложения, развернутого на другом континенте, что значительно увеличивает время отклика. О характере вызовов - полезная нагрузка небольшая, но вызовы выполняются часто.

Теперь моя идея - просто развернуть больше экземпляров приложения, чтобы в каждой области геоданных было одно. Но тогда возникает проблема загрузки балансировки/загрузки распределенных запросов по разным экземплярам.

Подход №1.

В начале я думал о некоторой балансировке нагрузки на уровне HTTP - иметь один хост, который предоставляет одни и те же методы WS и просто делегирует их другим экземплярам приложений. Но я думаю, что в этом решении я бы ничего не получил с точки зрения времени передачи - весь запрос должен был бы отправиться в одно центральное место, а затем в пункт назначения. Таким образом, маршрут пакетов будет еще длиннее, чем с одним экземпляром.

Подход №2.

Тогда я подумал о балансировке нагрузки на уровне DNS. DNS-поиск должен быть выполнен в любом случае, и если возвращаемый IP-адрес может указывать на закрывающий гео-локальный экземпляр, который бы он был! Но это решение кажется более сложным, потому что мне придется развернуть новую систему DNS (или просто настроить ту, которую использует моя компания, если она поддерживает что-то вроде этого). Также быстрый поиск в google показал в основном коммерческие балансиры нагрузки на основе DNS.

Вопросы Я хотел бы некоторую помощь с ответом являются:

1) Разве я пропустил что-нибудь в любом из перечисленных выше 2 подходов?

2) Есть ли лучший подход к этой проблеме и что это может быть точно?

Answer 1

Давайте держать два понятия индивидуальный:

1) Балансировка нагрузки

Как следует из названия, это распределяет нагрузку между несколькими серверами. Хотя это не влияет на время передачи, это будет, если серверы находятся в разных географических регионах. Но не в хорошем смысле - скажем, вы размещаете сервер 1 в регионе A и сервер 2 в регионе B, а затем балансируете баланс между ними, клиенты любого региона иногда получат обратные поездки в самый отдаленный регион. Например. сбалансированная балансировка нагрузки распределит половину всех вызовов в регион A, а другая половина - в область B, независимо от региона клиента.

Оба ваших подхода - это эффективные сценарии балансировки нагрузки - независимо от того, выполняете ли вы это на уровне DNS или веб-сервера, это не имеет большого значения.

2) Географическая местность

При таком подходе, который вы намекнуть на в вашем подходе # 2, серверы расположены как можно ближе к своим клиентам. Что вам нужно в этом случае - это некоторая форма маршрутизации . Другими словами, либо ваш DNS должен определить, какой клиент находится в каком регионе, так и вернуть соответствующий адрес сервера, или ваш веб-сервер должен сказать клиенту поговорить с другим сервером.

Основываясь на вашем сценарии, я предполагаю, что вы хотите 2).Есть несколько способов для достижения этой цели:

а) использовать поставщик Geo-DNS (поиск гео DNS), в результате чего сервер DNS перенаправляет к ближайшему серверу

б) если гео-DNS не вариант , вы могли бы проверить клиентов на свой основной веб-сервер для каждого первого запроса или, по крайней мере, периодически (например, один раз в день, один раз в час). Затем попросите веб-сервер выяснить регион клиента и попросить его перенаправить на ближайший сервер.

с) используют «гео-известно» передний конец обратного прокси-сервер, такие как Nginx, как описан в этом example