Comments 15
За «котэ» прям сразу лайк! Если серьезно, в Node.js я лютейший новичок, сейчас пытаюсь изучить его для самостоятельного написания сервисов для своих мобильных приложений, поэтому материал для меня жутко интересный. Думаю, что принцип разработки спокойно перекладывается и на TypeScript/Coffee, тут кому что больше нравится, но вот про котэ-библиотеку надо почитать подробнее, какие именно возможности она дает. Спасибо за статью!
Не силен в микросервесах, да и в бекенде тоже… Но разве микросервисы не подразумевают, что любой микросервис в системе может быть написан на любой технологии и языке? И пока нет реализции cote на других языках и платформах, использовать его для создания большой системы будет проблематично?
А в целом за статью спасибо. Интересно
А в целом за статью спасибо. Интересно
Очень похоже на http://senecajs.org/ — есть информация о том, что лучше/хуже?
Спасибо, открыл для себя котЭков :-) Вызвало некоторые ассоциации с вот этим
Решил погонять, хотел ради эксперимента связать SocketCluster (принимает нагрузку от фронтенда + аутентификация + "роутинг" к микросервисам и обратно) + cote (собственно, куча всяких микросервисов, которые по котэвски общаются между собой), но… с горяча что-то не заводится, ск воркеры падают при попытке что-нибудь сделать с котэ (например, запаблишить в котэ при новом подключении к СК). Разбираться где я накосячил с СК лень, котэкодить понравилось. В общем, буду присматриваться.
Сам микросервисы "пользую". Если говорить о технологиях, то у меня джентельменский набор состоит из Docker, NATS / NSQ, Socketcluster, Traefik, Go / Node.
PS: тру микросервисы на ноде :-)
Зачем лепить микросервисы во все поля?
Это же просто очередной buzzword…
Это же просто очередной buzzword…
Не нашел ни строчки про согласованность данных в этой платформе. Мне показалось что ее нет (смотрю в исходниках и ничего такого) и автор предполагает что все сервисы будут иметь актуальные данные сами собой. Вот как он сделал на распределенной системе, без консенсуса, проведение оплаты https://github.com/dashersw/cote-workshop/blob/master/services/payment-service.js Атакуем систему сотней запросов на покупку товара за 5$. Все микросервисы «payment» распределят нагрузку и получат запрос на проведение оплаты, каждый запросит мой баланс 100$ и каждый сделает списание 100$ — 5$ перетерев результаты другого. В итоге я имею 100 товаров, купленных за 5$, вместо 500$ (утрирую, но примерно так и будет)
Нет, так не будет, ибо точка истинности в платёжной системе находится не в микросервисах, а в транзакционном персистентном хранилище. Грубо говоря, только один сервис вернёт ОК, а другие вернут сообщение об ошибке. Микросервисность не отменяет программирования непротиворечивой бизнес-логики.
В нашем случае в исходниках видно что хранилище postgresql, т.е. транзакционное персистентное хранилище. И как это хранилище убережет нас от такой атаки? Никак. Защита от такой атаки либо журнал, либо stateful подход, либо консенсус между всему нодами, так мы получим согласованные данные. А решение этой защиты лежит на вышеупомянутых «зло» продуктах zookeeper, etcd, consul (apache ignite, cassandra и тд) против которых настроен автор.
К чему я: автор написал peer2peer месенджер с автопоиском пиров и не более. А статья преподносится будто это панацея какая-то: «отказываемся от всего, используем мое решение».
К чему я: автор написал peer2peer месенджер с автопоиском пиров и не более. А статья преподносится будто это панацея какая-то: «отказываемся от всего, используем мое решение».
> И как это хранилище убережет нас от такой атаки? Никак.
Почему никак? Любая транзакция о покупке товара будет гарантировать, что деньги списаны, а товар начислен (или ошибку в случае невозможности это сделать).
> Защита от такой атаки либо журнал, либо stateful подход, либо консенсус между всему нодами, так мы получим согласованные данные.
В чём заключается «атака»? Если пользователь послал 100 запросов на покупку товаров, то именно 100 раз мы и должны попытаться осуществить интересующую его операцию, разве нет? «Stateful подход» и «конценсус» в данном случае и заключается в том, что мы обращаемся к состоянию персистентного хранилища для выполнения операции, изолируя её SQL-транзакцией (а в более сложных системах могут пригодиться сервисы распределённых транзакций, например).
Почему никак? Любая транзакция о покупке товара будет гарантировать, что деньги списаны, а товар начислен (или ошибку в случае невозможности это сделать).
> Защита от такой атаки либо журнал, либо stateful подход, либо консенсус между всему нодами, так мы получим согласованные данные.
В чём заключается «атака»? Если пользователь послал 100 запросов на покупку товаров, то именно 100 раз мы и должны попытаться осуществить интересующую его операцию, разве нет? «Stateful подход» и «конценсус» в данном случае и заключается в том, что мы обращаемся к состоянию персистентного хранилища для выполнения операции, изолируя её SQL-транзакцией (а в более сложных системах могут пригодиться сервисы распределённых транзакций, например).
Если пользователь послал 100 запросов на покупку товаров, то именно 100 раз мы и должны попытаться осуществить интересующую его операцию, разве нет
Именно что должны, но cote этого архитектурно не может предоставить. Эта библиотека сделает именно как я описал.
Почему никак?
Вы точно исходники смотрели? Я говорю о коде который написал автор и который не работает. Там очень небольшой объем кода. Там из базы происходит чтение баланса в память и операция проводится над числом в памяти. Потом базе отдается число на запись.
> Именно что должны, но cote этого архитектурно не может предоставить. Эта библиотека сделает именно как я описал.
Эта библиотека не об этом вообще. Транзакционность перпендикулярна микросервисности.
> Вы точно исходники смотрели?
Нет, не смотрел. Думаю, это просто концептуальный пример (да, получается, что кривоватый, если чтение, обработка и запись данных в БД выполняются не в рамках одной SQL-транзакции).
Эта библиотека не об этом вообще. Транзакционность перпендикулярна микросервисности.
> Вы точно исходники смотрели?
Нет, не смотрел. Думаю, это просто концептуальный пример (да, получается, что кривоватый, если чтение, обработка и запись данных в БД выполняются не в рамках одной SQL-транзакции).
Sign up to leave a comment.
Node.js и cote: простая и удобная разработка микросервисов