Многие из нас уже не раз писали разного рода магазины. Но большие e-commerce проекты в быстро растущей и развивающейся компании разрабатывать приходится нечасто. К таким решениям предъявляются дополнительные требования, такие как конфигурируемость, адаптивность к изменениям, возможности встраивания в другие системы и прочее. Для написания такого решения компания Netcracker использовала Liferay Portal фреймворк. В итоге получили достаточно преимуществ, но и без проблем не обошлось.
Задача
Компания Netcracker, в которой я работаю, занимается разработкой комплексных программных решений для глобальных телеоператоров и операторов связи. Бизнес таких компаний крайне зависит от развития технологий, которые, как вы знаете, очень часто меняются, что сильно сказывается на подходах к решению, казалось бы, стандартных задач в индустрии.
Если попытаться кратко сформулировать задачу, она будет звучать так: необходимо создать корпоративный сайт (далее по тексту — Сайт) одного из крупнейших зарубежных национальных телекоммуникационных операторов связи, покрывающий около 10 млн активных абонентов.
Сайт должен предоставлять возможность просмотра каталога предоставляемых сервисов, информацию о сервисах и их доступности в разных регионах с возможностью тут же приобрести любой из них, а также позволять конфигурировать их в соответствии с описанием. Кроме того, одной из важнейших функций сайта является настроенный личный кабинет пользователя, через который можно управлять приобретенными сервисами, изменять их конфигурацию и без обращения в call-центр делать все, что душе угодно. Также должна быть реализована возможность, позволяющая в будущем легко расширять и модифицировать интерфейс сайта, не внедряясь в детали интеграций, методы получения данных и кодирования.
Все данные о сервисах, их ценах, операциях покупки и изменениях предоставляются модулями продуктовой линейки Netcracker, построенными на основе платформы – Netcracker Framework. Эти данные можно легко получить через REST API, предоставляемый этими модулями.
Остается только получить данные, закешировать все возможное, отобразить на сайте, красиво оформить и запустить сайт
Но так как у нас есть много дополнительных требований, приходится думать и над нефункциональными сценариями использования. Например, заказчику необходимо:
- Регулярно проводить промо-акции, делать скидки, вводить новые сервисы.
- Периодически менять дизайн страниц, элементов пользовательского интерфейса. Например, срочно оформить сайт к Новому году и к Black Friday.
- Уметь отображать на сайте контент, который предоставляют подрядчики.
- Интегрировать корзину в каждую страницу общего портала оператора.
- Иметь возможность без единой строчки кода добавлять новые сервисы существующих типов, а также новые типы сервисов.
Выбор технологии
В качестве платформы для создания решения был выбран Liferay Portal — это портальное решение, поддерживающее спецификацию JSR-168 и JSR-286 (портлетная спецификация), содержащее в себе много разнообразных модулей, которые из коробки позволяют строить расширяемые, управляемые и конфигурируемые приложения. Кроме всего прочего, Liferay Portal (далее Liferay) включает в себя полноценную CMS, интеграцию с социальными сетями, форумы, чаты и прочее. Liferay позволяет строить страницы из кубиков, называемых портлетами, создавать которые могут как сами разработчики решения, так и сторонние компании, используя спецификацию JSR-286.
Liferay является одним из самых популярных бесплатных решений для построения корпоративных порталов и порталов общего доступа. Например, известный многим Java-разработчикам JUG.ru построен именно на нем.
Благодаря архитектуре, предлагаемой Liferay, конфигурация без написания кода будет сводиться к накидыванию на страницы нужных блоков (портлетов), заданию им параметров и прав доступа/ отображения.
Кроме того, Liferay предлагает очень хороший набор модулей Out-of-The-Box типа CMS, интеграцию с социальными сетями, оптимизацию для поисковых машин, интеграцию с системами Single Sign On и сторонними аналитическими сервисами.
Особенности реализации
Обдумывая задачи 1 и 2 (описанные выше), мы поняли, что необходимо дать возможность самому заказчику напрямую влиять на отображение каждого портлета и всего сайта в целом. Кроме того, для разгрузки сервера и улучшения восприятия сайта, хотелось сделать многие операции асинхронными и динамичными. С этой целью в проекте начали использовать темплейтный движок Google Closure Templates.
Этот движок позволяет с легкостью использовать один раз написанный шаблон как на сервере, так и на клиенте. Кроме того, очень качественно продумана локализация, интернационализация, разбивка на подшаблоны и многое другое. Больше всего привлекали лаконичность, уход от логики в шаблонах, избавление от многих типов стандартных ошибок (типа эскейпинга и пр.). Также нравилось, что шаблоны являются компилируемыми сущностями, что позволяет серьезно увеличить производительность как на сервере, так и на клиенте.
Решили сделать так, чтобы заказчик всегда мог подправить шаблон для любого портлета (кубика страницы) на свое усмотрение. Общий же вид портала можно править в шаблоне темы.
Для удобства разработки был написан микрофреймворк, позволяющий писать каждый портлет с использованием Spring MVC и Google Closure Templates в качестве View, а также небольшой JavaScript класс, инкапсулирующий в себе: всю логику асинхронного доступа к портлетам, отложенную их отрисовку по шаблону на клиенте, получение данных, доступа к DOM контейнеру портлета и прочее. Также была добавлена возможность связать JS класс, отвечающий за динамику в данном портлете, и сам портлет.
Благодаря этому разработчик не задумывается о том, что шаблоны должны компилироваться и пишет привычный для него код на Spring, HTML, JavaScript.
Результат
Liferay Portal оказался достаточно стабильным порталом. Порадовала его изначальная направленность на горизонтальное масштабирование, наличие кучи Java API’s и точек расширения, позволяющих поменять чуть ли не все что угодно. Также очень порадовало большое количество конфигурационных свойств, изменение которых позволяло быстро переходить от высоко оптимизированного кода страницы и статики к его девелоперской конфигурации, в которой намного проще отлаживаться. Вообще, создалось впечатление, что платформа создана программистами для программистов!
Google Closure Templates оправдали абсолютно все ожидания. Теперь это мой фаворит среди шаблонизаторов!
Возможность строить страницы для сайта из кубиков, которые напрямую друг с другом не связаны, а общаются только по шине событий, действительно прекрасна. Код получается хорошо структурированным, разбитым на логические части. При этом получаешь дополнительные преимущества: возможность использовать один и тот же портлет с разными внешними видами на разных страницах без единой строчки кода, простоту изменения внешнего вида страницы за счет легкого (drag&drop) перемещения блоков по странице, независимость работы всей страницы от работоспособности конкретного портлета.
Проблемы и решения
Главной проблемой, с которой мы столкнулись и которую до сих пор не решили красиво, стала конфигурация Liferay. Дело в том, что она хранит в себе практически все, что позволяет сайт назвать сайтом: содержимое CMS, настройки каждого портлета, привязанные к странице, темы страниц, лэйауты и многое другое. Поэтому есть серьезная необходимость как-то уметь переносить эту конфигурацию с одного места на другое. Кроме того, необходимо эту конфигурацию хранить и версионировать. Ну и вдобавок при разработке очень бы хотелось иметь возможность мержить изменения конфигурации. Пока мы видим два пути переноса конфигурации в Liferay:
- Первый путь – Staging environment.Суть его в том, что ставятся два инстанса Liferay: один — это мастер изменений, второй – продакшн. На первом вносишь все изменения, убеждаешься, что они работают, и после этого нажимаешь кнопку [Применить]. После этого все изменения чудным образом перемещаются на продакшн сервер. Но, к сожалению, этот подход не удовлетворяет многим требованиям, описанным выше.
- Второй путь – Export/Import – казалось бы, идеальная и правильная штука, но и тут не обошлось без сюрпризов. Экспорт ведется в специальном формате LAR, который является обычным зипником с кучей XML. А проблема в том, что никакой логики в этих XML не наблюдается. Каждый тип конфигурации, каждый тип данных и прочее переводится в XML по-своему! Причем в этом XML такое количество постоянно меняющейся и зависящей от окружения служебной информации, что их мерж оказывается просто невозможным. Так при импорте одинаковой конфигурации с двух разных серверов получается результат различный на 90%.
Проблему конфигурации Liferay решаем пока просто хранением готового LAR-файла. Мержить его невозможно, но можно хотя бы версионировать изменения и откатываться за минуты.
Особенные трудности доставляет то, что в портлетных технологиях считается большим плюсом. Дело в том, что сам Liferay – это отдельное Java веб-приложение. А все портлеты должны быть оформлены как другое отдельное веб-приложение. Это значит, что контексты, класслоадеры, сессии, реквесты и прочее у них разные. Это приводит к куче проблем как при использовании Spring, так и при попытке сделать некоторые базовые вещи, которые можно было бы использовать во всех портлетах. Liferay эту проблему еще и усложняет, добавляя черную магию (постоянную подмену класслоадеров), то копируя, то не копируя параметры реквестов и сессий из приложения в приложение и изменяя код портлетов при деплое.
В общем, Liferay подготовил нам немало приключений, но большинство из них было возможно решить за счет предоставленных точек расширения и большого сообщества вокруг платформы.
Выводы
Решение Liferay еще не вышло в полноценный продакшн, но кое какие-то выводы можно сделать:
- Liferay – мощный инструмент для построения как внутренних, так и массовых порталов.
- Liferay позволил решить поставленные перед нами задачи без дополнительных капитальных вложений в разработку своего «велосипеда».
- Liferay – система, позволяющая делать защищенные, нагруженные и богатые функционалом решения настолько гибко, насколько это возможно.
Несмотря на все это, есть что улучшить. В ближайшее время планируем сделать исследование по следам полученного опыта, чтобы выяснить, есть ли еще какие-нибудь решения того же класса, помогающие решить задачу проще/правильнее. Если есть варианты – прошу в комментарии, будем благодарны.
Всем спасибо за то, что дочитали статью до конца. Надеюсь, она была достаточно интересна.
Комментарии (34)
ihostage
06.06.2016 20:09О какой версии Liferay идет речь? Не было в планах выложить в OpenSource ваш микрофреймворк для написания портлетов с использованием Spring MVC и Closure Templates?
ShimON
07.06.2016 10:36+1В данный момент речь идет о версии 6.2. Но для микрофреймворка это не важно. Статья готовилась почти год назад и сейчас этот микрофреймворк превратился в хорошо заточенный нож с функцией штопора :) Выкладывать в OpenSource пока не планировали, т.к. были уверены, что продукт очень нишевый. Если в этой статье будет проявлен интерес — мы обязательно задумаемся. Обещаю :)
akakunin
06.06.2016 23:18+2Спасибо за статью.
Поправочка — JUG.ru уже «спрыгнул» с Liferay (для нас, как компании которая занимается внедрением Liferay — факт печальный — но увы и ах).
На предмет шаблонизации — в Liferay 6.2 есть штатное средство — Application Display Templates — позволяет задать для портлетов шаблоны (поддерживается velocity & freemaker — это конечно не Google Closure Templates — но зато штатное и из коробки).
Вопрос хранения конфигурации — да, отдельная больная тема — тут вы совершенно правы. Как результат — версионность можно добиться только полным бекапом (и всех вар-ников, и базы, и папки data). Поведение импорта-экспорта (а так же stage-инга — так как он основан на том же импорте-экспорте) как вы правильно заметили совершенно непредсказуемо (особенно если вы используете бесплатную версию CE)
Ну и про «черную магию с подменой класслоадеров» — отдельные аплодисменты :) Только тот, кто до конца раскопал, как работает BeanFactoryLocator — тот поймет. Успокаивает одно — в 7-ой версии с переходом на OSGI это шаманство должно уйти в прошлое.ihostage
06.06.2016 23:37+2Магии с класслоадерами не избежать и в OSGi, в том смысле что он там не один и это тоже нужно понимать. Но всё-таки магия OSGi больше походит на белую, а не на черную, это стоит признать.
ShimON
07.06.2016 10:39Ну все, вы меня расстроили безмерно. Теперь моя надежда на спасение с помощью OSGI растворилась…
foal
07.06.2016 10:52+1Зато OSGI очень упростит развертывание приложений на IBM WebSphere, которая сама OSGI контейнер. В Liferay 6.2 у нас был отдельный EAR на каждую компоненту (~80) и общие библиотеки (shared libraries). Кошмар для отдела развертывания (provisioning). Особенно печалило, что при изменении в общих библиотеках необходим рестарт всей WebSphere. OSGI позволит перейти от классической JEE модели E(W)AR к динамическому графу OSGI приложений.
ShimON
07.06.2016 10:38Шаблоны, о которых вы говорите, не совсем то, что нам нужно. Основной плюс, который мы получили от GCT — это один шаблон для отрисовки на клиенте и сервере. Это реально работает и очень часто помогает.
foal
07.06.2016 10:30С Magnolia CMS последний раз работал лет 5 назад — довольно приятные впечатления. Liferay,… Как бы помягче сказать. Наверное он хорошо подходит для проектов которые интегрируют и отображают информацию из разнообразных источников. Причем информацию слабо связную. За 5 лет работы с Liferay, я таких не видел. Зато хорошо видел сколько проблем доставляет попытка написать на нём приложение, которое требует интеграцию между портлетами. А такое появлялось в любом проекте со временем. Да есть IPC (inter portlet communication). Но попробуйте его использовать в Vaadin портлете, если любой ajax запрос из такого портлета считается resource запросом. Вот и изобретаются костыли, которые пытаются в итоге заставить портлет приложение работать, как сервлет.
Готовые компоненты — круто, но только на презентации, а потом приходят реальные требования и всё пишется с нуля.
Лицензия? Да он стоит как слон. А OSS кончается с первым запросом на поддержку, а их обычно 3-4 в месяц при активной разработке.ShimON
07.06.2016 10:43+1Ну что вам сказать. Я описал эту же боль в статье немного лаконичнее. Сам портлетный подход хорош в теории, но на практике его плюсы никто не использует. Но при этом все выставленные им ограничения приходится обходить постоянно.
Для взаимодействия между портлетами мы используем либо шину событий на клиенте, либо общие синглтоны и сервисный слой. В зависимости от задачи. В 98% случаев хватает. В остальных 2% случаев нужно остановиться и подумать — а все ли я делаю так, не усложняю ли?
Лицензия — вы правы — очень дорогая. Но есть и бесплатная версия полностью функциональная, которую можно допилить напильником под себя и жить до следующего релиза :)foal
07.06.2016 11:07+1Золотые слова. В этом веся разработка на Liferay. И именно это я пытался донести последние 3 года. К сожалению в данную технологию, так много инвестировано, что никто не хочет брать на себя решение о целесообразности её дальнейшего применения.
Да, так и есть. К сожалению после пяти лет остались именно эти 2 процента :) А бизнес про них помнит.
Только не для банка или телекома. А вот когда, им говоришь, что в кластер надо добавить несколько новых узлов или когда бизнес узнаёт, что acceptance environment, должен полностью повторять production, а Liferay им выкатывает счет на пару десятков новых лицензий. Вот тут все и всплывает :)ShimON
07.06.2016 11:48+1Мы-таки научились готовить этого зверя так, чтобы он сильно не мешал, а выполнял строго свои функции CMS )))
Про банки и телекомы не понял. Где тут загвоздка? Мы крупный телеком software провайдер.foal
07.06.2016 12:02Банку необходима железобетонная SLA, которая в OSS отсутствует, как и нормальная поддержка кластера. В связи с этим и в acceptance нельзя применять OSS версию — enterprise портлеты там просто не заведутся. А ещё есть test и development environments. И все они тоже хотят сходную конфигурацию. Хотя узлов в кластерах на них поменьше. Как-то так :)
Хотя по сравнению, сколько банк тратит на лицензии от IBM, Liferay это просто слёзы.
akakunin
07.06.2016 12:04+1По поводу стоимости — смотря с чем сравнивать. Если с WebSphere или SharePoint — то Liferay очень и очень дешев.
Кстати — по моим наблюдениям бесплатность зачастую играет злую шутку с Liferay — люди его берут — раз бесплатный — но не учитывают что это достаточно сложный продукт — и что это на самом деле не что-то готовое — а конструктор — и что потом надо очень серьезно вложиться чтобы из этого конструктора что-то собрать. А особенно учитывая что JEE разработчики ( а тем более с опытом Liferay) стоят намного дороще PHP + какой-нибудь Битрикс — то «бесплатность» оборачивается для клиента высокими костами — и если он не был к этому готов — то проект в итоге вообще не достигает цели а клиент убеждается что «г… ваш этот Liferay».
Про замечания — Liferay не идеален — вопрос в том — для чего его использовать.
Если нужен просто сайт (просто CMS) — ну да, можно использовать Liferay, можно его фичи именно в плане построения сайтов (версионирование и варианты страниц, remote staging, согласование публикации контента, asset publisher и прочее и прочее). Но, уверен что тут есть и другие решения, скорей всего более удобные и более дешевые.
Внутренний портал… ну скажем так — если речь идет о сотнях сотрудников — то 1С Битрикс в руки и вперед.
Реализовать приложение которое решает какую-то конкретную задачу? Зачастую проще сделать сделать самим с нуля (благо framework-ов сейчас много). Не хотите с нуля — берем туже Cuba Platform и вперед — куча всего что есть «из коробки».
Из нашего опыта — Liferay имеет смысл:
1. Когда круг решаемых задач заранее неопределен и может быстро меняться. Тут Liferay реализовал по сути дела модель микросервисов — только на стороне UI — можно реализовать набор инструментов (сервисов — портлетов) и дальше на ходу комбинировать их в том виде в котором это требуется. И тут нет зачастую задач release management-а конфигурации о которых говорилось выше и решения для которых у Liferay нет — по сути дела мы имеет конструктор который уже средствами content manager-а собирается в ту или иную конфигурацию (грубо говоря — если вы делаете просто как-йто сайт — вы же не будете делать релиз для каждой новой новости? это же просто контент — так и тут — страницы и размещение портлетов — это просто «контент»).
2. B2B платформы — в отличие от той же CUBA в Liferay можно завести пользователей разных организаций, каждому пользователю в зависимости от типа организации и его роли настроить свое рабочее простарнство (из тех кубиков-микросервисов-портлетов что есть в заготовке) и дать всем возможность совместно работать.
Опять-таки — если процесс B2B взаимодействия, набор ролей и типов организаций определен заранее — можно написать и что-то свое, с нуля. Но если это заранее не определено (партнерский портал — где сегодня мы обмениваемся одним типом информации — а завтра будет другой) — то каждый раз переколбашивать приложение будет уже накладно.
И тут я альтернатив для Liferay не вижу (если говорить про стек технологий JEE) Но я не являюсь ярым фанатиком — буду благодарен за указание на продукты которые так же могут решать данные задачи.
r0zh0k
07.06.2016 11:40Заказчик действительно конфигурит сам внешний вид и расположение портлетов? Что-то мне подсказывает, что не все так просто :)
Ведь лайфрей был выбран исключительно по этой причине?ShimON
07.06.2016 11:51+1В определенных количествах — да, абсолютно. Есть портлеты-баннеры, текстовики, оформительские, абсолютно самостоятельные. Их и двигают и даже тестируют как больше нравится конечным пользователям. Чем более «динамическая» страница, тем меньше подобных возможностей.
Но мы над стандартными возможностями конфигурации Liferay надстроили свои функции, которые дают еще больше возможностей. Таких как изменение шаблонов портлетов на лету, использование дополнительных параметров объектов, задаваемых через CMS и много другого.
И да, по сути Liferay был выбран изначально за то, что дает неплохой старт не заставляя разрабатывать все это с нуля.
Andrewus
08.06.2016 10:21А можно поподробнее насчет производительности и нагруженности?
Как там с масштабируемостью, кэшированием, раскладкой на несколько серверов приложений и/или баз данных?
И привет, ага;)akakunin
08.06.2016 23:15+1Liferay 6.x поддерживает кластеризацию — проблем нет. Есть возможность выноса контента на CDN (но для нормальной работы требует допила). Небольшим допилом можно реализовать кеширование портлетов для анонимных пользователей.
То есть из коробки поддерживается кластеризация и базовые вещи для поддержки высокой нагрузки — но не всегда оптимально — и там где я писал про «допилы» — это то что мы сами «наработали» за годы внедрения.
А вот с Liferay 7 (новой версией) все немного хуже — из бесплатной версии убрали поддержку кластеризации (тут подробней: http://www.emdev.ru/-/ogranicenia-liferay-7-0-ce
ShimON
09.06.2016 01:34+1Даров :)
Давай начнем с масштабируемости. Сам лайфрей вообще говоря масштабируется слабо. Есть несколько схем, но все упирается в то, что пользователей он хранит в БД, которую надо либо синхронизировать между нодами, либо шарить и кластеризовать в целях HA. Также сам лайфрей умеет кластеризоваться — масштабироваться вертикально.
Мы применяем стандартно другой подход — код разрабатывается общий и раскатывается по нужному количеству серверов без синхронизации. Пользователи хранятся в отдельной idm и там же менеджатся. Таким образом каждая нода независима и горизонтально можно масштабировать до бесконечности.
Кеширование — опять же, сам по себе лайфрей кеширует много чего, но это никак не касается нашей бизнес логики. Мы, конечно же, тоже кешируем. Лайфрей сразу же идет с поддержкой Ehсache, который и использует. Также его используем и мы.
Не очень понял про разные сервера приложений. Сам лайфрей не зависит от реализации контейнера и легко работает как на Webloic так и на JBoss и на Tomcat. От базы данных тоже не зависит — используется стандартный hibernate. Сама по себе раскладка у нас осуществляется специальной внутренней тулой, используемой для раскладки по тестовым, CI, стейджинг и продакшен окружениям.
Производительность… Могу так ответить, в 95% случаев проблемы производительности не на стороне самого портала, а на стороне BE, где крутится вся логика. Со стороны портала занимаемся производительностью оптимизируя размеры страниц, асинхронно подгружая долгие данные, объединяя скрипты, кешируя все и все и пр. стандартные средства. Из цифр могу сказать — 800 req./sec держим лекго.
Надо понимать, что в этой статье я описываю подход к функциональной разработке. Понятно, что разрабатываем мы разные порталы с разными требованиями как к функционалу так и производительности и везде свои решения. Лайфрей нам тут помогает поддерживая из коробки ряд совсем стандартных подходов.Andrewus
09.06.2016 19:39А, если не секрет, сколько и каких сервером обслуживают эти 800 rps?
ShimON
09.06.2016 20:37У нас целый отдел занимающий инфраструктурой, поэтому про внутрянку серверов не могу сказать. На бекенде две ноды аппликейшена, Две ноды БД. На фронтенде 2 ноды аппликейшена с локальной мелкой базой. Также балансеры, файрволы и прочая утварь.
akakunin
13.06.2016 14:37Про масштабируемость: у вас получается все-таки чуть-чуть другой подход чем у нас — у вас liferay — чисто фронт-енд (вся бизнес-логика на back-end серверах) и управлением контента самого портала (страницы, конфигурация портлетов, контент и пр.) как понимаю занимаются сами программисты (если я правильно понял — у вас «версия» — это набор версий портлетов плюс определенная конфигурация- набор страниц, размещения портлетов, контенты) — соотвественно все собирает команда разработки, ставит — и потом это стоит и не меняется. Правильно понял? Тогда да — такой подход «независимых» порталов у вас сработает.
В нашем случае мы даем в первую очередь набор инструментов (портлеты) — проводим первичную установку, настройку — а дальше уже админы и бизнес-пользователи клиента по необходимости управляют всем этим. В этом случае — сам Liferay настраивается в кластер (и тут не со всем понял что имеется в виду под «масштабируется слабо») — и да — все сервера Liferay используют одну базу (дальше если требуется — база кластеризуется своими средствами).
Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы. При старте портал в частности определяет тип сервера, определяет поведение при хот-деплое и прочее. Вот поддержку нюансов для коммерческих серверов из Liferay CE 7 и удалили.
Аналогично с базами данных — да, Liferay использует Hibernate — но не все что поддерживает Hibernate — поддерживается в Liferay — так как для каждой базы есть свои небольшие «допилы». Их тоже удалили.
Хотя это лукавство — код из истории github не удалишь — так что все легко возвращается. Другое дело что развитие этой поддержки будет уже только в платной версии.ShimON
14.06.2016 15:34+1Правильно понял?
Ну да и нет :) Мы вполне позволяем менять настройки и пр. администратору портала со стороны заказчика. Т.е. мы делаем первоначальное внедрение (страницы, конфигурация портлетов, контент и пр.), а потом это все может модифицировать заказчик. И вот тут начинается веселье. Мы делаем какие-то новые фичи, требующие изменение настроек и админы делают изменения в конфиге — как мержить?
Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы.
Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?
и тут не со всем понял что имеется в виду под «масштабируется слабо»
Кластеризация предполагает постоянную синхронизацию по данным. А это сразу же бутылочное горлышко — горизонтально не отмасштабируешься.akakunin
14.06.2016 19:02Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?
Те кто не на томкате, wildfly и глассфише. Считается что если у вас есть деньги на WebSphere/WebLogic — то глупо экономить на «спичках» (лиценизциях на Liferay). Аналогично с базами — если есть деньги на Oracle — то ожидается что и на портал найдутся.
Кластеризация предполагает постоянную синхронизацию по данным. А это сразу же бутылочное горлышко — горизонтально не отмасштабируешься.
Понял, согласен! Как вы и писали выше — Liferay использует ehcache и как только возникает кластер — встает задача синхронизации кешей на нодах. Ну и 100 нод щелчком мыши не запустишь — сразу уткнешься в вопросы синхронизации. В платной версии есть плагин который оптимизирует синхронизацию данных между нодами — но все равно на больших кластерах это будет бутылочное корлышко.
webkumo
Работал над одним проектом (на базе Magnolia CMS), смотрели на LifeRay — так и не стали переходить. В плане кастомизации и внесения своих компонент LifeRay показал себя как-то совсем недружелюбным. Было это года 3 назад. Но у магнолии свои траблы (либо дорогая лицензия, либо ограниченный список версий, где можно не выставлять их плашку + на опенсорсе недоступны некоторые модули, доступные в enterprise версии — тот же мультисайт… на счёт модуля синхронизатора инстансов — не помню… но у нас свой был).
Про вашу проблему — плюс и минус магнолии — она работает поверх JCR, который элементрано экспортируется по заданному пути в виде xml файла, конфигурация и контент разнесены по разным «репозиториям». Возможно вам поможет.
Про вторую проблему (разные инстансы приложения) — именно это нам и помешало перейти на лайфрей. Магнолия модули подхватывает на старте и интегрирует в базовый сервис (с тем же лоадером)…
В общем она не идеал — там тоже своих закидонов хватает, но можете попробовать, вдруг вам подойдёт.
ShimON
Спасибо за развернутый комментарий по делу :)
LifeRay тоже построен над JCR, правда хранит он там только CMS контент. А вот всю конфигурацию — страницы, настройки страниц, портлеты, настройки портлетов и т.д. держит в отдельном месте в базе в проприетарном формате. В этом плане подход Магнолии мне нравится в разы больше и продуманнее.
А почему вы это назвали одновременно и плюсом и минусом? Минусов не вижу.
webkumo
Ровно потому, что при использовании сталкивались с некоторыми проблемами:
— не самая надёжная реализация хранилища (в очень редких случаях, но всё же ловили пару раз — портились данные. Транзакции в использующейся реализации JCR появились относительно недавно и очень многие компоненты о них не знают)
— низкая производительность (любые динамичные и/или большие бинарные данные лучше хранить где-нибудь в другом месте, со страничками справляется приемлемо).
ShimON
Спасибо за опыт. Все-таки в сторону магнолии посмотрим внимательнее.
akakunin
Вы чуть-чуть не правы. JCR — один из возможных способов хранения контента файлов (наряду с собственным файловых хранилищем, базой и Amazon S3). Причем JackRabbit (как реализация JCR) используется только для контентов файлов из портлета Documents & Library. Все остальные Asset-ы (веб-контент и прочее) хранится в базе.
В нашей практике мы JCR не использовали ни разу (если честно — просто не понимаю профита). Из общения с IT-специалистами одной из компаний, где был внедрен BackBase — который тоже базируется на JCR — люди огребли с ним бооооольшие проблемы по производительности.
ShimON
Да, вы абсолютно правы. И эту особенность — хранить все в базе совершенно не реляционной и в стремных форматах — я считаю чуть ли не основным минусом Liferay. В таком случае уж лучше хранить в JCR — оттуда понятно каким образом потом данные мигрировать. Но разработчики Liferay и JCR умудрились бы использовать таким же образом :)
Поделитесь опытом как вы справляетесь с параллельными коммитами и мержами конфигурации?
akakunin
Не совсем так: все данные Liferay хранит в базе в реляционной модели. Вне базы (в папке /data) хранятся только:
* Бинарный контент файлов (и именно его можно перенести в хранилище JCR — что на самом деле лишено смысла)
* Поисковые индексы lucene (в случае если не используется solr).
Так что само хранение данных — оно вполне реляционное.
LAR-файл с «непонятной структурой» о котором вы говорили выше — это только формат переноса данных между серверами.
По поводу мержа конфигурации — решения нет. Обычно как у нас устроено:
1. Разработка портлетов идет в отдельных фиче-бранчах — по мере готовности сливается в мастер — тут ничего, что отличалось бы обычной разработки
2. CI сервер с автоматическим деплоем на dev-среду. Там разработчик, если требуется проводит необходимую конфигурацию (документируя ее) — предварительное тестрование.
3. По мере готовности перенос на qa-env — там настройка уже осуществляется одним человеком (вручную)
4. По мере готовности так же в ручном режиме перенос на прод (опять-таки перенос настройки вручную).
Ну и бекапы.
LAR-файлы, как обсуждали выше — к сожалению не гарантируют 100% перенос — в итоге если их использовать — то после переноса LAR-ником все равно надо пройти и ручками все проверить что правильно перенеслось — проще сразу делать перенос конфигурации руками.
ShimON
Вы немного лукавите, на мой взгляд. Наверняка же заглядывали в «реляционные» таблички лайфрея? И видели огромные XML лежащие в ячейках. Вот это все — примерно 50% полезной информации. И оно в абсолютно не реляционном виде.
Вручную переносить конфигурацию на прод — это же смерти подобно. У нас короткие окна обновлений прода. Если КАЖДЫЙ раз я буду на прод заливать конфигурацию вручную, все пропало. Ну и вопрос мержа конфигурации все равно остается актуальным даже в этом случае. Один проставил одну пропертю в одно значение и записал это в инструкцию, а другой проставил другое значение и тоже записал в инструкцию. Кто, как и когда мержит.
akakunin
XML есть в PortletProperties/PortalProperties. И в контенте (например контент JournalArticle). Так же через XML хранятся локализуемые строки (например заголовок страницы будет идти в XML так как это локализуемый атрибут). В целом все (хотя если мог пропустить что-то важное).
Хотя стоп — Dynamic Data Mapping (кастомные формы и доп поля к веб-контенам и документам) — там тоже все в XML — тут да — проблема — это делает невозможным использовать эти формы для чего-то более-менее серьезного.
Но в целом база Liferay вполне себе реляционная :)