Архитектура

Enterprise приложения часто включают три основные части: пользовательский интерфейс, база данных и сервер. Cерверная часть обрабатывает HTTP запросы, выполняет доменную логику, запрашивает и обновляет данные в БД, формирует ответ, который затем отправляется клиенту. Любое изменение в системе приводит к пересборке и развертыванию новой версии серверной части приложения.

Монолитный сервер - распространенный способ построения подобных систем. Вся логика по обработке запросов выполняется в единственном процессе, при этом можно использовать возможности языка программирования для разделения приложения на классы, функции и т.д. Можно запускать и тестировать приложение на машине разработчика и использовать стандартный процесс развертывания для проверки изменений перед выкладыванием их в продакшн. Можно масштабировать монолитное приложения горизонтально путем запуска нескольких физических серверов за балансировщиком нагрузки. Монолитные приложения могут быть успешными, но все больше людей разочаровываются в них, особенно в свете того, что все больше приложений развертываются в облаке. Любые изменения, даже самые небольшие, требуют пересборки и развертывания всего монолита. С течением времени, становится труднее сохранять хорошую модульную структуру, изменения логики одного модуля имеют тенденцию влиять на код других модулей. Масштабировать приходится все приложение целиком, даже если это требуется только для одного модуля этого приложения. Эти неудобства привели к архитектурному стилю микросервисов: построению приложений в виде набора сервисов.

Основное преимущество микросервисного подхода перед монолитным - при единой архитектуре не приходится развертывать приложение целиком. У микросервисов выше доступность: если один из них вышел из строя, это не приводит к сбою всего приложения. Сохранять модульность и инкапсуляцию может быть непросто, несмотря на правила SOLID. Однако микросервисы позволяют гарантировать отсутствие общих состояний (shared state) между модулями. Так же микросервисы позволяют использовать разные технологии и языки, в соответствие с поставленными задачами. "Общение" сервисов может происходить различными путями. Чаще всего взаимодействие осуществляется с помощью REST или JMS.

REST - архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы.

Java Message Service (JMS) — стандарт промежуточного ПО для рассылки сообщений, позволяющий приложениям, выполненным на платформе Java EE, создавать, посылать, получать и читать сообщения. Коммуникация между компонентами, использующими JMS, асинхронна (процедура не дожидается ответа на своё сообщение) и независима от исполнения компонентов. JMS поддерживает две модели обмена сообщениями: «точка - точка» и «издатель-подписчик».

Модель «точка - точка» характеризуется следующим:

• каждое сообщение имеет только одного адресата;
• сообщение попадает в «почтовый ящик», или «очередь» адресата и может быть прочитано когда угодно. Если адресат не работал в момент отсылки сообщения, сообщение не пропадёт;
• после получения сообщения адресат посылает извещение.

Модель «издатель-подписчик» характеризуется следующим:

• подписчик подписывается на определённую «тему»;
• издатель публикует своё сообщение. Его получают все подписчики этой темы;
• получатель должен работать и быть подписан в момент отправки сообщения.

Важной особенностью JMS является то что он гарантирует доставку сообщений.

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