Node.js и cote: простая и удобная разработка микросервисов

[GDXRepo]

За «котэ» прям сразу лайк! Если серьезно, в Node.js я лютейший новичок, сейчас пытаюсь изучить его для самостоятельного написания сервисов для своих мобильных приложений, поэтому материал для меня жутко интересный. Думаю, что принцип разработки спокойно перекладывается и на TypeScript/Coffee, тут кому что больше нравится, но вот про котэ-библиотеку надо почитать подробнее, какие именно возможности она дает. Спасибо за статью!

[ElianL]

Не силен в микросервесах, да и в бекенде тоже… Но разве микросервисы не подразумевают, что любой микросервис в системе может быть написан на любой технологии и языке? И пока нет реализции cote на других языках и платформах, использовать его для создания большой системы будет проблематично?

А в целом за статью спасибо. Интересно

[YuryZakharov]

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

Подразумевают. Но не обязаны.

использовать его для создания большой системы будет проблематично?

Нет, если не ставить себе хипстерских целей.

[dos]

Очень похоже на http://senecajs.org/ — есть информация о том, что лучше/хуже?

[mytz]

Спасибо, открыл для себя котЭков :-) Вызвало некоторые ассоциации с вот этим

Решил погонять, хотел ради эксперимента связать SocketCluster (принимает нагрузку от фронтенда + аутентификация + "роутинг" к микросервисам и обратно) + cote (собственно, куча всяких микросервисов, которые по котэвски общаются между собой), но… с горяча что-то не заводится, ск воркеры падают при попытке что-нибудь сделать с котэ (например, запаблишить в котэ при новом подключении к СК). Разбираться где я накосячил с СК лень, котэкодить понравилось. В общем, буду присматриваться.

Сам микросервисы "пользую". Если говорить о технологиях, то у меня джентельменский набор состоит из Docker, NATS / NSQ, Socketcluster, Traefik, Go / Node.

PS: тру микросервисы на ноде :-)

[Movimento5Litri]

Зачем лепить микросервисы во все поля?
Это же просто очередной buzzword…

[napa3um]

Это инструмент для конкретных задач (точнее, конкретных требований к решению). Во все поля, конечно, не нужно, но там, где нужно — без них не получится (точнее, по естественным причинам решение выльется в микросервисную архитектуру, даже если архитектор не знал таких слов).

[freeart]

Не нашел ни строчки про согласованность данных в этой платформе. Мне показалось что ее нет (смотрю в исходниках и ничего такого) и автор предполагает что все сервисы будут иметь актуальные данные сами собой. Вот как он сделал на распределенной системе, без консенсуса, проведение оплаты https://github.com/dashersw/cote-workshop/blob/master/services/payment-service.js Атакуем систему сотней запросов на покупку товара за 5$. Все микросервисы «payment» распределят нагрузку и получат запрос на проведение оплаты, каждый запросит мой баланс 100$ и каждый сделает списание 100$ — 5$ перетерев результаты другого. В итоге я имею 100 товаров, купленных за 5$, вместо 500$ (утрирую, но примерно так и будет)

[napa3um]

Нет, так не будет, ибо точка истинности в платёжной системе находится не в микросервисах, а в транзакционном персистентном хранилище. Грубо говоря, только один сервис вернёт ОК, а другие вернут сообщение об ошибке. Микросервисность не отменяет программирования непротиворечивой бизнес-логики.

[freeart]

В нашем случае в исходниках видно что хранилище postgresql, т.е. транзакционное персистентное хранилище. И как это хранилище убережет нас от такой атаки? Никак. Защита от такой атаки либо журнал, либо stateful подход, либо консенсус между всему нодами, так мы получим согласованные данные. А решение этой защиты лежит на вышеупомянутых «зло» продуктах zookeeper, etcd, consul (apache ignite, cassandra и тд) против которых настроен автор.
К чему я: автор написал peer2peer месенджер с автопоиском пиров и не более. А статья преподносится будто это панацея какая-то: «отказываемся от всего, используем мое решение».

[napa3um]

> И как это хранилище убережет нас от такой атаки? Никак.

Почему никак? Любая транзакция о покупке товара будет гарантировать, что деньги списаны, а товар начислен (или ошибку в случае невозможности это сделать).

> Защита от такой атаки либо журнал, либо stateful подход, либо консенсус между всему нодами, так мы получим согласованные данные.

В чём заключается «атака»? Если пользователь послал 100 запросов на покупку товаров, то именно 100 раз мы и должны попытаться осуществить интересующую его операцию, разве нет? «Stateful подход» и «конценсус» в данном случае и заключается в том, что мы обращаемся к состоянию персистентного хранилища для выполнения операции, изолируя её SQL-транзакцией (а в более сложных системах могут пригодиться сервисы распределённых транзакций, например).

[freeart]

Если пользователь послал 100 запросов на покупку товаров, то именно 100 раз мы и должны попытаться осуществить интересующую его операцию, разве нет

Именно что должны, но cote этого архитектурно не может предоставить. Эта библиотека сделает именно как я описал.

Почему никак?

Вы точно исходники смотрели? Я говорю о коде который написал автор и который не работает. Там очень небольшой объем кода. Там из базы происходит чтение баланса в память и операция проводится над числом в памяти. Потом базе отдается число на запись.

[napa3um]

> Именно что должны, но cote этого архитектурно не может предоставить. Эта библиотека сделает именно как я описал.

Эта библиотека не об этом вообще. Транзакционность перпендикулярна микросервисности.

> Вы точно исходники смотрели?

Нет, не смотрел. Думаю, это просто концептуальный пример (да, получается, что кривоватый, если чтение, обработка и запись данных в БД выполняются не в рамках одной SQL-транзакции).

[freeart]

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

и ссылка именно на этот код. Для меня «основательно проработанный пример» что-то да значит.

[napa3um]

Да, с такой претензией спорить сложно :).