Доброго времени суток.

Нужен совет по архитектуре веб приложения.

Перед началом разработки пытаюсь определиться с общим видом высоко нагруженного многопользовательского веб приложения, с учетом возможности последующего масштабирования.

Первоначальная схема следующая (для веб приложения)

client -> nginx ->memcached -> apache -> memcached-> pl-proxy -> pgbouncer -> postgresql.

Схема( прошу прощения за кривость, ничего под рукой кроме mspainta нет)

На картинке все узлы которые в одном экземпляре могут дублироваться для отказоустойчивости.
"p/ proxy" на рисунке это криво нарисованный pl/proxy от skype.

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

Под знаком вопрос на рисунке ( по моему мнению ) должно стоять что-то, что балансирует запросы от десктоп-клиента, кеширует ответы, и организует взаимодействие с API которой лежит на бэкенде веб серверов (на рисунке Application API). Не знаю как правильно это организовать.

Подскажите пожалуйста, как правильно мобильный(приложение) и десктоп(приложение) клиенты должны взаимодействовать с архитектурой такого веб приложения.
Критика приветствуется, спасибо.

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

Есть идея воспользоваться следующим способом - транслировать каким-то образом запросы/ответы от и к десктоп клиенту в http запросы с какой-то пометкой что они от десктоп клиента и взаимодействовать через nginx как и само веб приложение ( далее ВП ).
Но я не знаю практикуется ли такой способ - мне он кажется кривым.

На самом деле задача очень распространенная - большинство тех кто сейчас делает многопользовательские ВП либо сразу делают клиента для мобильных/десктоп приложений либо закладывают возможность на будущее. Но какой-то внятной статьи на эту тему мне найти не удалось( пока ).
Да, кстати - многие популярные веб приложения открывают свой API для всех остальных в свободное пользование. Так как, по моему представлению, схема ВП у них похожа на ту что я нарисовал , то это означает что у них уже реализована балансировка запросов к их API(распределение нагрузки запросов по серверам с API) и кеширование ответов. Это мне и нужно - вопрос только в том какие готовые(по возможности) технологии нужно использовать.

Хотя больше интересны балансировка т.к кеширование уже есть позади серверов с api

Спасибо за комментарии



KachalovНепонятно что такое в этой схеме "Apache"? Apache Httpd (зачем он нужен при наличии в качестве фронтэнда nginx)? Apache Tomcat (при таком размахе почему не полноценный JavaEE-сервер)?
Apache имеется в виду полноценный сервер приложений.

KachalovПолноценный JavaEE сервер приложений уже имеет встроенный функционал по кэшированию объектов и кластеризации приложения.
Вы правы. Я выбрал такую схему просто потому что она является на данный момент распространенной практикой в промышленных приложениях.

KachalovНе web-клиенты на Java взаимодействуют с серверной частью через RMI-IIOP, или, если клиент написан не на Java, Corba/IIOP, SOAP.
Согласен, но как оранизовать связку клиент - несколько серверов с api? Его запрос 1 а серверов приложений много. На какой из серверов клиенту подключаться? Кто-то дожен так-же как и в веб приложении заниматься распределением запросов от клиента. В веб приложении эту функцию как раз выполняет nginx.

Я не ответил про nginx
KachalovНепонятно что такое в этой схеме "Apache"? Apache Httpd (зачем он нужен при наличии в качестве фронтэнда nginx)? Apache Tomcat (при таком размахе почему не полноценный JavaEE-сервер)?

Nginx в моей схеме выполняет роль балансировщика (распределителя)запросов к серверам apache. Это его основная функция в данной схеме. Также он может хранить и отдавать часть статического контента. То есть nginx 1 а серверов приложений много. Вроде является распространенной практикой.

DPH3Хм.
А какая нагрузка будет и какой профиль и какие задачи?
Я бы отнес это к многопользовательской интеллектуальной игре (без флеша, и графики, легкий javascript) где пользователи делятся на группы и в этой группе выполняют различные действия.
Нагрузка не известна, но в группе может быть не ограниченное количество одновременно выполняющих простые действия пользователей. Причем результаты действий других пользователей видны если не сразу то с небольшой задержкой. Масштабирование заложить хотелось бы сразу таким образом, чтобы масштабировать горизонтально можно было бы просто с помощью добавления параметров с новыми серверами в настройках узлов .

DPH3Вообще, если разделить уровень бизнес-логики и уровень презентации, то все станет несколько проще.
Согласен. Можно вообще разнести презентацию и api по разным серверам.

Для простоты представим что на рисунке теперь не 3 сервера с презентацией и api а 6 серверов -
3 с презентацией и 3 с api. Теперь точка входа для взаимодействия для всех типов клиентских приложений а так же для уровня презентации это сервера с api.

DPH3Т.е. есть сервер приложений, сидящий за тем же nginx, а перед ним - или JSPшки (или, лучше, какой-нибудь другой шаблонизатор) или десктопы или что-то еще.
Описал как раз такой вариант.
Но тогда возникает тот-же вопрос который я все время задаю в своих постах выше:
Какой компонент будет заниматься балансировкой запросов от клиентов и равномерно распределять по серверам с api?
Например мой мобильный клиент должен обратиться к API бизнес логики. К какому серверу с API ему коннектиться? Позже, допустим, будет не 3 а 10 серверов с API.
Как организовать распределение таких вот клиентских запросов к серверам с api? Как быть если клиент взамиодействует с api по rmi? Насколько я помню rmi клиенту надо явно указать на какой сервер коннектиться. А мне нужно к кластеру.

Можно , конечно, самому написать балансировщик с одной точкой входа но скорее всего я просто плохо разбираюсь в теме и есть стандартные решения которые нужно использовать.

DPH3И, да, memcached - это средство для кэширования, что оно делает перед applayer?
Да, я на рисунку просто пытался показать что кешировать можно не только страницы но и обьекты, То есть и элементы презентации и элементы логики. memcached один.

DPH3Ну и, конечно, полноценные J2EE сервера для полноценных приложений использовать не стоит.tomcat презентация + nginx бизнес логика?

DPH3И, да, почему PostgresSQL? Или это наиболее знакомая БД?
Из открытых бд на мой взгляд наиболее перспективная. Выбор был между mysql и postgre.

DPH3А вообще балансировку нагрузки можно делать разными способами - nginx, cisco, балансером на FreeBSD etc - это, в общем, уже что больше знакомо сисадмину :)
Чем делать балансировку rmi соединений если клиент взаимодействует с его помошью?
Cпасибо.

DPH3,

Спасибо за полезные комментарии.

Опс. J2ME на мобильниках еще кое-как живет, на смартфонах уже, фактически, умерла.
Увы, java - в первую очередь серверное решение. Ну, еще Android, конечно (хотя там та еще Java).

Я как-раз присматриваюсь к Android, а там только java и используется.

DPH3,

Тоже склоняюсь к http+json. Посмотрел что foursquare перешел на это в своем api.
Friendfeed тоже смотрю построил на этом свой API.

автор Сейчас проще и правильнее использовать http(s) в качестве транспорта, с REST+JSON поверх.

Итак, как я понял, итог такой:

Я использую единый API для всех клиентов - в моем случае это сервера с сервлетами стоящие за nginx. Запросы к API приходят на nginx который и занимается балансировкой всех запросов от всех клиентов на сервера с API.

Клиенты: браузер, iphone, android - ну может еще десктоп.

Все клиенты общаются с единым сервером с API через nginx.

Браузер:
В случае с клиентом-браузером перед API стоит еще слой который готовит html для браузера который тоже как и все остальные клиенты использует API для генерации html.
В html который отправляется клиенту будет также java script который уже в браузере клиента через ajax который по мере надобности будет обращаться к тому же API и брать json обьекты.

Iphone и Android:
Мобильные клиенты используют библиотеки для работы с json и http и взаимодействуют напрямую с API из мобильного приложения.

Мобильные приложения должны, однако, обновляться через RPC ( видимо).

Все.

Если я где-то ошибся, пожалуйста, поправте.

DPH3 ,

Спасибо за ответ.

А тут, обычно, или-или.
Или мы генерим html на сервере - и тогда много js на клиенте нам и не очень нужно.
Или генерим полностью на сервере - и тогда нам и шаблонизатор html не нужен вообще.
Решение - зависит от задач.
Ну, можно и смешивать, конечно, но аккуратно.

Честно говоря, до конца фразу не понял: .Или мы генерим html на сервере.. и Или генерим полностью на сервере... - не понял в чем разница тут - генерим в обоих случаях на сервере, но в одном случае не полностью?

Я правильно понимаю, что в любом случае слой презентации, который занимается генерацией html (сервер на котором мы полностью генерим html) является как бы клиентом по отношению к этому единому api, и делает к этому серверу с api http запросты - точно так же как это делают и мобильные клиенты, результаты запросов использует для генерации html и результат отправляет в браузер?
То есть моб клиенты коннектятся непосредственно к серверу с api(json на http), а браузер по http коннектиться к серверу со слоем презентации, а слой презентации далает запросы на сервер с api (json на http).
Иными словами связка в случае с web приложением такая : браузер --http-> сервер презетнации --http+json--> сервер с api ?