Создание отказоустойчивого мягкого веб-приложения в реальном времени с Erlang/OTP
Я хотел бы создать отказоустойчивое мягкое веб-приложение в реальном времени для магазина доставки пиццы. Это должно помочь магазину пиццы принимать телефонные звонки от клиентов, размещать их как заказы в системе (через веб-клиент CRM) и помогать диспетчерам назначать драйверы доставки для заказов.
В этих целях нет ничего необычного, но я хотел бы сделать сервис доступным 24/7, то есть сделать его отказоустойчивым. Более того, я бы хотел, чтобы он работал очень быстро и был очень отзывчивым.
Ниже приведен очень простой вид архитектуры для такого приложения.
Проблема в том, что я не знаю, как использовать все достоинства Erlang/OTP, чтобы сделать приложение очень отзывчивым и отказоустойчивым.
Вот мои вопросы:
- Какие элементы системы должны быть реплицированы для обеспечения отказоустойчивости и как мне это сделать? Я знаю, что могу хранить статус каждого транспортного средства (координаты, назначенные заказы и т. Д.) В реплицированной базе данных Mnesia. Это правильный путь?
- Какие службы хранения данных должны быть обычными на основе SQL (например, на основе boss_db), а какие должны быть сделаны в Mnesia, чтобы обеспечить очень быстрый ответ? Можно ли использовать обычную базу данных SQL для хранения записей и истории клиентов в таком отказоустойчивом и быстродействующем приложении?
- Должен ли я попытаться сохранить все данные обо всех службах (клиенты, состояние транспортных средств и т. Д.) В оперативной памяти, чтобы обеспечить высокую чувствительность приложения?
- Должен ли я хранить постоянные данные транспортного средства (идентификатор, емкость и т. Д.) В обычной базе данных SQL и хранить данные в реальном времени (координаты, назначенные заказы, заказы в магистрали и т. Д.) В базе данных Mnesia, чтобы сделать приложение более в режиме реального времени реагировать?
2 ответа
Прежде всего, это большой вопрос, но я постараюсь разбить его. Давайте сначала посмотрим на факты. Это веб-сервис. Это означает, что у нас есть эти слои: Web Server, Middle ware application а потом Data Storage, В большинстве приложений с высокой доступностью уровень хранения данных должен иметь избыточность через replication и нагрузка управляется через Distribution, В большинстве реальных приложений вам не нужно ничего хранить в ОЗУ, если только приложение не имеет реального характера в реальном времени, например Multi-player Game Server или же A telecom Switch, Таким образом, ваше приложение, в данном случае, действительно, не нуждается в оперативной памяти (может быть, какое-то caching здесь и там, как мы увидим.)
Теперь этот тип приложения включает в себя данные различного типа, информацию, которая не может иметь одинаковую форму одновременно, следовательно, использование RDMS заставит вас все упорядочить одинаково. Я предлагаю вам научиться использовать любые document oriented database, NoSQL DB или же key-value system потому что они хорошо смоделированы для реальных сложностей. Более подробную информацию о любом виде хранилища можно найти в этом файле PDF. Я предлагаю вам использовать базовый сервер Couch, на котором ваши данные будут просто JSON documents, schemaless и может развиваться по мере роста вашего приложения. Он поставляется с распространением и репликацией, так же, как это требовалось любому приложению. Вы можете добавлять или удалять серверы во время выполнения, и вся система просто продолжает балансировать себя. Это также идет с memcached встроенный для кеширования, поэтому для той части IN-Memory, о которой вы говорили, кеширование все сделает за вас.
После хранения давайте поговорим о промежуточном программном обеспечении. я хочу поговорить о веб-сервере как о промежуточном продукте. Вам понадобится очень стабильный веб-сервер, в зависимости от нагрузки и того, что вы хотите использовать Erlang, я предлагаю веб-сервер yaws и научиться работать с ним с помощью RESTFUL, используя appmods, Использование прокси Sunch как Nginx Infront кластера веб-серверов может помочь в управлении нагрузкой. По крайней мере, существует несколько способов балансировки нагрузки между веб-серверами. После этого вам потребуется приложение OTP. Приложение OTP не обязательно должно иметь gen_servers, Но, как вы узнаете, вы действительно обнаружите, где вам нужно распараллеливание или где вам нужен последовательный код. Однако беспокоиться о том, что вы хотите использовать то, что вы еще не освоили. Пожалуйста, следуйте этой веб-книге и этой книге Ориелли, чтобы помочь вам освоить все об Эрланге. Вы можете найти полезным попробовать Chicago Boss а также Mochiweb или же Misultin Http сервер библиотеки.
Еще одна вещь, которую я должен упомянуть о выполнении этого в Erlang, заключается в том, что вам необходимо освоить свои структуры данных и эффективный способ работы с ними. Плохой выбор структур данных может вызвать проблемы. Тестируйте и тестируйте все на каждом этапе. использование records везде, где это возможно, и проверьте потребление памяти на каждом этапе. Об этом вопросе есть что сказать, но, надеюсь, другие тоже отправят свои мысли.
Взломайте эту игру: https://github.com/synrc/games все вопросы в режиме реального времени, с малой задержкой, паб / саб, базы данных, вопросы архитектуры, написанные как современное программное обеспечение. Я предлагаю использовать gen_fsm для управления состояниями в вашем приложении, как это сделано в "нормальных" супервизорах. riak интегрирован с библиотекой kvs, которая также поддерживает социальные обновления. n2o выбрал ковбойский сервер, на мой взгляд, лучший сервер вокруг. http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/