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