Как стать автором
Обновить

Комментарии 4

Пе примите пожалуйста этот коммент на свой счет. У меня вопрос скорее ко всем кто может на него ответить нежели к автору статьи. Насколько буквально нужно воспринимать словосочетание "одна функция" в определении что является и что не является микросервисом?
Я например предпочитаю воспринимать буквально одна функция это function(){}
В противном случае можно facebook.com назвать микросервисом т.к. он выполняет одну функцию — реализровать ПО соцсети для клиентов и ФСБ (хотя это уже две функции)


Не является разделение монолита на несколько монолитов разделением на несколько мнонолитов а не на несколько микросервисов?

Желательно сильно не буквально. На мой взгляд цель создания «микросервисной архитектуры» в том, чтобы в будущем делать изменения и масштабирование системы удобно и с минимальным влиянием на остальные части.

Нам же не нужен микросервис ради микросервиса: переход должен нести какую-то ценность, а не просто удовлетворять каким-то там требованиям по определению.

Например: поиск, изменение и создание клиентской записи. Вполне логично, что их можно разделить на три сервиса, но с другой стороны, чем больше сервисов, тем больше нужно заботиться о модели хранения данных и нужно больше контроля за ними. А если заранее известно, что запросов на создание и изменение будет мало, то проще все три сделать в одном модуле и просто поднять приоритет операциям «создание/изменение» (если это вообще требуется).

Итого: всё зависит от задачи.

А получим ли мы выгоды от микросервиса если не будет все доведено до передельного состояния то есть одна function === один микросервис?


Микросервисная архитектура она же требует наличие спеицальной инфраструктуры такой например как cubernetes иначе мы не сможем уследить за работоспособностью всех микросервисов, и получать выгоды от масштабирования.


Вторая часть необходимой инфораструктуры это некая жутко масштабируемая база данных типа PostgreSQL в реализации DigitalOcean — к которой мы сможем обращаться с любого микросервиса как к источнику истины.


Если мы начинаем "разумно" делить на несколько глыб наш монолит — то не поучаем ли мы все негативы от микросервисов (заключающиеся в необходимости специальной инфраструктуры) вместе с тем теряя преимущества монолита? То есть не берем ли мы при этом все недостатки микросервисов и монолитов, и не выбрасываем ли мы все их положительные стороны?

Да, получим. Я не готов обсуждать «в общем случае», но в частном — совершенно точно и даже примеры есть (можно прямо мой выше).

Нет, микросервисы не требуют кубернетеса. И даже не факт, что там будет удобнее. Мониторинг и авто[ДО]запуск можно без проблем реализовать и без кубернетеса.

Ну а «разумность» деления, как и всё прочее, по-прежнему опирается на разумность(опыт?) тех, кто это решает. В целом и как в монолите ранее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий