Микросервисы - не используй их, пока...
Пару лет назад сделал для себя помтку, что микросервисы - это не архитектура, а всего лишь подход к организации компонентов приложения. Там кстатие есть схема, которая должна помочь понять, а нужно ли вам примянять микросервисный подход.
И читая профильную литературу не один раз сталкивался с примерами избыточного и неуместного использования микросервисного подхода.
Итак вот что еще удалось прочитать.
"Вам не нужна микросервисная архитектура" опубликовано 2017-05-25
Статья написана с позиции "адвоката дьявола" и о главных проблемах этого подхода.
Самое главное:
1) сложность, которая содержалась в большом и тяжелом монолитном приложении, никуда не ушла в тот момент, когда мы упростили код и вычленили всю логику в отдельные компоненты - теперь вся сложность, от которой мы избавились, прячется в зазоре между нашими сервисами - в том как они коммуницируют, как разворачиваются, как реагируют на изменения, и в других аспектах. Не стоит начинать новый проект с этого - за сиюминутный выигрыш в простоте кода, позднее придет расплата, которая может оказаться вам не по карману, если вы недостаточно опытны.
2) Если вы маленькая команда, и только начинаете, то - пишите обычные приложения - вам нужно бизнес развивать / удовлетворять, а не упражняться в элегантных архитектурах - если выживете, появится возможность какие-то фрагменты переписать “как надо”, а если вы вместо полезных фич будете всю дорогу бороться с инфраструктурными проблемами, то такого шанса может и не представиться.
3) Хотите иметь возможность переходить к сервисным архитектурам? Структурируйте внутреннее устройство вашего приложения, разбивайте его на компоненты, вычленяйте хорошие интерфейсы, библиотечные модули. См. архитектура на компонентах
Что стоит запомнить:
1) (Микро)Сервисы - это дорого не только с точки зрения самой разработки, как проектирования и написания кода - дорого с точки зрения поддержки, эксплуатации и отладки, внесения изменений. Настолько дорого, что процесс такой разработки может разорить небольшую компанию, или начинающий стартап.
2) Проблема 1 - еще одна точка отказа "Сеть" и дополнительная обработка сетевых ошибок (дополнительные ситуации о которых вы могли забыть или даже не знать). В вашу жизь войдут все категории сетевых проблем. Факт того, что все работает сегодня, совершенно не гарантирует, что оно так же будет работать завтра, если у вас нет полного контроля над сетью и тем, что в ней происходит (особенное если это в "облаках").
3) Проблема 2 - обработока удаленного вызова, это не тоже самое, что локальный вызов процедуры. Вот возникла у вас проблема при вызове, и что делать повторить вызов? А если вызов приводит к куче побочных эффектов в других сервисах, выставлению счетов и отправке уведомлений? Предстоит попотеть, чтобы после каждого такого эксцесса выяснить, что уже запущено в работу, а что нет и действовать исходя из полученной инфомации.
4) Проблема 3 - сложное и непредсказуемое интеграционное тестирование. Данные могут идти по цепочке сервисов, и по отдельности модульные тесты каждого сервиса проходят. Например сервис А получает данные от Б, а тот от В. Сервис Б умеет понимать разные форматы от В и отдавать результат вам в А. Тут вдруго поменяли форматы в В, тест пары Б-В проходит на тестовых данных, Б-А тоже проходит, то при прогоне А-Б-В тест не идет! А: не может обработать данные от Б полученные от В в новом формате. А не менялся, Б не менялся, но все сломалось. Решением может быть запуск всего набора сервисов и сквозного прогона типовых сценариев (это долго проводит и настраивать тоже). И В итоге запуская все вместе мы опять получили одно очень большое приложение...
5) Проблема 4 - развертывание усложняется, зависимости тоже. DevOPS инженеру придется несладно настраивая запуск нужных версий сервисов (особенно если у ваших протоколов нет версионности). Несколько версий сервится предьявляют взаимоисключающие требования к структуре БД с которой они работают - упс! Еще проблема.
6) Проблема 5 - мониторинг, сбор и анализ логов усложняется. Несколько экземпляров сервисов на разных машинах с разной аппаратной частью. Логи надо хранить централизовано, а если транспорт отказал, то складывать локально, а еще следить за доступностью сервисов (хранить результаты healthcheck в разные момоенты времени, чтобы знать кто был недоступен)
7) Проблема 6 - много точек входа API и на каждую свое описание, версионирование, авторизация, валидация и прочее...В одном приложении у вас одна точка публикации API и поддерживать нужно одну (ну две...позже).
8) Проблема 7 - разные люди проектируют API по разному, имея 100 сервисов имеете возможность 100 вариантов реализации и логики. И вам придется контролировать и сопровождать каждый API! Иногда придется вносить изменения в API нескольких сервисов для внесения измения в логику.
9) Проблема 8 - новая точка отказа, реестр сервисов / service locator. Ему нужна своя конфигурация для тестовой и рабочей среды.
10) Проблема 9 - рассинхронизация данных, когда несколько сервисов опираются на одно хранилище данных. В итоге можнет возникнуть конфликт на уровне структуры данных и придется их разносить.
"Microservices: don’t use them yet!" опубликовано 2019-12-26
Ситуация: ребята делали стартап командой в 3 инженера DevOps и 5 разработчиков (лид, 2 фронт, 2 бэк) и решили переделать лучше модно - микросервисами.
Что стоит запомнить:
1) Что у всех на слуху не обязательно подходит вам или что хорошо для Google вам может вообще не подойти (эти модные словечки AWS/Docker/Microservices)
2) Число микросервисов должно быть меньше числа их разработчиков. Разделяя традиционное монолитное приложение мы делим его на независимые модули и обычно кладем в разные репозитарии - отлчно! Теперь мы можем получать ошибки из большего числа источников и еще больше скакать между ними (это плохо).
3) Разделили - класс. Только как теперь обратиться к общей бизнес логике, которая нужна нескольиким сервисам...о НЕТ! Нам нужен еще один сервис?! И нужно его тоже обернуть в REST/RPC и написать кучу кода поверх.
4) Раздувание набора рабочих инструментов - теперь нам нужно еще коечто модное, к тому что уже есть: Docker, Express,Redis,Mysql,Kubernetes (kubectl),Swagger,React, Babel 6/7
5) Усложнение развертывания - теперь надо запустить запускать кучу сервисов и смотреть множество мест отказа (помните про наши 12 репозитариев ХаХА! - сказал пират)
Что поняли после разработки:
Можно было сделать иначе и проще:
- один репозитарий для всего, внутри каталог для исходников бекэнда и фронтэнда.
- общие правила для стилей кода, все тут.
- дать несколько репозитариев команде рисковать получить дублирование логики в разных репозитариях - и это хреново.
- пока у вас максимум 3 команды из 5 разрабочиков - не имеет смысла плодить множество репозитарев для частей бекэнда. Лучше пусть команда движется медленнее, но понимает код друг друга в этом репозитарии.
Накладные расходы микросервисов М.Фаулер 2015
И читая профильную литературу не один раз сталкивался с примерами избыточного и неуместного использования микросервисного подхода.
Итак вот что еще удалось прочитать.
"Вам не нужна микросервисная архитектура" опубликовано 2017-05-25
Статья написана с позиции "адвоката дьявола" и о главных проблемах этого подхода.
Самое главное:
1) сложность, которая содержалась в большом и тяжелом монолитном приложении, никуда не ушла в тот момент, когда мы упростили код и вычленили всю логику в отдельные компоненты - теперь вся сложность, от которой мы избавились, прячется в зазоре между нашими сервисами - в том как они коммуницируют, как разворачиваются, как реагируют на изменения, и в других аспектах. Не стоит начинать новый проект с этого - за сиюминутный выигрыш в простоте кода, позднее придет расплата, которая может оказаться вам не по карману, если вы недостаточно опытны.
2) Если вы маленькая команда, и только начинаете, то - пишите обычные приложения - вам нужно бизнес развивать / удовлетворять, а не упражняться в элегантных архитектурах - если выживете, появится возможность какие-то фрагменты переписать “как надо”, а если вы вместо полезных фич будете всю дорогу бороться с инфраструктурными проблемами, то такого шанса может и не представиться.
3) Хотите иметь возможность переходить к сервисным архитектурам? Структурируйте внутреннее устройство вашего приложения, разбивайте его на компоненты, вычленяйте хорошие интерфейсы, библиотечные модули. См. архитектура на компонентах
Что стоит запомнить:
1) (Микро)Сервисы - это дорого не только с точки зрения самой разработки, как проектирования и написания кода - дорого с точки зрения поддержки, эксплуатации и отладки, внесения изменений. Настолько дорого, что процесс такой разработки может разорить небольшую компанию, или начинающий стартап.
2) Проблема 1 - еще одна точка отказа "Сеть" и дополнительная обработка сетевых ошибок (дополнительные ситуации о которых вы могли забыть или даже не знать). В вашу жизь войдут все категории сетевых проблем. Факт того, что все работает сегодня, совершенно не гарантирует, что оно так же будет работать завтра, если у вас нет полного контроля над сетью и тем, что в ней происходит (особенное если это в "облаках").
3) Проблема 2 - обработока удаленного вызова, это не тоже самое, что локальный вызов процедуры. Вот возникла у вас проблема при вызове, и что делать повторить вызов? А если вызов приводит к куче побочных эффектов в других сервисах, выставлению счетов и отправке уведомлений? Предстоит попотеть, чтобы после каждого такого эксцесса выяснить, что уже запущено в работу, а что нет и действовать исходя из полученной инфомации.
4) Проблема 3 - сложное и непредсказуемое интеграционное тестирование. Данные могут идти по цепочке сервисов, и по отдельности модульные тесты каждого сервиса проходят. Например сервис А получает данные от Б, а тот от В. Сервис Б умеет понимать разные форматы от В и отдавать результат вам в А. Тут вдруго поменяли форматы в В, тест пары Б-В проходит на тестовых данных, Б-А тоже проходит, то при прогоне А-Б-В тест не идет! А: не может обработать данные от Б полученные от В в новом формате. А не менялся, Б не менялся, но все сломалось. Решением может быть запуск всего набора сервисов и сквозного прогона типовых сценариев (это долго проводит и настраивать тоже). И В итоге запуская все вместе мы опять получили одно очень большое приложение...
5) Проблема 4 - развертывание усложняется, зависимости тоже. DevOPS инженеру придется несладно настраивая запуск нужных версий сервисов (особенно если у ваших протоколов нет версионности). Несколько версий сервится предьявляют взаимоисключающие требования к структуре БД с которой они работают - упс! Еще проблема.
6) Проблема 5 - мониторинг, сбор и анализ логов усложняется. Несколько экземпляров сервисов на разных машинах с разной аппаратной частью. Логи надо хранить централизовано, а если транспорт отказал, то складывать локально, а еще следить за доступностью сервисов (хранить результаты healthcheck в разные момоенты времени, чтобы знать кто был недоступен)
7) Проблема 6 - много точек входа API и на каждую свое описание, версионирование, авторизация, валидация и прочее...В одном приложении у вас одна точка публикации API и поддерживать нужно одну (ну две...позже).
8) Проблема 7 - разные люди проектируют API по разному, имея 100 сервисов имеете возможность 100 вариантов реализации и логики. И вам придется контролировать и сопровождать каждый API! Иногда придется вносить изменения в API нескольких сервисов для внесения измения в логику.
9) Проблема 8 - новая точка отказа, реестр сервисов / service locator. Ему нужна своя конфигурация для тестовой и рабочей среды.
10) Проблема 9 - рассинхронизация данных, когда несколько сервисов опираются на одно хранилище данных. В итоге можнет возникнуть конфликт на уровне структуры данных и придется их разносить.
"Microservices: don’t use them yet!" опубликовано 2019-12-26
Ситуация: ребята делали стартап командой в 3 инженера DevOps и 5 разработчиков (лид, 2 фронт, 2 бэк) и решили переделать лучше модно - микросервисами.
Что стоит запомнить:
1) Что у всех на слуху не обязательно подходит вам или что хорошо для Google вам может вообще не подойти (эти модные словечки AWS/Docker/Microservices)
2) Число микросервисов должно быть меньше числа их разработчиков. Разделяя традиционное монолитное приложение мы делим его на независимые модули и обычно кладем в разные репозитарии - отлчно! Теперь мы можем получать ошибки из большего числа источников и еще больше скакать между ними (это плохо).
3) Разделили - класс. Только как теперь обратиться к общей бизнес логике, которая нужна нескольиким сервисам...о НЕТ! Нам нужен еще один сервис?! И нужно его тоже обернуть в REST/RPC и написать кучу кода поверх.
4) Раздувание набора рабочих инструментов - теперь нам нужно еще коечто модное, к тому что уже есть: Docker, Express,Redis,Mysql,Kubernetes (kubectl),Swagger,React, Babel 6/7
5) Усложнение развертывания - теперь надо запустить запускать кучу сервисов и смотреть множество мест отказа (помните про наши 12 репозитариев ХаХА! - сказал пират)
Что поняли после разработки:
Можно было сделать иначе и проще:
- один репозитарий для всего, внутри каталог для исходников бекэнда и фронтэнда.
- общие правила для стилей кода, все тут.
- дать несколько репозитариев команде рисковать получить дублирование логики в разных репозитариях - и это хреново.
- пока у вас максимум 3 команды из 5 разрабочиков - не имеет смысла плодить множество репозитарев для частей бекэнда. Лучше пусть команда движется медленнее, но понимает код друг друга в этом репозитарии.
Накладные расходы микросервисов М.Фаулер 2015