Что нужно от платформы для облачного PaaS?
Рассмотрим следующую задачу: необходимо выбрать некоторый "Java Enterprise Application Server" (классическое Нечто, предоставляющее поддержку transaction, security, threading - EJB контейнер, Spring, возможно что-то еще) для написания некого PaaS. Пусть это будет некая гипотетическая 1C-в-облаке (или платформа для хостинга интернет-магазинов). Т.е. нечто имеющее свой front-end, кастомизированную бизнесс-логику и базу. Мы ожидает что у нас будет 10.000 корпоративных клиентов. Клиент - это группа пользователей, которые имеют возможность "шарить" между собой данные, под каждого клиента кастомизируется бизнесс-логика. Имеется следующая специфика - у нас 10-100 "бриллиантовых" клиентов - тех которые приносят нам основные доходы, под каждого из них выделяется 10-100 серверов (допустим они генерируют такую нагрузку) + остальные клиенты ничего нам не приносят, пришли в ходе рекламной кампании, завели полноценный экземпляр приложения и нагрузка от них такова, что можем позволить располагать их по 100 на одном сервере. Спектр между генерируемой нагрузкой непрерывно заполнен клиентами, т.е. есть такие клиенты, что их располагаем по 3 на сервере, а есть такие что требуют 1-3 сервера.
Вопрос такой: что нам минимально необходимо требовать еще от платформы?
Я пока вижу два основных требования:
- поддержка multitenancy, т.е. возможность в рамках одного инстанса сервера/контейнера обрабатывать нескольких клиентов. При чем сервер/контейнер должен гарантировать как минимум две вещи: 1. невозможность одному клиенту вмешаться в работу другого (как минимум независимые classloader-ы, как у WAR в рамках сервлет-контейнера), 2. возможность выделять ресурсы контейнера каждому клиенту отдельно (конекшены к базе, пулы потоков, память под кэши). Ну или сверх-легковесный контейнер, такой что возможно запустить 100 инстансов контейнера на одной машине. Это для тех клиентов, которых сотня на машине.
- прозрачная репликация бизнесс-модулей. Имею в виду следующее: любая функциональность, реализованная в виде "модуля" контейнера, получает логическое имя и в случае "выгорания" машины на которой выполнялся вызов функциональности, под это логическое имя автоматически поставляется другой экземпляр модуля на другой машине. Ну и, естественно, автоматическая балансировка нагрузки на модуль путем репликации. Это для высоконагруженных клиентов.
Вопрос к знатокам - это все? Есть что почитать? Как с этим согласуется EJB/SOA/MOM/... ?
P.S. Контекст таков - имеем EJB/Spring/WS-*/JMS спецов, хотим/будем писать/переводить продукт на PaaS.
Рассмотрим следующую задачу: необходимо выбрать некоторый "Java Enterprise Application Server" (классическое Нечто, предоставляющее поддержку transaction, security, threading - EJB контейнер, Spring, возможно что-то еще) для написания некого PaaS. Пусть это будет некая гипотетическая 1C-в-облаке (или платформа для хостинга интернет-магазинов). Т.е. нечто имеющее свой front-end, кастомизированную бизнесс-логику и базу. Мы ожидает что у нас будет 10.000 корпоративных клиентов. Клиент - это группа пользователей, которые имеют возможность "шарить" между собой данные, под каждого клиента кастомизируется бизнесс-логика. Имеется следующая специфика - у нас 10-100 "бриллиантовых" клиентов - тех которые приносят нам основные доходы, под каждого из них выделяется 10-100 серверов (допустим они генерируют такую нагрузку) + остальные клиенты ничего нам не приносят, пришли в ходе рекламной кампании, завели полноценный экземпляр приложения и нагрузка от них такова, что можем позволить располагать их по 100 на одном сервере. Спектр между генерируемой нагрузкой непрерывно заполнен клиентами, т.е. есть такие клиенты, что их располагаем по 3 на сервере, а есть такие что требуют 1-3 сервера.
Вопрос такой: что нам минимально необходимо требовать еще от платформы?
Я пока вижу два основных требования:
- поддержка multitenancy, т.е. возможность в рамках одного инстанса сервера/контейнера обрабатывать нескольких клиентов. При чем сервер/контейнер должен гарантировать как минимум две вещи: 1. невозможность одному клиенту вмешаться в работу другого (как минимум независимые classloader-ы, как у WAR в рамках сервлет-контейнера), 2. возможность выделять ресурсы контейнера каждому клиенту отдельно (конекшены к базе, пулы потоков, память под кэши). Ну или сверх-легковесный контейнер, такой что возможно запустить 100 инстансов контейнера на одной машине. Это для тех клиентов, которых сотня на машине.
- прозрачная репликация бизнесс-модулей. Имею в виду следующее: любая функциональность, реализованная в виде "модуля" контейнера, получает логическое имя и в случае "выгорания" машины на которой выполнялся вызов функциональности, под это логическое имя автоматически поставляется другой экземпляр модуля на другой машине. Ну и, естественно, автоматическая балансировка нагрузки на модуль путем репликации. Это для высоконагруженных клиентов.
Вопрос к знатокам - это все? Есть что почитать? Как с этим согласуется EJB/SOA/MOM/... ?
P.S. Контекст таков - имеем EJB/Spring/WS-*/JMS спецов, хотим/будем писать/переводить продукт на PaaS.
Java совсем неприспособлена для multitenancy. Как ни разделяй classloader'ы, а одно приложение может легко отожрать всю память и свалить весь сервер.
ОтветитьУдалитьПотому проще разделять приложения между разными JVM и не мучатся. Ещё очень рулит JRockit, который сам умеет динамически менять размер хипа.