Что такое микросервисы node js
Создание микросервисов с Node.js
Когда ваше JavaScript-приложение увеличивается в размерах, вы начинаете сталкиваться с проблемами, связанными с поддержкой кода, исправлением ошибок и внедрением новых функций. Кроме того, добавление новых разработчиков в проект становится сложным.
Приложения создаются из кусочков, таких как пакеты и модули, но в какой-то момент этих структур недостаточно для уменьшения размера и сложности приложения. Идея, лежащая в основе распределенных систем, состоит в том, чтобы разбить большие монолитные конструкции на маленькие независимые программы, которые обмениваются данными друг с другом для обмена данными и выполнения операций.
Одним из многих вариантов распределенных систем является архитектура микросервисов, которая структурирует приложение как набор слабо связанных сервисов. Службы детализированы, а протоколы связи легковесны (например, протокол HTTP).
Есть несколько вещей, которые стоит подчеркнуть о превосходстве микросервисов и распределенных систем в целом над монолитной архитектурой:
В этой статье вы узнаете, как создавать микросервисы, создавая базовую систему, состоящую из двух JavaScript-сервисов, работающих на Node.js.
Подготовка для построения архитектуры микросервисов с Node.js
Для выполнения задач в этом посте вам понадобится следующее:
Чтобы наиболее эффективно учиться на этом посте, вы должны иметь следующее:
Создаем сервис героев
Перейдите в каталог, в котором вы хотите создать проект, и создайте следующую структуру каталогов и файлов:
Инициализируйте проект npm внутри каталога /heroes и установите необходимые зависимости, выполнив следующие команды:
Пришло время реализовать сервис. Скопируйте этот код JavaScript в файл /heroes/heroes.js:
Загрузите изображения и команды супергероев по следующим ссылкам и поместите их в каталог /heroes/img :
Код для сервиса героев обеспечивает:
Протестируйте сервис heroes.js
Код службы героев, показанный ниже, позволяет запускать службу на любом порту HTTP, который вы хотите.
Запустите службу, выполнив следующую инструкцию командной строки:
Вы можете проверить, работает ли служба должным образом, используя Postman, curl, PowerShell Invoke-WebRequest или ваш браузер. Например выполните команду curl указанную ниже:
Если служба работает правильно, вы должны увидеть результаты, похожие на следующий вывод консоли из curl:
В Postman тело ответа должно выглядеть так:
Создаем сервис «угроз»
Какова цель супергероя, если нет опасности? Архитектура микросервисов нашего приложения использует отдельный сервис для представления задач, которые может преодолеть только супергерой. Он также предоставляет конечную точку API для сопоставления супергероев с угрозами.
Процедура создания сервиса угроз аналогична сервису героев.
В главном каталоге вашего проекта создайте следующую структуру каталогов и файлов:
Поместите этот код JavaScript в файл /threats/threats.js:
Вы можете скачать фотографии по следующим ссылкам и поместить в каталог /threat/img:
Поскольку код реализует взаимодействие между службами, ему необходимо знать адрес службы героев, как показано ниже. Если вы изменили порт, на котором работает служба героев, вам нужно отредактировать эту строку:
Тестируем службу «угроз»
Если вы остановили службу героев или закрыли окно терминала, перезапустите ее.
Откройте другое окно терминала и запустите службу угроз, выполнив следующую инструкцию командной строки:
Так же, как вы тестировали сервис героев, протестируйте сервис угроз, выполнив веб-запрос с помощью Postman, curl, PowerShell Invoke-WebRequest или вашего браузера. Обратите внимание, что на этот раз это запрос POST.
Инструкция командной строки curl:
Если служба работает правильно, вы должны увидеть результаты, похожие на следующий вывод консоли из curl:
В Postman тело ответа должно выглядеть так:
В окне терминала, где работает служба героев, вы должны увидеть:
Вы только что отправили Купера (localhost:8081/img/cooper.jpg) с заданием.
. полететь в Пизу и спасти исторический памятник! (localhost:8082/img/tower.jpg):
Вы можете использовать изображения героев и угроз для самостоятельного изучения функциональности сервисов. Эти объекты также будут частью проекта в следующей публикации, которая использует этот проект в качестве отправной точки.
Учимся общаться между микросервисами на Node.js через RabbitMQ
Это продолжение статьи «Пишем первый микросервис на Node.js с общением через RabbitMQ», которая была неплохо принята пользователями хабра.
В этой статье я расскажу о том, как нужно правильно общаться между микросервисами, чтобы микросервисы оставались изолированными.
Как делать не стоит
Зачем нужно общаться между микросервисами? Используешь одну базу данных, читаешь оттуда что хочешь — делов-то!
Нет, так делать нельзя. Концепция микросервисов заключается в том, что они изолированы друг от друга, никто ни о ком ничего не знает (практически). Скорее всего, в будущем, когда система начнет разрастаться, вы захотите расширять функционал и вам понадобится общаться между микросервисами: например, пользователь купил товар, значит, нужно отправить уведомление о продаже продавцу.
Преимущества изоляции
Надежность
Предположим, имеется монолитное приложение, в котором есть несколько контроллеров:
В один прекрасный день у нас падает база данных: теперь мы не можем получить ни товары, ни скидки, ни статьи для блога, ни пользователей. Сайт полностью недоступен, клиенты не могут зайти, бизнес теряет прибыль.
Что будет в микросервисной архитектуре?
В другой вселенной, в этот же день падает база данных микросервиса пользователей, он становится недоступным: пользователи не могут выйти из аккаунта, зарегистрироваться и залогиниться. Казалось бы, что все плохо и бизнес так же теряет прибыль, но нет: потенциальные покупатели могут посмотреть имеющиеся товары, почитать блог компании, находить скидки.
Благодаря тому, что у каждого микросервиса своя база данных, сайд-эффектов становится куда меньше.
Это называется постепенная деградация.
Абстракция
В большом приложении очень сложно сосредоточиться на одной задаче, поскольку поменяв какую-нибудь небольшую миддлвару, можно сломать какой-то контроллер. Захотите использовать новый клиент для redis — нет, нельзя, тот контроллер, который мы написали три года назад, использует версию 0.1.0. Хотите наконец-то использовать новые возможности Node.js 10? А может 12? Извините, но в монолите используется 6 версия.
Как общаться
Раз уж мы заговорили о примере «пользователь купил товар, отправляем уведомление о продаже продавцу», тогда его и реализуем.
Устанавливаем MicroMQ
Пишем gateway
Гейтвей у нас состоит лишь из одного эндпоинта, но этого хватит для примера и тренировок.
Пишем микросервис notifications
Здесь мы поднимаем вебсокет-сервер и микросервис одновременно, чтобы принимать запросы и по вебсокетам, и по RabbitMQ.
Пишем микросервис market
Проверяем
Пишем первый микросервис на Node.js с общением через RabbitMQ
Со временем, каждый проект растет и реализовывать новый функционал в существующий монолит становится все сложнее, дольше и дороже для бизнеса.
Один из вариантов решения данной проблемы — использование микросервисной архитектуры. Для новичков или для тех, кто впервые сталкиваются с данной архитектурой, может быть сложно понять, с чего начать, что нужно делать, а что делать не стоит.
В этой статье будет написан простейший микросервис на Nodejs & RabbitMQ, а также показан процесс миграции монолита на микросервисы.
Что есть в микросервисной архитектуре?
Почему именно RabbitMQ?
Разумеется, можно не использовать RabbitMQ, есть другие варианты общения между микросервисами. Самый простой — HTTP, есть gRPC от Google.
Я использую RabbitMQ, поскольку считаю его достаточно простым для старта написания микросервисов, надежным и удобным в том плане, что отправляя сообщение в очередь, можно быть уверенным в том, что сообщение дойдет до микросервиса (даже если он выключен в данный момент, а потом включился). Благодаря этим преимуществам можно писать надежные микросервисы и использовать бесшовный деплой.
Начало
Для начала реализуем простой gateway, который будет принимать запросы по HTTP, слушая определенный порт.
Разворачиваем RabbitMQ (через него наши микросервисы и gateway будут общаться):
Инициализируем проект и устанавливаем NPM-пакет micromq:
Пишем gateway
Как это будет работать:
Пишем микросервис
Как это будет работать:
Миграция монолита на микросервисную архитектуру
Предположим, что у нас уже есть приложение на express, и мы хотим начать его переносить на микросервисы.
Оно выглядит следующим образом:
Мы хотим вынести из него 2 эндпоинта: /friends и /status. Что нам для этого нужно сделать?
В примере выше, когда мы создавали микросервис users, мы реализовали два метода /friends и /status, который делают то же самое, что делает наш монолит.
Для того, чтобы проксировать запросы в микросервис из gateway, мы воспользуемся тем же пакетом, подключив middleware в наше express приложение:
Это работает так же, как в примере выше, где мы писали чистый Gateway. В этом примере разница лишь в том, что запросы принимает не Gateway, а монолит, написанный на express.
Node.js и cote: простая и удобная разработка микросервисов
Многие считают, что микросервисы — это очень сложно. На самом же деле, при правильном подходе, это совсем не так.
Микросервисы сегодня весьма популярны, а настоящие приверженцы этой архитектуры едва ли не кланяются всему, на чём написано «микросервис». Однако, если отбросить фанатизм, подобный подход к разработке ПО — это достойный шаг вперёд, микросервисы навсегда могут изменить то, как создают серверные части приложений. Вокруг микросервисов много информационного шума, поэтому стоит выделить по-настоящему важные свойства этой архитектуры и поработать над тем, чтобы упростить её внедрение и использование там, где это действительно нужно.
Если вы относитесь к микросервисам с осторожностью, или чувствуете, что в этой теме запутались, знайте, что вы не одиноки. С архитектурной точки зрения микросервисы устроены не так уж и просто. Дело усугубляется сложившейся вокруг них экосистемой. Вместо того, чтобы напрямую решать сложные задачи, сопутствующие работе с микросервисами, те, кто этим занимаются, пытаются уйти от прямых решений, упрощая одно и усложняя другое. В итоге это приводит к тому, что приходится поддерживать большой набор технологий и иметь дело с ошибками, которые невозможно отлаживать именно из-за сложности всей конструкции. Нелегко даже просто проверить работоспособность приложения. Пришло время эту ситуацию исправить.
Здесь мы пошагово разберём разработку веб-приложения, основанного на микросервисах. Этот пример вполне может быть вашим первым подобным проектом, а если вы разбираетесь в разработке для Node.js, на то, чтобы всё у вас заработало, уйдут считанные минуты.
Прежде чем мы приступим к делу, мне хотелось бы уточнить, что я являюсь автором библиотеки для Node.js cote, которая упрощает и ускоряет разработку приложений, основанных на микросервисах.
Пример реализации приложения, основанного на микросервисах
Существует множество способов демонстрации реализации архитектуры микросервисов, и, на самом деле, основательно проработанный пример — это всё, что нужно опытному разработчику. Однако, этот материал рассчитан на программистов с разным уровнем подготовки, в том числе и на новичков, поэтому для демонстрации был выбран простой, но полноценный пример: приложение для конвертации валют. Мы создадим систему из четырёх сервисов, совместная работа которых позволит организовать конверсию в условиях колебания курсов валют.
Обзор сервисов. Каждый из них может независимо масштабироваться. Стрелки указывают направления потоков данных.
Мы создадим систему, состоящую из следующих частей.
Субъективный взгляд на историю микросервисов
Давайте взглянем в прошлое. Десять лет назад, когда микросервисы ещё и не появились, в почёте была сервис-ориентированная архитектура (SOA, service-oriented architecture). Существовали сотни решений для построения сервис-ориентированных приложений, а вокруг всего этого был построен серьёзный консалтинговый бизнес.
Продвинемся лет на семь ближе к нашему времени, здесь мы уже встретимся с микросервисами. Хотя на фундаментальном уровне они очень сильно отличаются от SOA, те, кто раньше строил сервис-ориентированные приложения, переключились на новую технологию. Всё бы хорошо, но за плечами у этих разработчиков был багаж из прошлого, в котором много лишнего.
В одночасье существующие подходы к разработке были перенесены в новую среду. Хотя основные предпосылки, лежащие в основе микросервисов, отличались от SOA, эти первые решения, основанные на старых технологиях, преподносились общественности как «единственно верные». В результате, кроме прочего, у нас были AMQP, HTTP, или даже, боже упаси, SOAP. Это были nginx, zookeeper, etcd, consul и несколько других решений, которым пытались придать вид инструментов, жизненно необходимых для создания микросервисов.
Проблема со всем этим заключалась в том, что данные технологии изначально создавались для решения совсем других проблем. Их, так сказать, «перепаяли» под микросервисы. Однако, после того, как разработчики использовали некоторые из этих инструментов для построения собственных сервисов, они, в лучшем случае, оставляли ощущение временных подручных средств. Это напоминало забивание гвоздей плоскогубцами. Когда больше ничего под рукой нет — гвоздь забить можно, но не лучше ли поискать нормальный молоток?
Всегда было очевидно, что барьер входа в сферу микросервисов слишком высок, хотя переход на них и сулил экономические выгоды. Однако, за окном 2017-й год, все мы заслуживаем лучшего, чем старые технологии, с помощью которых решают новые задачи. Пришло время заявить, что для того, чтобы изучать, создавать и использовать микросервисы, для того, чтобы добиться их масштабирования при решении реальных проблем, нужен только Node.js.
Теперь поговорим об архитектуре современных микросервисов.
Пять требований к микросервисам
Вот требования, которым должны соответствовать современные системы, основанные на микросервисах.
Это — не микросервисы
Мне хотелось бы, ещё раз подчеркнуть одну важную вещь: архитектура микросервисов не привязана к какой-то определённой технологии. Скажем, старые добрые рабочие очереди и потоки-потребители — это не микросервисы. Почтовые демоны, механизмы уведомлений, любые вспомогательные службы, которые лишь потребляют события и ничего не делают для обработки запросов пользователей — это не микросервисы.
Некое административное приложение и клиентская программа — это разные вещи? Такое разделение тоже не означает применение микросервисной архитектуры. Серверные демоны, которые могут получать и обрабатывать HTTP-запросы… И это не микросервисы. А что, если у нас есть кластер серверов, компьютеры, входящие в который, названы в честь лун Юпитера? Нужно ли администратору вмешиваться в их работу? Если да — то и тут нет никаких микросервисов.
Понятно, что на волне популярности новой технологии заманчиво называть «микросервисными архитектурами» всё подряд. Однако, это лишь создаёт информационный шум и не даёт другим людям понять, что такое микросервисы, а значит и использовать их в своих разработках.
Микросервисы всегда стремились к минимализму. «Тяжёлые» технологии, о которых говорят, что только они делают возможным создание микросервисов — это прямая им противоположность.
Библиотека cote и микросервисы
Микросервисы, построенные на базе библиотеки cote, конфигурируются автоматически. Библиотека использует широковещательные или многоадресные IP-рассылки, в результате демоны в одной сети находят друг друга и автоматически обмениваются необходимой для настройки соединения информацией. В этом отношении cote удовлетворяет требованиям №1 и №5: «Автоматическое конфигурирование системы» и «Автоматическое обнаружение сервисов».
С помощью cote можно весьма эффективно, с малыми затратами ресурсов, создавать множество копий сервисов, при этом обработка запросов масштабируется автоматически. Это значит, то библиотека соответствует и требованию №2: «Высокий уровень избыточности системы».
Если в системе нет сервисов для удовлетворения некоего запроса, cote кэширует его и ждёт до тех пор, пока нужный сервис не окажется доступен. Так как сервисы обычно независимы, подобная организация системы означает её отказоустойчивость, а это соответствует требованию №3: «Отказоустойчивость системы».
Оставшееся требование №4: «Самовосстановление системы», выполняется благодаря использованию Docker, давая возможность перезапускать сервисы при сбоях. Так как в системе работает автоматическое обнаружение сервисов, даже если Docker решит развернуть упавший сервис на новой машине, все оставшиеся сервисы найдут его и будут с ним взаимодействовать.
Таким образом cote даёт разработчику полную свободу в плане инфраструктуры, беря на себя заботу о выполнении основных требований к системам, построенным на базе микросервисов.
С помощью cote вы можете сосредоточиться на самых важных аспектах разработки приложений, оставив библиотеке выполнение вспомогательных задач.
Полагаю, я доступно и понятно рассказал о том, что такое — настоящие микросервисы. Теперь давайте поговорим о том, как всё это реализовать.
▍Установка cote
Мы создадим систему, основанную на микросервисах, в среде Node.js, с помощью библиотеки cote, основные возможности которой мы рассмотрели выше. Она доступна в виде npm-пакета для Node.js.
▍Первое знакомство с cote
Хотите ли вы интегрировать cote с существующим веб-приложением, например, основанным на express.js, как показано здесь, собираетесь ли переписать некоторую часть монолитного приложения, или решили перевести несколько существующих микросервисов на cote, работа будет заключаться в том, чтобы создать несколько экземпляров компонентов cote и использовать их сообразно вашим нуждам. Среди этих компонентов, например — Responder, Requester, Publisher, Subscriber, подробности о них вы узнаете ниже. Эти компоненты рассчитаны на взаимодействие друг с другом, позволяя реализовать наиболее распространённые сценарии разработки приложений.
Простое приложение, или очень маленький микросервис, вполне могут быть построены так, что на один Node.js-процесс будет приходиться реализация одного компонента cote. Однако, более сложные проекты требуют более тесной связи и совместной работы множества компонентов и микросервисов. Библиотека cote поддерживает и такие сценарии.
Реализация механизма запросов и ответов
Наиболее распространённый сценарий взаимодействия компонентов, реализуемый во множестве приложений — это цикл запросов-ответов. Обычно некий микросервис запрашивает выполнение задачи у другого микросервиса, или выполняет к нему запрос и получает от него ответ. Реализуем подобную схему взаимодействия с помощью cote.
Тут ничего особенного не происходит — обычный вызов библиотеки.
▍Создание компонента Requester
Для того, чтобы выполнить этот файл, воспользуйтесь такой командой:
Сейчас выполнение запроса ни к чему полезному не приводит, нет даже логов в консоли, так как в нашей системе пока нет компонента, способного отреагировать на запрос и вернуть что-то в ответ.
▍Создание компонента Responder
Вот как выглядит простая реализация вышеописанного механизма.
Сохраним файл, и, в новом терминале, выполним его с помощью node:
Обратите внимание на то, что мы не настраивали IP-адреса, порты, имена хостов или что угодно другое. А ещё — примите поздравления! Только что вы создали свой первый набор микросервисов.
Теперь, в разных терминалах, вы можете запустить множество копий каждого сервиса и убедиться в том, что всё это отлично работает. Остановите несколько сервисов конверсии, перезапустите их, и вы увидите, что созданная нами система соответствует требованиям к современным микросервисам. Если вы хотите масштабировать проект, развернуть его на нескольких серверах или в нескольких дата-центрах, вы можете либо использовать собственное решение, либо воспользоваться возможностями Docker, который позволяет решать множество задач по управлению инфраструктурой.
Займёмся дальнейшим развитием нашего конвертера валют.
Отслеживание изменений в системе с использованием механизма издатель-подписчик
Одно из преимуществ систем, построенных на базе микросервисов, заключается в том, что в них очень легко реализовать механизмы, которые раньше требовали серьёзных вложений в инфраструктуру. Среди задач, решаемых с помощью подобных механизмов — управление обновлениями и отслеживание изменений в системе. Ранее это требовало, как минимум, инфраструктуры очереди с разветвлением. Подобные вещи нелегко масштабировать, ими сложно управлять, это было одним из ограничивающих факторов развития подобных систем.
Библиотека cote решает такие проблемы совершенно естественным и интуитивно понятным образом.
Предположим, нам нужен арбитражный сервис, который устанавливает курсы валют, и, если произошли изменения, уведомляет все экземпляры сервисов-конвертеров о том, что им надо использовать новые значения курсов.
Самое важное тут — уведомление всех экземпляров сервисов-конвертеров. В высокодоступном приложении, основанном на микросервисах, можно ожидать наличия нескольких одинаковых сервисов, между которыми распределяется нагрузка. Когда происходит обновление курсов валют, все эти сервисы должны быть проинформированы об изменениях. Если бы в приложении был лишь один сервис-конвертер, подобное легко было бы реализовать с помощью механизма запросов-ответов. Но так как мы стремимся к масштабируемой архитектуре, не хотим ограничивать себя в количестве одновременно работающих сервисов, нам нужен механизм, который уведомлял бы каждый из таких сервисов, причём, надо, чтобы все они получали подобные уведомления одновременно. В cote это достижимо с помощью механизма издателей и подписчиков.
▍Создание арбитражного сервиса
Теперь нужен механизм для отслеживания курсов валют в системе. Скажем, они хранятся в локальной переменной в области видимости модуля. Это вполне может быть и база данных, к которой обращается сервис, но, для того, чтобы не усложнять пример, пусть это будет локальная переменная.
▍Создание компонента Publisher
Теперь, при обновлении курсов, надо воспользоваться возможностями этого компонента. В результате обработчик запроса типа update rate надо будет отредактировать так, как показано ниже.
▍Создание компонента Subscriber
Добавим в conversion-service.js следующий код, который позволит прослушивать обновления, которые публикует арбитражный сервис.
Вот и всё. После того, как все наши микросервисы будут запущены, сервисы конверсии будут синхронизироваться с арбитражным сервисом, получая публикуемые им сообщения. Запросы на конверсию, поступающие после обновления курсов, будут выполняться уже с учётом свежих данных.
Только что мы создали три сервиса, совместная работа которых позволила реализовать систему конверсии валют, основанную на микросервисной архитектуре. Вот репозиторий на GitHub, в котором вы можете найти все три микросервиса, которыми мы тут занимались, и сервис для автоматического обновления курсов валют. Если хотите — клонируйте репозиторий и поэкспериментируйте с его содержимым.
Что дальше?
Если тема разработки микросервисов с использованием cote вам интересна, взгляните на репозиторий библиотеки на GitHub, присоединяйтесь к нашему сообществу на Slack. Проект нуждается в активных участниках, поэтому, если вы хотите внести вклад в дело превращения микросервисов в широко распространённый, доступный всем желающим инструмент, дайте нам знать.
Вот ещё один репозиторий, в котором вы можете найти расширенный пример, представляющий собой реализацию простого приложения для электронной коммерции на базе cote. В этом примере, в частности, имеется следующее.
Итоги
В этом материале мы, очень кратко, рассмотрели тему разработки приложений на основе микросервисов. Это — введение в архитектуру микросервисов, общий обзор методики разработки. Однако, хотя приложение, которое мы тут создали, состоит всего из нескольких строк кода, тот же подход можно использовать и на гораздо более масштабных проектах. Надо отметить, что и библиотеку cote мы рассмотрели лишь в общих чертах.
Полагаю, мы находимся на пороге очень интересных времён, когда можно наблюдать изменение подходов к разработке ПО. Я горячо поддерживаю путь упрощения, по которому идёт индустрия веб-разработки. Библиотека cote — один из шагов по этому пути, и, на самом деле, это — только начало. Надеюсь, этот материал помог тем, кто задумывался о микросервисах, но так и не решался внедрить их в свои проекты.
Уважаемые читатели! А вы пользуетесь микросервисами в своих разработках?