Spring RESTful сервисная прикладная архитектура - PullRequest
Новая
       28

Spring RESTful сервисная прикладная архитектура

0 голосов
/ 13 октября 2011

В настоящее время мы создаем приложения для веб-сервисов с использованием Spring, Hibernate, MySQL и tomcat. Мы не используем настоящий сервер приложений - архитектура SoA. Что касается уровня персистентности - сегодня мы используем Hibernate с MySQL, но через год мы можем получить MongoDB и Morphia.

Идея заключается в том, чтобы создать архитектуру системы независимо от конкретного механизма базы данных или уровня персистентности и получить максимальные преимущества.

Позвольте мне объяснить - https://s3.amazonaws.com/creately-published/gtp2dsmt1. У нас есть два случая:

Сценарий первый: У нас есть одна база данных, которая реплицируется (в начале нет) и разные приложения. Каждое приложение представляет на войне один контроллер, контекст приложения, сервлет xml. Слой домена и персистентности импортируется как maven lib - для него есть одна версия, включенная в каждое приложение.

Плюсы:

  • Небольшие приложения, которые легко обслуживать
  • Распределенное решение - каждое приложение может быть перенесено на собственный экземпляр tomcat или на другой компьютер, например

Минусы:

  • Возможные проблемы при использовании hibernate-сессии и ее синхронизации между различными приложениями. Я не знаю, что это вообще возможно при такой реализации.

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

Плюсы:

  • Один персистентный слой - полнофункциональный hibernate
  • Больше j2ee с вариантами расширения до следующего уровня - интеграция EJB и переход на сервер приложений

Минусы:

  • Одно огромное военное приложение, больше усилий для поддержания
  • Не распространять, как в первом сценарии

Мне больше нравится первый сценарий, но меня беспокоит поведение Hibernate в этом случае и все преимущества, которые я могу от него получить.

Я буду очень благодарен за ваше мнение по этому делу.

Приветствия

Ответы [ 2 ]

1 голос
/ 14 октября 2011
  • Возможные проблемы при использовании Hibernate-сессии и ее синхронизации между различными приложениями.Я не знаю, возможно ли это вообще с такой реализацией.

Есть пара решений, которые решают эту точную проблему:

Terracotta

Взгляните на Учебное пособие по Hibernate Distributed Cache

Также есть немного более старый общий ресурс для слайдов Масштабирование Hibernate с Terracotta , которое обеспечиваетточка в картинках

Infinispan

Взгляните на Использование Infinispan в качестве провайдера кэширования второго уровня JPA-Hibernate

Начиная с первогорешение (распределенное) может быть верным путем.

Все зависит от бизнес-проблемы

Конечно distributed круто и отказоустойчиво и, и, .. но Оперативная память и диски становятся все дешевле и дешевле, поэтому «расширение» (и наличие двух «горячих» реплик) на самом деле не так уж и плохо => это подпорка «второму» подходу, который вы описали.

Но допустим, вы идете с подходом # 1.Если вы сделаете это, вы выиграете от перехода на NoSQL в будущем, так как теперь у вас есть наборы / разбиения реплик и т. Д. И фактически несколько узлов для поддержки этой концепции.

Но ... это 100% согласованность что-то, что должно иметь?(например, имеет ли продукт отношение к деньгам ).Насколько большим вы планируете стать => готовы ли вы поддерживать сотни серверов?У вас есть сложные агрегированные запросы, которые должны выполняться быстрее, чем xteen часов?

Это вопросы, которые, помимо вашего понимания бизнеса, должны помочь вам приземлиться на # 1 или # 2.

0 голосов
/ 15 февраля 2012

Итак, это очень поздний ответ, но, наконец, я готов ответить.Здесь я приведу некоторые подробности о дальнейшей разработке приложения-службы REST.

Наконец-то я нашел решение № 1 из tolitius - отличный ответ с возможностью перехода на решение № 2 вболее поздняя стадия.

Это архитектура приложения - позже я добавлю графику.

Уровень постоянства - содержит модель домена, все операции с базами данных.Генерируется из модели базы данных с помощью Spring Roo, сгенерированного хранилища и сервисного уровня для облегчения последующей миграции.

Бизнес слой - здесь находится вся бизнес-логика, необходимая для операций.Этот уровень зависит от уровня Постоянство .

Проверка представления , контроллеры вызывают уровень Business .

Все этозапустить на Tomcat без дополнений сервера приложений.На более позднем этапе это можно переместить на сервер приложений и полностью реализовать шаблон локатора служб.

Инфраструктура - географически расположенные серверы с гео-балансировщиком нагрузки, кольцом репликации MySQL между всеми ними и одним сервером резервного копирования и одним сервером резервного копирования в случаепровал.

Моя идея состояла в том, чтобы сделать более современную системную архитектуру, но, исходя из моего опыта работы с технологиями Java, это «нормальный риск».

С большим опытом - более красивые решения :) Взгляджду этого!

...