Показаны сообщения с ярлыком Nginx. Показать все сообщения
Показаны сообщения с ярлыком Nginx. Показать все сообщения

вторник, 29 октября 2013 г.

Настраиваем связку Tomcat+Nginx

Это сугубо практичный пост: просто набор команд для настройки "маленького сервера с блекджеком и танцовщицами" для хостинга java-приложений. Настраивал сегодня wds на Ubuntu 12.04 и, наверное, в десятый раз вспоминал всё это. Теперь всё будет в одном месте.

1. Java
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java6-installer


в конец ~/.bashrc добавляем 
export JAVA_HOME=/usr/lib/jvm/java-6-oracle 

2. Tomcat
sudo apt-get install tomcat7

Tomcat будет стартовать при старте системы, приложения будут разворачиваться на порту 8080 (каждое в своём соответствующем контексте) если .war залить в  /var/lib/tomcat7/webapps/.
Так уже можно работать, но для клиентов нужно спрятать tomcat за прокси, чтобы иметь возможность фровардить порты и прятать контексты за доменными именами. 

3. Nginx
wget http://nginx.org/keys/nginx_signing.key
sudo apt-key add nginx_signing.key

В конец файла /etc/apt/sources.list добавляем строки:
deb http://nginx.org/packages/ubuntu/ codename nginx 
deb-src http://nginx.org/packages/ubuntu/ codename nginx

где codename - имя дистрибутива (посмотрите его в строчках выше или получите из сat /etc/*-release) 

sudo apt-get update
sudo apt-get install nginx

Это почти всё. Осталось только настроить проксирование запросов. Допустим, мы пишем конфиг для нашего хоста newgoogle.com, приложение для которого мы в tomcat-e развернули на контексте /ng:
sudo cp /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/newgoogle.com.conf
sudo vim /etc/nginx/conf.d/newgoogle.com.conf
меняем server_name на newgoogle.com и меняем location-секцию на: 
    location / {
        proxy_pass        http://localhost:8080/ng/;
        proxy_set_header  X-Real-IP  $remote_addr;
    }

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

вторник, 24 апреля 2012 г.

Оповещаем Android о событиях на сервере

Допустим, у нас есть достаточно популярное Android-приложение, в которое мы хотим добавить опцию оповещения пользователей о каких-либо событиях. Например, пользователь должен иметь возможность оперативно получить новость или персональное сообщение от другого пользователя. Как решить такую задачу?
Решение в виде сервиса на устройстве, который регулярно опрашивает сервер выглядит несовременно, да и опасно: достаточно большое количество пользователей могут задосить нам сервер. Увеличение интервала опроса в нашем случае решает проблему нагрузки с одной стороны, но снижает скорость доставки с другой.
Второй вариант: использовать Cloud to Device Messaging Framework. Действительно хорошее решение, но в ряде случаев не подходит. Во-первых, передаче сообщений через сторонние сервера могут препятствовать соображения конфиденциальности, а во-вторых, если приложение должно поддерживать версию Android 2.1 и ниже, то этот фреймворк нам не поможет.
Третий вариант - использовать свой http push сервер, например nginx + nginx push stream module. Можно поспорить, что лучше, много запросов или много коннектов а также сравнить производительность разных серверов, но цель у нас сейчас другая. Давайте рассмотрим простой вариант реализации такого оповещения.


понедельник, 14 ноября 2011 г.

Nginx+Redis: делаем асихронное web-приложение для больших нагрузок

Как работает обычное web-приложение?
Примерно так:
Проходит время, нагрузка растёт и узким местом становится база данных. Разработчики, стараясь снять с неё нагрузку, переходят к асинхронной схеме. Тут база данных не используется в каждом запросе. В основном используется только быстрое noSQL-хранилище или специализированный сервер очередей, для передачи заданий пулу обработчиков. Основную работу эти обработчики выполнят уже позже, когда довольный клиент получит быстрый ответ и пойдёт заниматься своими делами:


Но нагрузка может расти и дальше. Оставим в стороне "горизонтальное" масштабирование при котором мы строим кластера и плодим инстансы приложений - речь сейчас не об этом. Что в последней схеме становится узким местом? База данных уже не в счёт: спрятанная за слоем очередей и обработчиков, кэшей и буферов, она может чувствовать себя спокойно. Обработчики великолепно масштабируются, ведь они "висят" на безразмерной шине очереди. Nginx - один из самых высопроизводительных серверов, за него не беспокоимся. noSQL-хранилища тоже как правило замечтально держат нагрузку и масштабируются.
Что остаётся? К сожалению "крайним" остаётся наше web-приложение. Это оно разбирает запрос, авторизует его, создаёт обьекты, манипулирует с ними, сериализует в базу или в очередь. А потом ещё вычитать данные, сериализовать для ответа... Приложение может содержать неэффективный код, плохо масштабироваться... Кстати, а зачем нам оно вообще нужно? Давайте уберём его из схемы:


 Как же так? Очень просто. Задача получить данные из запроса и уложить в очередь вообще-то тривиальная. И обратная задача тоже. Зачем программировать тривиальные вещи? Всё уж сделано за нас :)
Nginx при помощи HttpRedis2Module может уложить в noSQL-хранилище Redis любые параметры из запроса в виде такого набора ключ-значение, который нам нужен. И вычитать нужный нам набор ключей для возврата клиенту. Вы не используете параметры запросов? У вас обмен с клиентской частью в формате JSON? Нет проблем! Используя set-misc-nginx-module мы можем прямо в конфиге nginx-а описать правила получения данных из запроса: UrlDecode, JSONDecode, Base64Decode и т.п.

Теперь посмотрим, как настроить такое "сверхтонкое" web-приложение: