Как стать автором
Обновить

Комментарии 34

Работал над одним проектом (на базе Magnolia CMS), смотрели на LifeRay — так и не стали переходить. В плане кастомизации и внесения своих компонент LifeRay показал себя как-то совсем недружелюбным. Было это года 3 назад. Но у магнолии свои траблы (либо дорогая лицензия, либо ограниченный список версий, где можно не выставлять их плашку + на опенсорсе недоступны некоторые модули, доступные в enterprise версии — тот же мультисайт… на счёт модуля синхронизатора инстансов — не помню… но у нас свой был).

Про вашу проблему — плюс и минус магнолии — она работает поверх JCR, который элементрано экспортируется по заданному пути в виде xml файла, конфигурация и контент разнесены по разным «репозиториям». Возможно вам поможет.
Про вторую проблему (разные инстансы приложения) — именно это нам и помешало перейти на лайфрей. Магнолия модули подхватывает на старте и интегрирует в базовый сервис (с тем же лоадером)…

В общем она не идеал — там тоже своих закидонов хватает, но можете попробовать, вдруг вам подойдёт.
Спасибо за развернутый комментарий по делу :)

LifeRay тоже построен над JCR, правда хранит он там только CMS контент. А вот всю конфигурацию — страницы, настройки страниц, портлеты, настройки портлетов и т.д. держит в отдельном месте в базе в проприетарном формате. В этом плане подход Магнолии мне нравится в разы больше и продуманнее.
А почему вы это назвали одновременно и плюсом и минусом? Минусов не вижу.
Ровно потому, что при использовании сталкивались с некоторыми проблемами:
— не самая надёжная реализация хранилища (в очень редких случаях, но всё же ловили пару раз — портились данные. Транзакции в использующейся реализации JCR появились относительно недавно и очень многие компоненты о них не знают)
— низкая производительность (любые динамичные и/или большие бинарные данные лучше хранить где-нибудь в другом месте, со страничками справляется приемлемо).
Спасибо за опыт. Все-таки в сторону магнолии посмотрим внимательнее.
Вы чуть-чуть не правы. JCR — один из возможных способов хранения контента файлов (наряду с собственным файловых хранилищем, базой и Amazon S3). Причем JackRabbit (как реализация JCR) используется только для контентов файлов из портлета Documents & Library. Все остальные Asset-ы (веб-контент и прочее) хранится в базе.

В нашей практике мы JCR не использовали ни разу (если честно — просто не понимаю профита). Из общения с IT-специалистами одной из компаний, где был внедрен BackBase — который тоже базируется на JCR — люди огребли с ним бооооольшие проблемы по производительности.
Да, вы абсолютно правы. И эту особенность — хранить все в базе совершенно не реляционной и в стремных форматах — я считаю чуть ли не основным минусом Liferay. В таком случае уж лучше хранить в JCR — оттуда понятно каким образом потом данные мигрировать. Но разработчики Liferay и JCR умудрились бы использовать таким же образом :)

Поделитесь опытом как вы справляетесь с параллельными коммитами и мержами конфигурации?
Не совсем так: все данные Liferay хранит в базе в реляционной модели. Вне базы (в папке /data) хранятся только:
* Бинарный контент файлов (и именно его можно перенести в хранилище JCR — что на самом деле лишено смысла)
* Поисковые индексы lucene (в случае если не используется solr).

Так что само хранение данных — оно вполне реляционное.
LAR-файл с «непонятной структурой» о котором вы говорили выше — это только формат переноса данных между серверами.

По поводу мержа конфигурации — решения нет. Обычно как у нас устроено:
1. Разработка портлетов идет в отдельных фиче-бранчах — по мере готовности сливается в мастер — тут ничего, что отличалось бы обычной разработки
2. CI сервер с автоматическим деплоем на dev-среду. Там разработчик, если требуется проводит необходимую конфигурацию (документируя ее) — предварительное тестрование.
3. По мере готовности перенос на qa-env — там настройка уже осуществляется одним человеком (вручную)
4. По мере готовности так же в ручном режиме перенос на прод (опять-таки перенос настройки вручную).

Ну и бекапы.
LAR-файлы, как обсуждали выше — к сожалению не гарантируют 100% перенос — в итоге если их использовать — то после переноса LAR-ником все равно надо пройти и ручками все проверить что правильно перенеслось — проще сразу делать перенос конфигурации руками.
Вы немного лукавите, на мой взгляд. Наверняка же заглядывали в «реляционные» таблички лайфрея? И видели огромные XML лежащие в ячейках. Вот это все — примерно 50% полезной информации. И оно в абсолютно не реляционном виде.

Вручную переносить конфигурацию на прод — это же смерти подобно. У нас короткие окна обновлений прода. Если КАЖДЫЙ раз я буду на прод заливать конфигурацию вручную, все пропало. Ну и вопрос мержа конфигурации все равно остается актуальным даже в этом случае. Один проставил одну пропертю в одно значение и записал это в инструкцию, а другой проставил другое значение и тоже записал в инструкцию. Кто, как и когда мержит.
XML есть в PortletProperties/PortalProperties. И в контенте (например контент JournalArticle). Так же через XML хранятся локализуемые строки (например заголовок страницы будет идти в XML так как это локализуемый атрибут). В целом все (хотя если мог пропустить что-то важное).

Хотя стоп — Dynamic Data Mapping (кастомные формы и доп поля к веб-контенам и документам) — там тоже все в XML — тут да — проблема — это делает невозможным использовать эти формы для чего-то более-менее серьезного.

Но в целом база Liferay вполне себе реляционная :)

О какой версии Liferay идет речь? Не было в планах выложить в OpenSource ваш микрофреймворк для написания портлетов с использованием Spring MVC и Closure Templates?

В данный момент речь идет о версии 6.2. Но для микрофреймворка это не важно. Статья готовилась почти год назад и сейчас этот микрофреймворк превратился в хорошо заточенный нож с функцией штопора :) Выкладывать в OpenSource пока не планировали, т.к. были уверены, что продукт очень нишевый. Если в этой статье будет проявлен интерес — мы обязательно задумаемся. Обещаю :)
Спасибо за статью.

Поправочка — JUG.ru уже «спрыгнул» с Liferay (для нас, как компании которая занимается внедрением Liferay — факт печальный — но увы и ах).

На предмет шаблонизации — в Liferay 6.2 есть штатное средство — Application Display Templates — позволяет задать для портлетов шаблоны (поддерживается velocity & freemaker — это конечно не Google Closure Templates — но зато штатное и из коробки).

Вопрос хранения конфигурации — да, отдельная больная тема — тут вы совершенно правы. Как результат — версионность можно добиться только полным бекапом (и всех вар-ников, и базы, и папки data). Поведение импорта-экспорта (а так же stage-инга — так как он основан на том же импорте-экспорте) как вы правильно заметили совершенно непредсказуемо (особенно если вы используете бесплатную версию CE)

Ну и про «черную магию с подменой класслоадеров» — отдельные аплодисменты :) Только тот, кто до конца раскопал, как работает BeanFactoryLocator — тот поймет. Успокаивает одно — в 7-ой версии с переходом на OSGI это шаманство должно уйти в прошлое.

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

Ну все, вы меня расстроили безмерно. Теперь моя надежда на спасение с помощью OSGI растворилась…
Зато OSGI очень упростит развертывание приложений на IBM WebSphere, которая сама OSGI контейнер. В Liferay 6.2 у нас был отдельный EAR на каждую компоненту (~80) и общие библиотеки (shared libraries). Кошмар для отдела развертывания (provisioning). Особенно печалило, что при изменении в общих библиотеках необходим рестарт всей WebSphere. OSGI позволит перейти от классической JEE модели E(W)AR к динамическому графу OSGI приложений.

Внушает. Спасибо.
Шаблоны, о которых вы говорите, не совсем то, что нам нужно. Основной плюс, который мы получили от GCT — это один шаблон для отрисовки на клиенте и сервере. Это реально работает и очень часто помогает.
С Magnolia CMS последний раз работал лет 5 назад — довольно приятные впечатления. Liferay,… Как бы помягче сказать. Наверное он хорошо подходит для проектов которые интегрируют и отображают информацию из разнообразных источников. Причем информацию слабо связную. За 5 лет работы с Liferay, я таких не видел. Зато хорошо видел сколько проблем доставляет попытка написать на нём приложение, которое требует интеграцию между портлетами. А такое появлялось в любом проекте со временем. Да есть IPC (inter portlet communication). Но попробуйте его использовать в Vaadin портлете, если любой ajax запрос из такого портлета считается resource запросом. Вот и изобретаются костыли, которые пытаются в итоге заставить портлет приложение работать, как сервлет.

Готовые компоненты — круто, но только на презентации, а потом приходят реальные требования и всё пишется с нуля.

Лицензия? Да он стоит как слон. А OSS кончается с первым запросом на поддержку, а их обычно 3-4 в месяц при активной разработке.
Ну что вам сказать. Я описал эту же боль в статье немного лаконичнее. Сам портлетный подход хорош в теории, но на практике его плюсы никто не использует. Но при этом все выставленные им ограничения приходится обходить постоянно.

Для взаимодействия между портлетами мы используем либо шину событий на клиенте, либо общие синглтоны и сервисный слой. В зависимости от задачи. В 98% случаев хватает. В остальных 2% случаев нужно остановиться и подумать — а все ли я делаю так, не усложняю ли?

Лицензия — вы правы — очень дорогая. Но есть и бесплатная версия полностью функциональная, которую можно допилить напильником под себя и жить до следующего релиза :)
Золотые слова. В этом веся разработка на Liferay. И именно это я пытался донести последние 3 года. К сожалению в данную технологию, так много инвестировано, что никто не хочет брать на себя решение о целесообразности её дальнейшего применения.

Да, так и есть. К сожалению после пяти лет остались именно эти 2 процента :) А бизнес про них помнит.

Только не для банка или телекома. А вот когда, им говоришь, что в кластер надо добавить несколько новых узлов или когда бизнес узнаёт, что acceptance environment, должен полностью повторять production, а Liferay им выкатывает счет на пару десятков новых лицензий. Вот тут все и всплывает :)
Мы-таки научились готовить этого зверя так, чтобы он сильно не мешал, а выполнял строго свои функции CMS )))

Про банки и телекомы не понял. Где тут загвоздка? Мы крупный телеком software провайдер.
Банку необходима железобетонная SLA, которая в OSS отсутствует, как и нормальная поддержка кластера. В связи с этим и в acceptance нельзя применять OSS версию — enterprise портлеты там просто не заведутся. А ещё есть test и development environments. И все они тоже хотят сходную конфигурацию. Хотя узлов в кластерах на них поменьше. Как-то так :)

Хотя по сравнению, сколько банк тратит на лицензии от IBM, Liferay это просто слёзы.
По поводу стоимости — смотря с чем сравнивать. Если с 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) Но я не являюсь ярым фанатиком — буду благодарен за указание на продукты которые так же могут решать данные задачи.
Заказчик действительно конфигурит сам внешний вид и расположение портлетов? Что-то мне подсказывает, что не все так просто :)
Ведь лайфрей был выбран исключительно по этой причине?
В определенных количествах — да, абсолютно. Есть портлеты-баннеры, текстовики, оформительские, абсолютно самостоятельные. Их и двигают и даже тестируют как больше нравится конечным пользователям. Чем более «динамическая» страница, тем меньше подобных возможностей.

Но мы над стандартными возможностями конфигурации Liferay надстроили свои функции, которые дают еще больше возможностей. Таких как изменение шаблонов портлетов на лету, использование дополнительных параметров объектов, задаваемых через CMS и много другого.

И да, по сути Liferay был выбран изначально за то, что дает неплохой старт не заставляя разрабатывать все это с нуля.
А можно поподробнее насчет производительности и нагруженности?
Как там с масштабируемостью, кэшированием, раскладкой на несколько серверов приложений и/или баз данных?

И привет, ага;)
Liferay 6.x поддерживает кластеризацию — проблем нет. Есть возможность выноса контента на CDN (но для нормальной работы требует допила). Небольшим допилом можно реализовать кеширование портлетов для анонимных пользователей.
То есть из коробки поддерживается кластеризация и базовые вещи для поддержки высокой нагрузки — но не всегда оптимально — и там где я писал про «допилы» — это то что мы сами «наработали» за годы внедрения.

А вот с Liferay 7 (новой версией) все немного хуже — из бесплатной версии убрали поддержку кластеризации (тут подробней: http://www.emdev.ru/-/ogranicenia-liferay-7-0-ce
Даров :)

Давай начнем с масштабируемости. Сам лайфрей вообще говоря масштабируется слабо. Есть несколько схем, но все упирается в то, что пользователей он хранит в БД, которую надо либо синхронизировать между нодами, либо шарить и кластеризовать в целях HA. Также сам лайфрей умеет кластеризоваться — масштабироваться вертикально.
Мы применяем стандартно другой подход — код разрабатывается общий и раскатывается по нужному количеству серверов без синхронизации. Пользователи хранятся в отдельной idm и там же менеджатся. Таким образом каждая нода независима и горизонтально можно масштабировать до бесконечности.
Кеширование — опять же, сам по себе лайфрей кеширует много чего, но это никак не касается нашей бизнес логики. Мы, конечно же, тоже кешируем. Лайфрей сразу же идет с поддержкой Ehсache, который и использует. Также его используем и мы.
Не очень понял про разные сервера приложений. Сам лайфрей не зависит от реализации контейнера и легко работает как на Webloic так и на JBoss и на Tomcat. От базы данных тоже не зависит — используется стандартный hibernate. Сама по себе раскладка у нас осуществляется специальной внутренней тулой, используемой для раскладки по тестовым, CI, стейджинг и продакшен окружениям.

Производительность… Могу так ответить, в 95% случаев проблемы производительности не на стороне самого портала, а на стороне BE, где крутится вся логика. Со стороны портала занимаемся производительностью оптимизируя размеры страниц, асинхронно подгружая долгие данные, объединяя скрипты, кешируя все и все и пр. стандартные средства. Из цифр могу сказать — 800 req./sec держим лекго.

Надо понимать, что в этой статье я описываю подход к функциональной разработке. Понятно, что разрабатываем мы разные порталы с разными требованиями как к функционалу так и производительности и везде свои решения. Лайфрей нам тут помогает поддерживая из коробки ряд совсем стандартных подходов.
А, если не секрет, сколько и каких сервером обслуживают эти 800 rps?
У нас целый отдел занимающий инфраструктурой, поэтому про внутрянку серверов не могу сказать. На бекенде две ноды аппликейшена, Две ноды БД. На фронтенде 2 ноды аппликейшена с локальной мелкой базой. Также балансеры, файрволы и прочая утварь.
Про масштабируемость: у вас получается все-таки чуть-чуть другой подход чем у нас — у вас liferay — чисто фронт-енд (вся бизнес-логика на back-end серверах) и управлением контента самого портала (страницы, конфигурация портлетов, контент и пр.) как понимаю занимаются сами программисты (если я правильно понял — у вас «версия» — это набор версий портлетов плюс определенная конфигурация- набор страниц, размещения портлетов, контенты) — соотвественно все собирает команда разработки, ставит — и потом это стоит и не меняется. Правильно понял? Тогда да — такой подход «независимых» порталов у вас сработает.

В нашем случае мы даем в первую очередь набор инструментов (портлеты) — проводим первичную установку, настройку — а дальше уже админы и бизнес-пользователи клиента по необходимости управляют всем этим. В этом случае — сам Liferay настраивается в кластер (и тут не со всем понял что имеется в виду под «масштабируется слабо») — и да — все сервера Liferay используют одну базу (дальше если требуется — база кластеризуется своими средствами).

Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы. При старте портал в частности определяет тип сервера, определяет поведение при хот-деплое и прочее. Вот поддержку нюансов для коммерческих серверов из Liferay CE 7 и удалили.
Аналогично с базами данных — да, Liferay использует Hibernate — но не все что поддерживает Hibernate — поддерживается в Liferay — так как для каждой базы есть свои небольшие «допилы». Их тоже удалили.

Хотя это лукавство — код из истории github не удалишь — так что все легко возвращается. Другое дело что развитие этой поддержки будет уже только в платной версии.
Но 800 req/s — неплохо!
Правильно понял?

Ну да и нет :) Мы вполне позволяем менять настройки и пр. администратору портала со стороны заказчика. Т.е. мы делаем первоначальное внедрение (страницы, конфигурация портлетов, контент и пр.), а потом это все может модифицировать заказчик. И вот тут начинается веселье. Мы делаем какие-то новые фичи, требующие изменение настроек и админы делают изменения в конфиге — как мержить?
Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы.

Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?
и тут не со всем понял что имеется в виду под «масштабируется слабо»

Кластеризация предполагает постоянную синхронизацию по данным. А это сразу же бутылочное горлышко — горизонтально не отмасштабируешься.
Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?


Те кто не на томкате, wildfly и глассфише. Считается что если у вас есть деньги на WebSphere/WebLogic — то глупо экономить на «спичках» (лиценизциях на Liferay). Аналогично с базами — если есть деньги на Oracle — то ожидается что и на портал найдутся.

Кластеризация предполагает постоянную синхронизацию по данным. А это сразу же бутылочное горлышко — горизонтально не отмасштабируешься.


Понял, согласен! Как вы и писали выше — Liferay использует ehcache и как только возникает кластер — встает задача синхронизации кешей на нодах. Ну и 100 нод щелчком мыши не запустишь — сразу уткнешься в вопросы синхронизации. В платной версии есть плагин который оптимизирует синхронизацию данных между нодами — но все равно на больших кластерах это будет бутылочное корлышко.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий