балансировка нагрузки / перенаправление портов TCP с использованием поддоменов - PullRequest
3 голосов
/ 06 декабря 2011

Я работаю над проектом

1., для которого требуется, чтобы несколько процессов прослушивали запросы на уникальных портах (возможно, на нескольких хостах)

2.Каждый процесс предназначен для обслуживанияуникальный клиент

3. Клиентам следует подключиться к соответствующему серверному процессу, используя client_id.domainname.com в качестве идентификатора / конечной точки.

Пример: запросы поступают на

client_id_1.domainname.com:FIXED_PORT should go to host_1:port_1
client_id_2.domainname.com:FIXED_PORT should go to host_2:port_2    
etc..
[Edited for clarification : the port number with which client will access should be fixed.Only the client_id would change with change in client]

4. [Отредактировано (упустил этот пункт)].Сопоставление должно быть динамическим / изменяемым. Например, если один процесс умирает, должен быть запущен другой, который может быть не на том же порту

Я пробовал следующие подходы (с использованием Java)

1. реализовал tcp сервер и попытался использовать tcp portforwarding, используя http://code.google.com/p/portforward/ и другие подобные вещи, которые я нашел при поиске. Проблема в том, что он использует InetAddress, у которого нет запроса uri (чтобы получить идентификатор клиента с помощьюsubdomain from uri)

2. Реализованы серверные процессы в виде сервлетов во встроенном Jetty. Это нормально только для запросов GET.GET-запросы могут быть перенаправлены на конкретный сервер, используя

httpServletResonse.sendRedirect("http://host_1:port_1")

для POST. У нас есть RequestDispatcher, который в конечном итоге приводит к GET. Кажется, что спецификация HTTP не разрешает перенаправление с POST.

Iтакже нашел это Вызов doPost в другом веб-приложении с Req Dispatcher forward , который предлагает программно запускать запрос POST (я еще не работал над этим подходом)

Я надеюсь, что тамэто решение для этого.Возможно, я сильно упрощен, но я думаю, что это похоже на то, что делает HEROKU. У них также есть бэкэнд-процессы (dynos), которые работают на разных портах (я не уверен в этом). Они сопоставляются с входящими запросами на основе приложения.name.The следующим обсуждается http://www.quora.com/Scalability/How-does-Heroku-work, но на этот вопрос нет ответа.

Я застрял на этом довольно долго. Я был бы очень благодарен за вашу помощь.

1 Ответ

0 голосов
/ 30 декабря 2011

Это невозможно в стеке Heroku, поскольку он поддерживает только стандартные порты HTTP и HTTPS (80 и 443). Когда вы запускаете процесс, порт, к которому подключена служба, определяется инфраструктурой Heroku (см. $ PORT и Procfiles ).

Попытка сделать что-то, что не подходит этой модели, на самом деле не будет работать, пока они не будут поддерживать больше портов.

...