Comments 18
Все это и многое другое есть в книге Сэма Ньюмена "От монолитов к микросервисам". Это во-первых. А во-вторых и главное: когда имеет смысл делать такую трудоемкую и не гарантирующую успех миграцию?
Когда от вас требуют:
1) Масштабируемость - на больших нагрузках без нее никуда.
2) Высокую отказоустойчивость - достигается как и аппаратными средствами + средствами виртуализации, так и программными (резервные инстансы)
Я не эксперт, но: я как-то узнал, что Lichess, имея до 100 тыс. пользователей онлайн, крутится на одном сервере (точнее, игровой сервер Lila). Так что масштабируемость довольно спорный момент, если это не сайт с аудиторией всяких социальных сетей.
А ведь могли перейти на микросеовисы. Нанять ещё больше людей. Писать каждый микросераис на своем языке. Нанять дополнительно hr отдел, который будет нанимать разных программистов. Программисты бы смогли масштабировать систему на сотни серверов, были бы написаны сотни микросераисов, с отдельным API и его версионированием. Запилить распределенные транзакции. Использовать разные бд для кэширования.
А они сидят и бздят на одном сервере:)
Влияние микросервисов на масштабируемость преувеличена
Отказоустойчивость там специфическая: одно чиним, другое ломаем
Просто надо иметь очень хорошего архитектора и ревьювера. Ну и грамотную команду разработки (да, дорого)
Микросервисы штука с одной стороны простая и понятная, а с другой.. межсервисные транзакци и прочие "нюансы" могут поставить весь прод в мечтательную позу, если не будут учтены всевозможные сбои и проблемы. Ни какого ACID - чистый треш.
Оба качества достигались и до хайпа микросервисов наличием избыточного количества копий приложения. Так при каких условиях имеет смысл его дробить?
Когда от вас требуют:1) Масштабируемость - на больших нагрузках без нее никуда.2) Высокую отказоустойчивость - достигается как и аппаратными средствами + средствами виртуализации, так и программными (резервные инстансы)
Обычно это все достижимо и с монолитом. Плохо решаемые проблемы начинаются для очень большого и очень сложного монолита.
Основные фишки микросервисной архитектуры - это своя база для каждого сервиса и отсутствие общей программной платформы на все случаи жизни.
Если монолит огромен и сложен, то часто бывают ситуации, когда для добавления новой функции надо что-то немножечко поправить в платформе, а если поправишь, то рискуешь зацепить всех, и согласовать такую правку может только один из ключевых программистов проекта, а он все время занят....
Вот тогда идеи микросервисов и приходятся кстати: общей платформы больше нет, ее функции частично дублируются в разных сервисах, но зато эти функции можно менять не согласовывая со всеми. Аналогично со схемой данных: нужна колонка в базе, добавил колонку и не нужно париться что о ней думают все другие команды. То же самое, когда в одном сервисе данные хранят используя само-писанную платформу, во втором через ORM, в прямо в базе. Каждый делает как ему удобно и не переживает как эти же задачи принято решать в проекте.
1) Масштабируемость - на больших нагрузках без нее никуда.
Почему никуда? Что мешает разместить одну и ту же монилитную программу на множестве разных машин, и поставить перед ними брокера сообщений, который будет определять, какой тип сообщений отправлять на какую машину. Да, при этом каждый монолит будет работать так, как будто он и не монолит вовсе, а микросервис. Зато это одна единая программа, целостность которой гарантирует компилятор и юниттесты. Проще писать, проще тестировать, проще поддерживать. И зачем в таком случае вообще нужны микросервисы?
как писалось выше это достигается в монолитах.
реальная польза микросервисной архитектуры - это когда разрастается штат программистов и согласования/разработа в рамках одного микросервиса будет проще и быстрей чем в рамках монолита.
то есть это про менеджмент разработки.
Поскольку иллюстрации взяты из статьи https://blog.bytebytego.com/p/from-monolith-to-microservices-key (за пэйволлом), опубликованной 2 днями ранее, то я предполагаю, что содержимое сдернуто оттуда же.
Насколько я понимаю микросервисы - это хостинг независимых (ограниченных) модулей.
То есть если монолит модульный - то переход на микросервисы - это разнести модули по серверам и наладить между ними взаимодействие через различные протоколы синхронного и асинхронного взаимодействия. Плюс подложить соломку в виде рейтрай полиси, циркуль-брейкеров, саг и тп. В конце наслаждаться тоннами денег на девопс, увеличенными задержками в обработке данных и «когда-нибудь оно будет в согласованном состоянии»
А вот если монолит не модульный. То сначала из него надо сделать модульный. Нарезать ограниченные контексты, разрезать единую бд на схемы, и тп.
Не советую связываться с Debezium
А точно надо "перейти от монолита к микросервисам"? ;)
Как перейти от монолита к микросервисам без сложностей и рисков? Четыре проверенных паттерна