Архитектура web-сервиса
От: Флибустьер Россия http://flibustier87.livejournal.com
Дата: 15.11.07 21:00
Оценка:
Коллеги, рад приветствовать вас на страницах этого форума!

Начинаю разработку нетривиального (на мой взгляд) web-проекта (ближе всего подходит определение "браузерная online-игра", хотя есть ряд существенных отличий от классической реализации). И в связи с этим очень нужен совет гуру и опытных людей по одному ключевому вопросу архитектуры.

Итак, от слов к делу.

Сервис состоит из трех сущностей:

1. Модель (или ядро) сервиса: по "историческим" и на мой взгляд вполне объективным причинам сложилось так, что модель реализована и развивается на языке C++. По сути — это серверная часть проекта. Далее по тексту — model.

2. CGI для взаимодействия с моделью (далее по тексту Mediator) — как раз то решение, на которое я хочу получить объективную критику от уважаемого all . На данный момент предполагаю реализовать этот интерфейс на php.

3. Клиент. Здесь, думаю, все понятно (браузер, ajax, вообщем полный "web2.0")

Взаимодействие сущностей 2 и 3 не вызывает никаких вопросов: здесь все понятно.

Вся суть вопроса — взаимодействие сущностей 1 и 2.

Как Я себе это представляю на данный момент:

Model и Mediator общаются друг с другом через сокеты. Mediator работает так:

0. Создает сессию для общения с клиентом (стандартный механизм php-session)
1. На каждый запрос клиента создает сокет (bottleneck? А не загнется ли сервер? И если загнется, то на скольких "запросах в секунду"?)
2. Преобразовывает запрос в понятный модели (Model) язык
3. Отправляет по сокету запрос в модель
4. Получает от модели ответ
5. Преобразовывает ответ модели в понятный клиенту язык
6. Отправляет клиенту ответ
7. Закрывает сокет

Вот схема примерно такая.

А теперь "+" и "-", которые я вижу в этом решении. Сначала разберемся со знаком "+":

* Mediator и Model общаются через сетевой интерфейс, а это означает, что возможна не только связь по loopback, но и связь с моделью, находящейся на удаленном сервере. Имеем возможность разнести модель по нескольким серверам, что может быть вполне востребовано.

* Вся "рутинная" работа по обработке пользовательских запросов (POST, GET, sessions) возлагается на плечи php: используем для этих целей готовые, проверенные решения.

А теперь "-":

* Единственный минус, который вижу я, это потенциальный bottleneck в Mediator: на каждый запрос клиента создается сокет, и по этому сокету бегают данные. Думаю, что loopback (Model и Mediator — на одном и том же сервере) будет работать быстро. Но есть сомнения. Действительно ли это так? И есть ли еще какие-то "грабли", про которые я забыл?

Вообще, буду признателен за любую конструктивную критику по этой архитектуре.

Всем спасибо за внимание.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.