Комментарии 15
Прокоментирую. Чтоб применять практики как в Нетфликс и Убер, надо быть как Нетфликс и Убер - быть очень большими и нанимать квалифицированный персонал за 300 килобаксов. А если вы маленькие, бедные и умеренно компетентные - то лучше присмотрется к технологиям попроще. Монолит, единый яп и синхронный код - отличный выбор для огромного количества юзкейзов
Тихо ты!
Согласен, тут ещё вопрос кадров , чтоб поддерживать зоопарк сервисов нужно много людей , условные 5 программистов и 20 микров ( которые нихрена не микро) на 100 серверах - это больше проблем чем плюсов
Статья по сути банальное решение работы с любым асинхронным сервисом. Да можно тут и без рэббита, но в мире победивших облачных сервисов и докера это всё в целом ПРОСТОЕ решение. Где вы тут увидели необходимость в супер мега программистах — хз. В мое время такое на первом курсе студенты писали с самописными очередями. Студенты, Карл.
Микросервисы никак не отрицают единый яп и синхронный код.
Монолит в итоге сложнее и дороже поддерживать, вы думаете айтиха идет по пути элитарного программирования на эзотерических яп? Как раз наоборот.
Чем больше технологий задействовано в создании продукта, тем острее проблема копметентности. Ибо или разработчик знает много разного, но крайне поверхностно, либо знает мало разного но сумел погрузится в некоторые важные детали. Но не все вместе. А мса за собой тянет лютый зоопарк обычно.
Касаемо различных языков, это то что упоминает автор, вот мол мс на гоу, а вот на пайтоне. Более того ходят слухи, что в нетфликсе, чтобы люди не шарили код, специально заставляют писать сервисы на разных языках. Так что разнородная языковая среда это вполне укоренившаяся идея в индустрии.
В амазоне, скажем, десятки тысяч раработчиков, конечно, им там было бы тяжело писать единый монолит. Они там разделились на мсы написали статьи про мса и живут себе спокойно. А потом эти статьи читает команда из 10 человек и применяет мса к себе и вот тут у меня возникают сомнения.
Возможность писать на разных языках - это только одна из множества возможностей. Банально у меня в одном мс устаревший стек и нет возможности поднять версию фреймворка, а в другом нужна новая фича, которая вот только вышла в бета-тестирование в новом фреймворке, и ещё не известно, насколько хорошо она будет работать под нагрузкой. В монолите это стало бы неразрешимой проблемой
Возможность иметь устаревший стек это скорее антивозможность, а старая версия фреймворка возможно не только старая но уже и дырявая. И то время, которое команда тратит на возню с микросервисами она могла бы потратить на обновление зависимостей и новую фичу и ее границы тоже бы изучила. В крупных корпорациях к обновлению зависимостей принуждает юротдел - выдают и отзывают разрешения на использование либов, могут за устаревший фреймворк сделать ай-йай-йай.
Пс. За тся извените.
У нас было два железных криптосервиса с библиотекой на .net 2.0, сто семьдесят семь микросервисов на .net 3.5 на поддержке (сервисы хорошие, оплачивать их рефакторинг, мы, конечно, не будем), три сервиса на java, разработчики которых уже не с нами, пять версий одного микросервиса с разной степенью реализованности интеграций (партнер по интеграции до сих пор не предоставил тест, а сдавать прод через две недели), и целое море микросервисов, которые можно запустить только на проде, поскольку цепочки интеграции превышают все мыслимые человеческому мозгу размерности. Не то, чтобы всё это было категорически необходимо для успешной работы бизнес-процессов, но если ты мастодонт масштабов страны, то все описанное выше - лишь малая часть твоей инфраструктуры
Соглашусь, надо соизмерять подходы с потребностями. Как говорил наш препод по морской практике, лучший узел - тот, который ты знаешь.
Однако чем больше ты вкладываешься в технологии, тем меньше у тебя проблем роста. А проблемы роста, они, собаки такие, мешают, как это ни удивительно, росту. А это, зачастую, наша приоритетная задача - чтобы проект развивался.
Так что можно оставаться малышом на монолите, а можно стремиться применять современные подходы там, где это можно себе позволить, рассчитывая на дивиденды в будущем в виде меньших издержек развития проекта
Для домашнего проекта я бы писал монолит просто потому, что у меня нет ни желания, ни возможности тратить время на всю суету вокруг микросервисов. Но на рабочем проекте я монолит бы даже не стал рассматривать
З. Ы. И, простите, ться
И не забываем что сплитбрейн у rabbitmq не лечится без потери данных.
Что отсутствует у NATS, Jetstream и "for update skip locked"
Если мне не изменяет память, Nats в дефолтной конфигурации (без jetstreams), вообще доставляет только тем подписчикам кто онлайн. А если все оффлайн то никуда не доставляет.
Но вообще, потеря месседжей это обычно неизбежная ситуация. Скажем, если мы апдейтим базу и посылаем об этом нотификацию через меccедж брокер. Эти два шага же не образуют единую атомарную операцию. А значит мы можем проапдейтить бд и тут же упасть и месседж просто не будет послан, хотя стейт и изменился.
Так что надежный сервис должен обычно иметь план Б на случай потери собщений (и их дупликации кста), а если такой план есть то надежность месседж брокера не столь важна, если не доставляет постоянно боль, то ну и ладно.
NATS гарантии - at most once, Jetstream - at least once, "for update skip locked" - exactly once.
Про потери мессаджей гугл - Transactional inbox/outbox.
Микросервисы и RabbitMQ в Docker