Какова общая веб-архитектура для Java-приложений?

Question

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

Пока я планирую настроить следующую архитектуру

Internet ->
Varnish (reverse proxy) ->
Apache2 (mod_pagespeed, mod_jk) -> 
Ehcache-web (caching html page fragments,spring-cache) ->
Tomcat (java appsrv) ->
Ehcache (cache layer) -> 
MySQL (persistance layer)

Есть ли проблемы с этим дизайном? Как насчет масштабирования и кластеризации, когда дело доходит до этого? Есть ли другие (лучшие) решения?

Спасибо!

Answer 1

Я не предполагаю веб-приложение традиционным способом - но с точки зрения поставщиков услуг и потребителей.На работе у нас есть уровень API RESTful, работающий под Tomcat, созданный с использованием интерфейсов Shindig.Уровень взаимодействует с MySQL, а также с MongoDB.Мы используем ближнее / дальнее кэширование с использованием Memcached, которое мы планируем переместить в Redis, учитывая, что мы используем много операций со списками и множествами.Этот слой также взаимодействует с Twitter и Facebook для определенных API (например, выталкивает обновления статуса).Все конечные точки доступны как вызовы REST / XML, совместимые с OpenSocial.Мы используем NewRelic для мониторинга производительности сервиса и SLA.В настоящее время мы делаем чуть более 30 000 оборотов в минуту с временем отклика 10 мс.У нас есть кластер из 4 Tomcats, 3 memcacheds, 3 MySQL (1M 2S) и 3 MongoDB (replicaset).Весь стек работает на виртуальных машинах, размещенных на XenServer с Centos.Мы используем RabbitMQ для обмена сообщениями / асинхронных операций, таких как отправка уведомлений или общение с третьими лицами (Twitter / Facebook), чтобы не блокировать потоки виртуальных машин.Мы планируем перейти на HornetQ + Scala Actors в ближайшем будущем, поскольку платформа станет популярной.Поиск выполняется в Solr, но мы активно переходим на ElasticSearch.

Мы спроектировали систему в этой модели на основе API / Services, чтобы мы могли обслуживать более одной клиентской платформы.Поэтому, когда наше мобильное приложение запускается, оно может повторно использовать API вместо того, чтобы иметь отдельный набор одного и того же стека для Mobile.Эта архитектура абстрагирует серверные предложения без связи с внешним интерфейсом.Внешний интерфейс, который у нас есть, построен на PHP / Zend и широко использует JQuery.Мы создаем мобильный интерфейс с использованием HTML5, PhoneGap и Sencha Touch.

В целях безопасности у нас есть открытые GET, но запись защищена с помощью двухстороннего oauth.Нам нужно будет предоставить трехстороннюю поддержку, как только мы откроем API для внешних потребителей и разработчиков приложений.

Надеюсь, это резюме поможет.Пожалуйста, не стесняйтесь комментировать, если вам нужна дополнительная информация или у вас есть какие-либо вопросы.

Answer 2

Мы используем для нашего портала с высоким трафиком (около 55 млн. PI / месяц) 3 прокси Varnish, 3 балансировщика нагрузки Apache (2), на 6 серверах для сервера 4 сервера связи, взаимодействующих с apache через mod_jk.Как RDBMS, у нас есть оракулы.Я думаю, что выбор БД имеет решающее значение.Наше содержание - это наше существование, поэтому нам нужен продукт БД, который отзывчив, надежен, масштабируем, надежен, высокодоступен и так далее.Нам может понадобиться поддержка в худшем случае.По этой причине наш выбор был Oracle.

Выбор Tomcat / Application Server зависит от архитектуры вашего приложения.В нашем случае у нас есть Coremedia CMS (Spring CMS, которая содержит распределенные сервисы, такие как контент-сервер, главный живой сервер, фидер и т. Д., Взаимодействующие через CORBA) и кластеризованные Tomcats.

Я думаю, что ваш список / настройка и эта комбинация кажутся очень хорошими и достаточными для большинства случаев.