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

Question

Я студент PhD в области облачных вычислений, я планирую использовать архитектуру на основе микросервисов с консулом и zeromq для моего исследовательского проекта. У меня было несколько вопросов, которые мне трудно понять. Может кто-то помочь мне поделиться своим опытом.

1. У нас есть микросервисы на основе докеров, у нас есть zeromq, и у нас есть консул. Можете ли вы упомянуть, как мы могли бы объединить все три вместе, чтобы иметь динамическую адаптивную среду?

Хотя я понимаю, как к тому, что ZeroMQ, докер и консулом индивидуально, я до сих пор не удалось получить четкую картину того, как все они функционируют как whole.We имеют Docker контейнеры, имеющие microservices, работающие в них на хост. Мы используем zeromq для транспорта (Pub-sub/pipe) сообщений между контейнерами докеров. Контейнеры могут работать на одном и том же узле/центре обработки данных или на разных хостах/центрах обработки данных. Затем мы используем консул для обнаружения сервисов. Я понимаю, что здесь правильно?

2. Как динамически масштабируется архитектура в зависимости от рабочей нагрузки?

Скажем, у меня есть ситуация, когда мне нужно больше рабочих узлов для определенного вычисления на какое-то время. Кто закручивает больше рабочих узлов. Какой компонент определяет/принимает это решение?

Есть ли компонент планирования? Если да, может кто-нибудь кратко объяснить, как это происходит или какой компонент выполняет эту функцию?

3. Итак, какова главная роль консула? Используется ли он только для обнаружения сервисов? Может ли он использоваться и для конфигураций. Если да, то каково его ограничение?

Я вижу, что даже у zeromq есть механизмы обнаружения услуг, так зачем нам нужен консул?

4. Как происходит сбой в информации об узле в архитектуре? Какой компонент несет ответственность? Это просто консул? Или zeroMq также?

Прошу совета.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

   Я бы опирался на Консула для этого и был готов прервать или возродить разъемы REQ при сбоях. Избежать взаимодействия стиля RPC полностью, используя Staged Event Driven Architecture (SEDA), где производители входных данных не являются потребителями выходов сборок этого почти полностью. У вас всегда есть задача потерять поставленные в очередь входы или выходы при сбое, поэтому вам понадобятся системный мониторинг уровня и механизмы повторной попытки, если потеря работы будет фатальной.

ContainerBuddy позволяет поместить любое спускаемых приложение в контейнере Докер и его регистрацию консулом. Это может упростить вам вещи.