Динамическая Масштабируемая и адаптивная архитектура

Я участвую в большом проекте с использованием микросервисов на основе Docker и Consul. (Мы используем другую службу очередей — RabbitMQ, поэтому я не могу подробно говорить об этом аспекте, но в целом очередь — это очередь.)

Ни Docker, ни Consul, ни какая-либо технология очередей, о которой я знаю, не предоставляют функции автоматического масштабирования. Docker предоставляет простой способ развернуть несколько экземпляров службы, а Consul обеспечивает обнаружение службы (как вы сказали) и постоянное хранилище ключей/значений. Очередь — это просто способ передачи сообщений между экземплярами службы. Ничего из того, что вы упомянули, не поддерживает автомасштабирование.

Чтобы добавить функциональность автомасштабирования, вам нужно взглянуть на что-то вроде Kubernetes.

Вы можете посмотреть на что-то вроде CloudFoundry или Mesos. Однако для обоих из них требуется уровень виртуализации, такой как OpenStack или VMWare vSphere. С этими продуктами приходит значительная ценность, но также цена и сложность.

Вместо того, чтобы идти по этому пути, я рекомендую вам заглянуть в Amazon Web Services. Используя AWS, вы можете легко запускать док-контейнеры и настраивать автомасштабирование в зависимости от загрузки ЦП, сообщений в очереди, времени суток (или дня недели) и т. д. Я знаю, что использование AWS имеет свою цену, но при хорошем дизайне и управлении , это будет стоить вам гораздо меньше, чем попытки спроектировать, внедрить и обслуживать самостоятельно. Вы также можете использовать самые маленькие (т. е. бесплатные) машины и/или точечные экземпляры для минимизации затрат.

Это интересный вопрос. Все упомянутые вами компоненты являются независимыми с четко разделенными сильными сторонами и ролями в архитектуре микросервисов. Необычная часть заключается в использовании обмена сообщениями, а не HTTP. Я думаю, что это ценное отклонение, поскольку оно обеспечивает более гибкие схемы вычислений (производителю работы не нужно быть потребителем продукта или даже получать уведомление). Особая прелесть пропуска HTTP заключается в том, чтобы избежать затрат (как эксплуатационных расходов, так и задержек обслуживания), сложности и дополнительных режимов сбоя балансировщиков нагрузки.

1. Docker: для управления упаковкой отдельных сервисов и их доставкой в ​​инфраструктуру ZeroMQ: для управления эффективной одноранговой или посреднической связью между сервисами Consul: обнаружение сервисов (например, выяснение, где находится пользовательский сервис)

2. Автомасштабирование не выполняется Docker. Вы можете сделать это с помощью собственного микросервиса, который проверяет метрики нагрузки (например, среднюю нагрузку, использование физической/своп-памяти и т. д.), запускает реплики и обновляет Consul.

   В качестве альтернативы вы можете воспользоваться решениями по автомасштабированию, подробно описанными @drhender: Kubernetes, Mesosphere DCOS или AWS Autoscaling Groups. Однако обратите внимание, что использование групп AWS Autoscaling Group значительно ограничивает переносимость вашего решения.

   Какой бы механизм автомасштабирования вы ни выбрали, убедитесь, что шаблоны сообщений ZeroMQ поддерживают добавление или удаление служб. В Руководстве по ZeroMQ есть хорошие советы по этой теме.

3. Consul может обеспечить как обнаружение служб, так и потребности в настройке служб. Помните о проблемах с безопасностью хранения, если вы храните конфиденциальные данные, такие как PHI или PII. Их лучше хранить с помощью средств защиты в состоянии покоя, таких как запасы Убежища.

   Агент Consul собирает данные телеметрии, которые вы можете отслеживать на наличие проблем. Существует также довольно простой набор тестов Consul KV, который можно использовать для тестирования хранилище конфигурации.

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

4. Отказ узла — интересная проблема. Консул может узнать об этом через проверки работоспособности, но ZeroMQ создает некоторые проблемы в зависимости от шаблонов обмена сообщениями. Например, используя пару REQ-REP, если запрос отправлен, а ответчик умирает после доставки, по моему опыту, сокет REQ будет заблокирован навсегда. Есть способы обойти это с тайм-аутами.

   Я бы положился на Consul для этого и был бы готов прерывать или возрождать сокеты REQ при сбоях. Полный отказ от взаимодействия в стиле RPC с помощью поэтапной управляемой событиями архитектуры (SEDA), в которой производители входных данных не являются потребителями выходных данных, почти полностью исключает это. Вы всегда сталкиваетесь с проблемой потери входных или выходных данных в очереди в случае сбоя, поэтому вам нужен мониторинг на уровне системы и механизмы повторных попыток, если потеря работы фатальна.

ContainerBuddy позволяет поместить любое запускаемое приложение в контейнер Docker и зарегистрировать его в Consul. Это может упростить вам задачу.