Архив метки: distributed app

Поиск и регистрация сервисов с Consul

Consul logoДопустим, есть у нас распределённое приложение, в которое входят два вида сервисов: web и db. Для большей надёжности они запускаются сразу в нескольких экземплярах, на разных хостах, иногда приходят в онлайн, иногда уходят, какие-то подвисли, какие-то ещё нет… В общем, хаос. Как в таком случае отдельно взятому сервису web отыскать себе живой db?

Самое очевидное решение — придумать какое-нибудь отдельное хранилище типа ключ-значение, в котором сервисы будут себя регистрировать при запуске: кто такой и куда слать запросы. Правда, сервисы иногда будут выключаться… Значит, перед выключением они должны себя «разрегистрировать».

А если сервис «упал», или сети не стало, он же тогда не сможет себя удалить из списков… Ну тогда можно ввести ещё один сервис, который будет проверять, живы ли ещё все остальные. А если..

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

Но её и не обязательно решать самому, когда для этого уже есть инструменты. Например, Consul. Читать далее Поиск и регистрация сервисов с Consul

Конфигурация сервисов c Consul Key-Value Store

consul logoКак люди обычно конфигурируют приложения? Некоторые, например, передают аргументы через командную строку. Ещё можно задать переменные окружения или просто указать на файл с настройками. Да чего уж там, пока никто не видит, опцию-другую можно и прямо в код прошить.

Но как быть с такой ситуацией. Есть у нас распределённое приложение: куча хостов, сервисы создаются, приходят в онлайн, уходят, и все с разными версиями и непонятными адресами. И вдруг нам нужно их всех переконфигурировать. Ничего такая задачка? С монолитным приложением можно было бы просто зайти на хост и поколдовать там. А как быть с распределённым?

Читать далее Конфигурация сервисов c Consul Key-Value Store

«Hello world» в Apache Kafka

Однохостовый Kafka кластер

Ну что, самое время отправить каких-нибудь данных через Apache Kafka. Но сначала, разумеется, его нужно установить.

Установка Кафки настолько простая, что в этот раз я отойду от своего обычного правила и в самом деле объясню, как его устанавливать. Итак, четыре шага:

  • Установить Java Development Kit (почему-то часто уже оказывается установленным)
  • Скачать архив с Кафкой
  • Распаковать ( tar -xzf kafka_2.11-0.10.1.0.tgz в *nix системах)
  • Всё. Кафка готов.

Читать далее «Hello world» в Apache Kafka

Краткое введение в Apache Kafka

Что такое Apache Kafka

Официальное определение для Apache Kafka — распределённая стриминговая платформа. Это одно из тех прекрасных определений, которые не имеют никакого смысла до тех пор, пока не посидишь хорошенько с документацией. На самом деле идея Кафки очень простая. В большой распределенной системе обычно много сервисов, которые генерируют разные события: логи, данные мониторинга, замеченные попытки доступа к секретным ресурсам, и т. п. С другой стороны, есть сервисы, которым эти данные очень нужны. И тут появляется Kafka: он сидит между продюсерами и консьюмерами данных (producer & consumer): собирает данные у первых, хранит у себя в распределенном хранилище по топикам и раздаёт вторым по подписке. Другими словами, Kafka — это гибрид распределенной базы данных и очереди сообщений.

Apache Kafka

Читать далее Краткое введение в Apache Kafka

Создаём RabbitMQ кластер

RabbitMQ кластер

Как и обещал в прошлый раз, сегодня мы попробуем какую-нибудь из продвинутых фич RabbitMQ. Например, кластеризацию.

RabbitMQ кластер это сразу несколько сервисов, у которых общие пользователи, настройки и даже очереди. Сервисы могут добавляться и удаляться на лету, располагаться на разных краях континента, но для подключённого клиента они будут выглядеть как один большой RabbitMQ сервис. Это хорошо для горизонтального мастшабирования —  когда клиентов становится так много, что одиночному брокеру уже не справиться.

Кластеризация — это не то же самое, что репликация и high availability. В первом и втором случае уход одного из узлов в оффлайн никак не повлияет на доступность данных и работу сервиса в принципе. В кластере же узлы не взаимозаменяемы. Да, пользователи и настройки действительно будут дублироваться на каждом их них, где бы тех не создавали. Но очереди сообщений — нет. Так что если какой-то хост ушёл в оффлайн, то его очереди пойдут следом.

Читать далее Создаём RabbitMQ кластер

Краткое введение в RabbitMQ

Краткое введение в RabbitMQ

RabbitMQ — это полноценная и щедро удобренная фичами очередь сообщений. В отличие от ZeroMQ, который встраивается в приложения, RabbitMQ — сервис-посредник. Он разграничивает права доступа, поддерживает шифрование, сохранение сообщений на диск (чтобы пережить плановое отключение электричества), работу в кластерах и даже дублирование сервисов для повышенной живучести. К тому же он написан на Erlang, за что автоматически становится неубиваемым и поддерживаемым на большинстве популярных ОС.

В этом посте мы посмотрим, насколько тяжело отправлять и получать сообщения с RabbitMQ, да и вообще, на что он похож вблизи. В качестве платформы будет Убунта (запертая внутри Docker контейнера), но сгодился бы и Mac, и Windows. Читать далее Краткое введение в RabbitMQ

Как использовать ZeroMQ с Docker

Как использовать ZeroMQ с Docker

В прошлый раз мы написали аж три примера клиент-сервер Node.js приложений, в которых компоненты общаются между собой через ZeroMQ. Примеры простые, показывают основную идею, но работают всё-таки на localhost, и поэтому слабо пересекаются с реальностью, в которой ZeroMQ обычно работает. И тогда я подумал, а почему бы не раскидать клиента и сервера по Docker-контейнерам? В задачу добавятся новые вопросы, она станет больше похожа на правду, и главное, это отличный шанс откатать сразу несколько инструментов, которые обычно используются вместе.

Итак, задача на сегодня: взять fire-and-forget паттерн из прошлого поста и доработать его до контейнерного приложения. Читать далее Как использовать ZeroMQ с Docker

Обмен сообщениями между сервисами с ZeroMQ и Node.js

ZeroMQ

ZeroMQ это небольшая и шустрая библиотека для обмена сообщениями, которая одинаково хорошо работает как между процессами на одном хосте, так и по сети. Хотя она написана на C++, очень добрые люди создали адаптеры для всего: хоть для Node.js, хоть для Haskell.

Работа с ZeroMQ напоминает работу с TCP/UDP сокетами. Один процесс создаёт сокет и привязывает его к адресу, второй — подключается к первому, и понеслась, родная. Правда, сокеты в ZMQ весьма необычные. Но, наверное, стоит начать с примеров, и по ходу дела уже вдаваться в детали. Читать далее Обмен сообщениями между сервисами с ZeroMQ и Node.js

Краткое введение в docker-compose

Что такое docker-compose

docker-composeКак docker может управлять отдельно взятым контейнером, так docker-compose помогает управлять не просто одним, а всеми контейнерами, которые составляют распределенное приложение. Причём, не только контейнерами, но и сетями, подключёнными папками и всеми связанными с этим настройками.

Ведь даже чтобы запустить простое вэб-приложение, состоящее всего из двух контейнеров (например, «web» с контентом и «db» с данными), нужно как минимум:

Читать далее Краткое введение в docker-compose