Микросервисы / распределенные системы

Пошел удивительный тренд (впервые был замечен на хабре), что микросервисы – это не распределенная система (а земля, видимо, все-таки плоская). Достаточно взять определение Таненбаума: «Распределенная система — это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой. В этом определении оговариваются два момента. Первый относится к аппара­туре: все машины автономны. Второй касается программного обеспечения: поль­зователи думают, что имеют дело с единой системой.»

Если так подумать, то у нас сейчас практически любая система – распределенная система :)

Но что касается микросервисов, – это не просто распределенная система, у этого архитектурного стиля есть ряд важных особенностей, а именно в микросервисном архитектурном стиле должна быть обеспечена:
- Независимость на уровне моделей предметных областей, что дает независимое, но в то же время полное понимание отдельно взятого микросервиса
- Возможность одновременного сосуществование нескольких версий одного сервиса
- Независимое эволюционное развитие за счет сокрытия внутренней реализации (независимая реализация, независимое развертываение, независимое тестирование, независимая возможность выбора используемых технологий)
- Изоляция сбоев на уровне отдельных микросервисов
- При необходимости –  изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов

Это свойства микросервисного архитектурного стиля, если какие-то свойства не заложены, то это не микросервисный архитектурный стиль. Поэтому, когда вам говорят или вы слышите на конференциях, что «один микросервис упал и все сломалось», «сложно провести полный регресс всех микросервисов», «необходимость внесения изменений во всех микросервисах для реализации одной фичи приводит к тому, что нельзя зарелизить ничего, пока все не сделают», – это про какой-то другой архитектурный стиль и на самом деле такие выступления в большей степени указывают не на недостатки микросервисов, а на то, что пишут или рассказывают про что-то другое.

Это равнозначно, что сказать - борщ - это фигня и рассказывать про вермишелевый суп. Вроде суп, но ведь не тот же :)

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

Не бывает правильных или неправильных архитектурных решений, бывают подходящие и не подходящие и если пихать везде что-то из-за хайпа, то где-то оно покажет хороший результат, но это будет, скорее случайность, чем осознанный выбор.

👍36❤1👏1

www.tgoop.com/microservices_arch/473

2.35K viewsSergey Baranov, edited  Sep 17, 2023 at 15:47

Пошел удивительный тренд (впервые был замечен на хабре), что микросервисы – это не распределенная система (а земля, видимо, все-таки плоская). Достаточно взять определение Таненбаума: «Распределенная система — это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой. В этом определении оговариваются два момента. Первый относится к аппара­туре: все машины автономны. Второй касается программного обеспечения: поль­зователи думают, что имеют дело с единой системой.»

Если так подумать, то у нас сейчас практически любая система – распределенная система :)

Но что касается микросервисов, – это не просто распределенная система, у этого архитектурного стиля есть ряд важных особенностей, а именно в микросервисном архитектурном стиле должна быть обеспечена:
- Независимость на уровне моделей предметных областей, что дает независимое, но в то же время полное понимание отдельно взятого микросервиса
- Возможность одновременного сосуществование нескольких версий одного сервиса
- Независимое эволюционное развитие за счет сокрытия внутренней реализации (независимая реализация, независимое развертываение, независимое тестирование, независимая возможность выбора используемых технологий)
- Изоляция сбоев на уровне отдельных микросервисов
- При необходимости –  изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов

Это свойства микросервисного архитектурного стиля, если какие-то свойства не заложены, то это не микросервисный архитектурный стиль. Поэтому, когда вам говорят или вы слышите на конференциях, что «один микросервис упал и все сломалось», «сложно провести полный регресс всех микросервисов», «необходимость внесения изменений во всех микросервисах для реализации одной фичи приводит к тому, что нельзя зарелизить ничего, пока все не сделают», – это про какой-то другой архитектурный стиль и на самом деле такие выступления в большей степени указывают не на недостатки микросервисов, а на то, что пишут или рассказывают про что-то другое.

Это равнозначно, что сказать - борщ - это фигня и рассказывать про вермишелевый суп. Вроде суп, но ведь не тот же :)

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

Не бывает правильных или неправильных архитектурных решений, бывают подходящие и не подходящие и если пихать везде что-то из-за хайпа, то где-то оно покажет хороший результат, но это будет, скорее случайность, чем осознанный выбор.

BY Микросервисы / распределенные системы