![( ^ИГ мВо ib 4.
- W .dIHÜ Ч~ A
ЁЯПг № ; j ! -Г sky
л*' 3^ ■ Ж i р^5®вИИ| ¿лйии РЙЖЖ Шйймд шВ
дДСр]иТ»шо^|ít]^»у*1Й^И^ЯИ^И- л /jJ íJjüM¿A gH Щц i,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,Друзья (Сериал),Сериалы](https://img2.joyreactor.cc/pics/post/full/it-юмор-geek-Друзья-(Сериал)-8134115.jpeg "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,Друзья (Сериал),Сериалы")
Во-первых монолит и горизонтальное масштабирование это вещи слабо совместимые и запуск такого это всегда костыли и нихуёвый оверхед, потому что ты масштабируешь сразу всё что есть в монолите, даже если он задыхается только на одном конкретном этапе, во-вторых что мешает несколько системд сервисов запустить?
как же чел раскрутился с тех времен (crymory)
-5040079.jpeg "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,Друзья (Сериал),Сериалы")
Делать проект одним большим куском. Кубернетс - приблуда для компоновки отдельньіх кусков-кирпичиков проекта. При монолите он не нужен (на самом деле нужен, так как всегда на монолит потом чегото навешивают)
Так стали называть классические серверы после того, как в моду вошли микросервисы. Микросервисы это зоопарк разных сервисов, которые друг с другом общаются по сети. Чтобы их всех поднимать или обновлять, нужен специальный "оркестратор", который бы следил за ними и спавнил или гасил по необходимости. Ебала та еще, так что требует отдельной роли "девопс".
Монолит---это подход при котором приложение не разделяется на независимые компоненты и взаимодействие между ними. В современной айтишке сейчас это сохранилось в нескольких изолировнных направлениях, все остальное пилится на микросервисы, потому что так 9 матерей могут родить ребенка за месяц---после того, как архитекты запилят логику, несколько независимых команд параллельно педалят каждый свои сервисы. И можно запилить готового к продаже энтерпрайсного франкейштейна за три спринта.
А ещё это даёт более предсказуемый результат. Поскольку контракты на обмен данными строгие, то изменения внутри модуля не трогают остального проекта. И всё это достаточно хорошо тестируется. А вот в монолите, в плохом случае, со временем могут начать вытекать новые правки, которые могут неявным образом повлиять на пятый мизинец третьей ноги на второй жопе, отчего там начинается на ровном месте фантомная боль, будто на лего наступил.
Читал на хабре, что многие кто успел много поработать с микросервисной архитектурой пришли к выводу, что их не стоит пихать во все проекты и первое что нужно сделать при согласовании проекта это определить - монолит ли тут будет лучше или микросервисы. То есть, монолит вполне имеет сеье место быть и надо уметь работать с ним, а не отказываться полностью. Видел картинки где связи между микросервисами настолько запутанные, что нужен новый инструмент, поисковая система чтобы ориентироваться в них (картинка в статьях была другая, но эта думаю тоже подойдет для наглядности)
-5040292.jpeg "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,Друзья (Сериал),Сериалы")
Кафка это pub-sub система, количество подписывающихся (консьюмеров) или публикующих (продьюсеры) сервисов может быть условно каким угодно (там есть своя специфика конфигурации, но даже в самой примитивной конфигурации топиков, можно повесить тысячи консьюмеров на топик, а продьюсеры кажется не ограничены, лимит только на throughput. Если делать по нормальному - то каждый сервис будет иметь свой топик, тогда кол-во сервисов вообще будет не ограничено - но тут придется помудрить с месседжингом все-таки)
Если же говорить о пропускной способности - confluent kafka например гарантирует пропускную способность до 1Гб/сек, если не писать в кафку бинарные файлы, а использовать ее только для метаданных, то этого хватит для своего нетфликса, скорее всего.
Если же говорить о пропускной способности - confluent kafka например гарантирует пропускную способность до 1Гб/сек, если не писать в кафку бинарные файлы, а использовать ее только для метаданных, то этого хватит для своего нетфликса, скорее всего.
Я читал "Чистую архитектуру" Мартина, и он учит, что первым делом нужно проектировать архитектуру, а на монолите она будет или на микросервисах, нужно определять в последнюю очередь. Связи между компонентами что там, что там будут с одинаковыми контрактами, вот эти контракты и нужно определять в первую очередь.
Ну и ещё кто-то из классиков стратегии (кажется, Сун-цзы) сказал, что равные позиции преобразуются в равные, поэтому ад зависимостей между классами в монолите превращается в ад зависимостей между микросервисами.
Ну и ещё кто-то из классиков стратегии (кажется, Сун-цзы) сказал, что равные позиции преобразуются в равные, поэтому ад зависимостей между классами в монолите превращается в ад зависимостей между микросервисами.
-5040081.jpeg "it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,Друзья (Сериал),Сериалы")
То что раньше жило в одном месте, теперь делят на десяток мест. То что передавалось внутри памяти, теперь сериализуется и гоняется по сети. Процессы раньше управлялись ОС-ю внутри одной машины, теперь нужен кубернетес чтобы морочить десять машин. Кафку выдают за что-то новое (pub-sub схема была еще наверное лет 40 назад). Я решительно не вижу прогресса, лишь новые базз-ворды.
Чтобы написать коммент, необходимо залогиниться
Отличный комментарий!