Народ, пятница? Небось сидите с друзьями где-то и на @jsunderhood вам наплевать? А мы обсудим микросервисы, как я и обещал
Похоже на правду?
2000 - бум сервисов CORBA и COM на C++
2005 - SOAP и SOA в Java
2010 - REST в Ruby on Rails
2015 - микросервисы на Node/Go
Так можно использовать те же инструменты мониторинга и развертывания не для всей системы, а для каждого компонента отдельно.
Например память. Если все в одном процессе, то понять, какая часть приложения “течет”, сложно.
с др. стороны: у нас есть цепочка боксов, выполняющая задачу. Ответ системы приходит медленно. Бывает сложно понять, какой из боксов виноват
У меня есть подозрение, что есть граница, после которой дробить сервисы уже не имеет смысла. Насколько “микро” должны быть микросервисы?
Например: регистрация пользователей.
Приняли форму и послали письмо
Приняли get из письма и активировали аккаунт.
Один сервис? 2? 3?
Или сервис “управление пользователями”, который логинит, регистрирует, роли меняет и все такое?
Если послушать доклады по микросервисам года 2012-2013 от нодеров, то окажется, что они определенно говорили о варианте с 2мя сервисами
с обработчиком формы и активатором
мы описываем use cases цепочкой шагов. каждый шаг - микросервис. кода строк на 50-200
“Микросервисы - это не про вынос отдельных таблиц из БД в виде отдельных сервисов...Думайте не о данных (БД), а о функциональности (сервис)"
“стройте архитектуру микросервисов так, что большинство новых фич можно было добавлять в виде отдельных сервисов"