1) Если речь идет о новой реализации существующего функционала, то конечно!
2) Возможность постепенного перехода является одним из плюсов этой идеи :)
3) Судя по комментариям, очень многие несогласны, что сама идея микросервисов хорошая. Не рано ли им предлагать переход? :) Создается впечатление, что людям пока надо слышать доводы в пользу. Даже если взять глобальную сцену IT, крупных проектов, которые приняли парадигму – намного менее половины (если судить по публичным источникам)
А если один микросервис решил мигрировать схему БД немного? Если вам из-за этого придется что-то менять в остальных – это, вроде как, нарушает всю идею и лишает плюсов
У каждого микросервиса должно быть отдельное хранилище, это как раз одно из преимуществ архитектуры (можно под конкретные данные выбрать конкретный вид sql/nosql базы)
В обществе разработчиков именно так традиционно противопоставляется. Вы правы насчет сетевого уровня, правда обычно его более низким, а не высоким считают (взять ту же модель OSI). Какую выгоду это дает — будет в одной из следующих статей, это очень, очень важное преимущество для high availability или high load систем
— 1мс — это очень даже низкая задержка, учитывай что голое приложение с микро-фреймворком может 20+ мс занимать. В целом в мире ответ API в 100-150мс считается ризонно быстрым
— Можно полностью положится на облачных провайдеров, очереди и сообщения обычно стоят очень недорого.
1) Самые распространенные способы — это http (REST) или очереди/сообщения (tcp/udp/web)
2) Как правило создается некий реестр сервисов по типу, из которого можно всегда адрес живого инстанса (экземпляра) сервиса взять. Популярное бесплатное ПО — consul.
В Docker Cloud создается внутренняя сеть автоматически между всеми сервисами, достаточно друг друга по хостнейму стучать.
В AWS можно на мониторинг и Route53 достаточно просто привязать
У Netflix 600+ микросервисов — это ок.
Если у вас миллион пользователей, то перевести 200 классов в 200 сервисов — может быть вполне разумной идеей.
До перехода, в независимости от нагрузки, каждому классу «нужны» будут остальные 199 — остальные 199 деплоятся вместе и находятся в ОЗУ вместе. После перехода на микросервисы, у 2 классов может быть по 100 «инстансов», а у остальных 198 всего по одному (потому что они проще).
1) Развертывание один раз настраивается и редко меняется, обычно. Зато развертывание изолированное — по частям, что безопаснее (вся система не рухнет из-за одного элемента)
2) Время ops зачастую дешевле времени разработчиков стоит, да и ops обычно меньше в штате :)
3) А какие сложности с управлением версиями?
Ну, взять вот даже эту картинку — одна какашка и 5 какашек. Что легче зарефакторить? Что будет меньше потенциальных сбоев во время рефакторинга давать? (деплои 1/5 системы или каждый раз деплой всей системы)
Даже если код одинаково плохим остается — когда он порезан на куски, с ним легче справляться и его проще рефакторить
А временные затраты на общение сервисов не такое большое — все библиотеки и провайдеры предоставляют SDK. Во многих фреймворках с ходу включены клиенты вроде AWS SQS или IronMQ
Нет, сейчас нет. Если будут многочисленные запросы — добавим :) Отмечу, что большинство таких слов непереводимо — такие названия как правило есть только внутри страны на родном языке.
Модульные приложения в рамках конкретной этой статьи — вероятно да, не так сильно и отличаются от микросервисов. Но по факторам из последующих статей — разница большая (отдельный деплой, возможность разделения на уровне сети, масштабирование только нагруженных элементов и тд)
Микросервисы особенно эффективны в условиях high load — поэтому на них и перешли сайты с высокой нагрузкой вроде Netflix и Amazon. Расход на RESTful или очереди ничтожен, зато масштабировать конкретный сервис (который создает нагрузку) намного эффективнее, чем масштабировать весь монолит (включая ненужные части)
Представьте, что делаете сайт вроде YouTube. Естественно предположить, что на транскодинг файлов будет больше всего ресурсов уходить — логично иметь намного больше инстансов (копий) микросервиса по транскодингу, чем скажем API комментариев. Микросервисы тут идеально вписываются
Я ждал этого вопроса :) Так как уже есть поддержка разных стандартов, планируется просто добавить еще один — что-то вроде «дефакто» деления. Так как официальных кодов в этом случае не будет, придется скорее всего какие-то свои уникальные идентификаторы использовать
Сервисы не должны работать напрямую с таблицей юзеров — от API gateway передается только сам факт успешной аутентификации и немного дополнительных полей (scopes/права, ID юзера).
Если необходимо реализовать свою (для конкретного сервиса) авторизацию — традиционно нужна _отдельная_ база данных. Это основа философии — один сервис не должен задевать другой, все должно деплоиться по-отдельности без проблем.
Если данные о пользователе используются более чем 1-2 сервисами — их можно хранить в общей базе (которую можно держать «при» API gateway), если данные нужны конкретному сервису — в его местной базе.
2) Возможность постепенного перехода является одним из плюсов этой идеи :)
3) Судя по комментариям, очень многие несогласны, что сама идея микросервисов хорошая. Не рано ли им предлагать переход? :) Создается впечатление, что людям пока надо слышать доводы в пользу. Даже если взять глобальную сцену IT, крупных проектов, которые приняли парадигму – намного менее половины (если судить по публичным источникам)
Весь startup-мир глумится над PHP, jQuery и MySQL, а один из самых успешных проектов десятилетия Slack сделан на них :)
PS. Сложно себе представляю реализацию большого проекта на jQuery, но факт есть факт
— Можно полностью положится на облачных провайдеров, очереди и сообщения обычно стоят очень недорого.
2) Как правило создается некий реестр сервисов по типу, из которого можно всегда адрес живого инстанса (экземпляра) сервиса взять. Популярное бесплатное ПО — consul.
В Docker Cloud создается внутренняя сеть автоматически между всеми сервисами, достаточно друг друга по хостнейму стучать.
В AWS можно на мониторинг и Route53 достаточно просто привязать
Если у вас миллион пользователей, то перевести 200 классов в 200 сервисов — может быть вполне разумной идеей.
До перехода, в независимости от нагрузки, каждому классу «нужны» будут остальные 199 — остальные 199 деплоятся вместе и находятся в ОЗУ вместе. После перехода на микросервисы, у 2 классов может быть по 100 «инстансов», а у остальных 198 всего по одному (потому что они проще).
Конечно, это относится как правило в коллекции back-end сервисов
2) Время ops зачастую дешевле времени разработчиков стоит, да и ops обычно меньше в штате :)
3) А какие сложности с управлением версиями?
Даже если код одинаково плохим остается — когда он порезан на куски, с ним легче справляться и его проще рефакторить
А временные затраты на общение сервисов не такое большое — все библиотеки и провайдеры предоставляют SDK. Во многих фреймворках с ходу включены клиенты вроде AWS SQS или IronMQ
Представьте, что делаете сайт вроде YouTube. Естественно предположить, что на транскодинг файлов будет больше всего ресурсов уходить — логично иметь намного больше инстансов (копий) микросервиса по транскодингу, чем скажем API комментариев. Микросервисы тут идеально вписываются
Сайт хостится на AWS S3, это просто набор статических HTML (Gatsby) — там нечему падать особо :)
Если необходимо реализовать свою (для конкретного сервиса) авторизацию — традиционно нужна _отдельная_ база данных. Это основа философии — один сервис не должен задевать другой, все должно деплоиться по-отдельности без проблем.
Если данные о пользователе используются более чем 1-2 сервисами — их можно хранить в общей базе (которую можно держать «при» API gateway), если данные нужны конкретному сервису — в его местной базе.