Микросервисы... Как много в этом слове. Что это такое и что с этим делать?
Представьте себе ситуацию, когда для решения двух разных проблем используются разные инструменты. Немыслимо, правда? -_-
Так вот микросервисная архитектура подразумевает под собой разбиение системы на небольшие сервисы под определенным срезом, где каждый сервис отвечает за свою часть бизнес-логики и решает определенную проблему. По сути это эскалация принципа SRP на уровень архитектуры системы. Теперь не только компоненты имеют единственную причину для изменения, но и в само приложение вносятся изменения относящиеся к одной части бизнес-процесса.
Зачем одному приложению уметь отсылать почту, обрабатывать изображения, работать с пушами, интегрироваться со сторонними сервисами, если эту логику можно разнести по разным приложениям и скрыть это всё за единым интерфейсом.
Преимущества такого подхода к организации системы:
1. Низкая связанность.
2. Высокое зацепление. Компоненты внутри одного сервиса решают только одну задачу.
3. Независимое развёртывание.
4. Свобода в выборе инструментов. Можно написать сервис аналити на питоне, интеграцию со сторонними сервисами сделать на джаве, а блог на php (для извращенцев).
5. Повышение надёжности. Можно независимо масштабировать только те сервисы, которые имеют большую нагрузку.
Минусы:
1. Сложнее развёртывать. Для каждого микросервиса есть необходимость поднимать отдельные инстансы БД, кэша и т.п.
2. Сложнее поддерживать. Стэк технологий в микросервисах может меняться от сервиса к сервису, что увеличивает стоимость поддержки и добавляет необходимость иметь разработчиков с экспириенсом в разных стэках
3. Больше точек отказа. Т.к. разные задачи требуют разные технологии, то вместо одного приложения и БД на систему, у нас могут быть разные БД для разных микросервисов. И каждая БД - потенциальный источник отказа.
Когда использовать?
Если делаете MVP - если не хотите, чтобы другие разрабы крутили пальцем у виска, когда вы рассказываете о своем микросервисном проекте, в котором кол-во строк конфигов микросервисов суммарно превышает кол-во строк бизнес-логики(если вы не пишите на джава, конечно), то подумайте - оно вам надо?
Для себя я определил следующие звоночки для того, чтобы тащить микросервисы:
1. Нагрузка явно будет больше на опредленую часть приложения и требуется возможность независмо масштабировать эту часть
2. Решение задачи будет быстрее и дешевле сделать с использованием другой технологии/инструментов, чем изобретать велосипед на текущем стэке
3. понты Наличие экспертизы в команде
Про паттерны и конкретную имплементацию поговорим в другой раз.
