Комментарии 16
Статья ради статьи (рекламы хостинга). Опоздали с ней годика на 2-3
побуду немного адвокатом дьявола, микросервисы усложняют архитектуру приложения, она должна быть ассинхронна, за всем этим надо следить, усложняется мониторинг. Скорость работы падает, потому что все по разным местам, за всем этим надо ходить, забирать, ждать, собирать, объединять, формировать и т.п. в итоге серверов надо больше, мониторинга больше, обслуживать все это сложнее, в замен что? программная архитектура тоже становится сложнее. Куча новых инструментов, меняется способ программирования, как бы владельцы облачных решений не пели песни, что все будет просто и легко, это все становится сложнее чем можно было бы написать в обычном монолите. Потому что у тебя тут все синхронно и просто.
Но да, свои плюсы у микросервисов конечно же есть. Но не все так просто как «рассказывается» в маркетинговых статьях на эту тему.
Но да, свои плюсы у микросервисов конечно же есть. Но не все так просто как «рассказывается» в маркетинговых статьях на эту тему.
На мой взгляд, больш`ая часть сложности микросервисов возникает из потребности в распределенных транзакциях, если возможно разработать такую архитектуру, в которой нет в них необходимости, то для большого проекта, над которым трудится множество разработчиков, микросервисная архитектура снижает сложность, дает больше свободы, а главное позволяет поддерживать команды маленькими и эффективными.
Приходилось что-то подобное делать. Правда, не было гарантии что на сайте отображается реальное наличие, гарантированная проверка остатков производилась при резервировании в момент заказа. Бизнес устроил такой компромисс.
Еще одно такое же маркетинговое бла-бла.
А как это без микросервисов реализовать?
Берёте и реализуете. Но это, конечно, свой код надо иметь, а не на поделиях от 1С побираться.
Вода не несущая смысловой нагрузки, слегка разбавленная сомнительными или откровенно ложными утверждениями.
Под каждой второй фразой хочется добавить комментарий, «нет».
Феерический продукт маркетингового графоманства.
Под каждой второй фразой хочется добавить комментарий, «нет».
Феерический продукт маркетингового графоманства.
Однажды я устроился работать в компанию, чтобы пилить продукт с кучей микросервисов. Дублирование кода в различных сервисах, усложнение запуска продукта, усложнение отладки продукта целиком, снижение скорости работы т.к. много чего общается между собой по http. Вот те минусы, которые надо сразу как-то решать при микросервисной архитектуре.
Выделение какой либо части отдельно должно нести практический смысл, как например СУБД-сервер-клиент — здесь каждая отдельная часть обоснована практическими соображениями, где профит получаемой выгоды существенно перевешивает накладные расходы от усложнения взаимодействия между частями.
Отдельная СУБД — выгода в том что ее разработкой занимается кто то другой.
Отдельно клиент — выгода в том что мы получаем многопользовательскую версию софта.
и т.п. к примеру написали механизм модов-аддонов, и вот к твоему продукту куча энтузиастов может делать моды, плагины, дополнения самостоятельно. Это ведь тоже микросервисы.
Те же dll библиотеки в системе, несут идею что их можно использовать в разных приложениях.
То есть вот когда решается что мы хотим выделить что то отдельно то нужно ответить на вопрос «что бы что»?
Если делить все на микросервисы ради идеи, то так, извините, как в известном анекдоте — можно и «до мышей до***ться».
Отдельная СУБД — выгода в том что ее разработкой занимается кто то другой.
Отдельно клиент — выгода в том что мы получаем многопользовательскую версию софта.
и т.п. к примеру написали механизм модов-аддонов, и вот к твоему продукту куча энтузиастов может делать моды, плагины, дополнения самостоятельно. Это ведь тоже микросервисы.
Те же dll библиотеки в системе, несут идею что их можно использовать в разных приложениях.
То есть вот когда решается что мы хотим выделить что то отдельно то нужно ответить на вопрос «что бы что»?
Если делить все на микросервисы ради идеи, то так, извините, как в известном анекдоте — можно и «до мышей до***ться».
Даже для того чтобы разработкой занимался кто-то другой не нужен отдельный сервис. Кто-то другой может заниматься разработкой библиотеки, которая будет линковаться в монолитный бинарник.
В моей практике отдельный сервис был нужен только один раз, чтобы понять где течет память. Когда починили утечку мы, конечно же, вернули базу данных назад в монолит, потому что так быстрее. И все равно, этого же можно было достичь хорошим профайлером.
В моей практике отдельный сервис был нужен только один раз, чтобы понять где течет память. Когда починили утечку мы, конечно же, вернули базу данных назад в монолит, потому что так быстрее. И все равно, этого же можно было достичь хорошим профайлером.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микросервисы: почему это не панацея?