Опять вторые после Гугла высказываются. Требуют знание сортировки в хэш таблицах, а потом растят крудошлёпов. 1С ники как минимум понимают язык запросов до уровня оптимизации и вращения OLAP кубов. Хватит их обижать.
Если речь про "анмаршл" json/xml, то я не сказал бы что в питоне это делать намного проще делать
В питоне json - это его суть. Если говорить языком го - то, например list[] в питоне - это []interface{} на го. При этом в питоне такой объект является примитивной конструкцией, не требующей как в го, например, утверждать типы(или копировать значения списка []int в слайс пустого) чтобы прочитать данные списка/слайса или положить данные в список/слайс.
Наверное если проект написан на питоне, то обычно дешевле оптизировать код а не переписывать его на другом языке.
Если это микросервис - то дешевле переписывать. Потому что его всё равно переделывать. И нужен супер скил, и книжек по оптимизации мешок, а в идеале готовый спец, умеющий код на питоне разгонять. А если взять Джуна с опытом в го. Он напишет хардкод месиво на коленке и оно уже будет быстрее работать.
А весь проект, да. Сложно сразу обуть на новые рельсы. Но слона по частям едят обычно
Пул потоков в питоне он не для CPU boud задач. Ну джсон на пуле потоков точно париться не будет паралельно.Там GIL воткнут.
Из наблюдений. Питон время измеряет стандартным пакетом в микросекундах. А Го - в нано.
Именно GIL не позволяет питону быть быстрее Го в cpu-bound задачах.
А пул процессов в питоне - он дорогой по оперативке. Особенно Спаун, который обычно более надёжен чем форк. Тут го опять выигрывает своими легковесными потоками-горутинами.
Однако в Го крайне легко словить дедлок. А в питоне так как там GIL. Про дедлок не слышали даже мидлы. И то что там гонки с данными бывают тоже никто не слыхал из питонистов.
Изучаю го, после питона (опыт 5 лет). Не могу понять для чего в Го рефлексия. Не мучаетесь, пройдите туториал по питону и шаблонизации текста и генерируйте код го через шаблоны ниндзя.
Ну, по сути, использование рефлексии в Го выглядит как попытка стать динамически типизированным, цепляясь за производительность. Не зря же многие умные люди говорят,что статическая типизация быстрее динамической. Знают чего небось. Профайлеры умеют включать.
Не усидеть с рефлексией на двух стульях. А если её прям НАДО использовать в кодогенераторах - то Вам в питон.
А если рефлексия нужна в ОРМ? ОРМ - это зло. Надо уметь понимать язык СУБД.
А если у меня универсально сложный анмаршл? И супер синтез структура - то Вам опять в питон (или вы ошиблись в архитектуре, посмотрите на бизнес кейсы внимательнее). Пока Го там будет пытаться сохранить производительность, питон просто её принесёт в жертву. И результата добьётесь за сутки.
Кароче хотите гибкости - учите питон. Хотите хайлоад - нафиг рефлексию. И никаких компромиссов.
Нужен генератор кода - идём в питон. Нужно что то супер абстрактное - идём в питон.
Книжки они там целые выпускают... О том как весь мир опутать одним инструментом. Знаем мы такие книжки. На питоне мешок книжек про оптимизацию. А смысл в этом? Под каждый кейс - свой инструмент. А язык - это инструмент)
Самый читаемый код - самый долго работающий. Самый не читаемый код - самый быстро-работающий.
Пример максимально читаемого кода: "Привет компьютер. Сходи в кафку, достань данные, положи в базу". Для запуска нужен чат жпт, ещё гора нейронок и сервисов под капотом ... Очень легко читается.
Пример самого производительного кода "01101101111.... 1000 000 строк спустя 001111011". Вообще не читается. Включить можно на куске из дерева
Микросервисы - это уже не модно само по себе и антипаттерн для команд маленького размера и стартапов.
Да - прикольно пилить работу на 1000 человек через микросервисы - чтобы создать магазин косметики. И уже не прикольно делать это втроём в каморке как монолит в котором и фронт и бэк - всё в одном месте через шаблоны.
Но есть более интересная вещь - настоящий кошмар для любителей догм про микросервисы - "Квантовые сервисы". Квантовые сервисы позволяют создавать такие магазины командами от 5-ти человек (3 на Бэк и 2 на фронт, например). Квантовые сервисы берут лучшее от монолитов половину антипаттернов от микросервисов и немного их паттернов - и получается гремучая смесь.
Квантовый сервис - это один проект/репозиторий (моно-репа), который рождает несколько докер-контейнеров (обычно 5-20, команда то маленькая, а ещё тесты писать и нагрузочные тесты и QA тесты - и это всё тем 3-м ребятам с бэка). Кодовая база одна - безусловно. Код поделён на слои и грамотно. Можно масштабировать его хоть до бесконечности. Повторяющийся код-опыт выделяется в OpenSource решение, если это код, реализующий технологию. Бизнес-логика выделена в отдельный кодовый слой-ядро. А к ядру - любой слой интерфейса, gRPS, REST-API, что угодно. БД одна или несколько - зависит от проекта (не только Одна! или каждому контейнеру своя обязательно! А сколько выгодно - столько и баз). Так ещё и СУБД самих может быть несколько и это нормально.
CQRS - полезен и в квантовых сервисах, один контейнер наполняет БД, другой - строит запросы и отдаёт в дашборды.
Сага не нужна, так как между контейнерами связи нет (Вообще нет - вот оно, соблюдение супер-паттерна). Они не общаются. У них в ядре весь код всего проекта (да, эти страшные исходники легаси бизнес-логики на 5-20 мегабайт - лежат в каждом контейнере и "жутко бесят" Devops команду). Потребности через API дёргать функции друг у друга нет, весь код есть у каждого. Нужна очередь - включаем gRPC на RabbitMQ или что-то подобное.
И на удивление просто поддерживать квантовые сервисы. И расширять. Потому что у монолитов тоже были догмы. Одна из которых была "Включай голову, подключай ООП и дели код на слои".
Пример деления на слои:
Слой 1. Кодовая база (она же библиотеки, она же слой Технологий) - ничем не отличается от того, что все скачивают из OpenSource решений на гитхабе. Каждая своя библиотека/модуль/GoMod проходит тестирование и может использоваться на любом проекте как обычно (как и любые другие чужие).
Слой 2. Бизнес-легаси. Ядро проекта. Бизнес-логика - она всегда легаси, почти. Она постоянно меняется, хардкода там полно - заказчик так решил, ему надо было быстро - он дал денег. Если хардкод обретает смысл - он отправляется в слой 1. Постоянно идёт процесс осмысления того что есть технология, а что есть - просто логика и где можно паттерн ООП воткнуть, а где и хардкода достаточно.
Слой 3. Интерфейс. Здесь всё просто. Нужен REST - прикрутили REST. Нужен gRPS - прикрутили gRPS. Когда интерфейсов много они могут реализовывать разные вещи, или одинаковые но по-разному. Это всё вопросы интерфейсов.
Сумма трёх слоёв родит контейнер.
Не сложно догадаться что тут используется паттерн слабой связанности - а точнее её полное отсутствие между слоями. Технологии живут своей жизнью всегда, потому что часть вы скачали, а не создали. Легаси бизнеса - своей. А интерфейсы к нему - своей, потому что фронту неудобно то да сё. И что) Не пересобирать же двигатель машины - если у руля валики резиновые, а не кожанные. Логично - просто заменить валики.
А теперь шок-контент - если один квантовый сервис родит один контейнер - это будет микросервис =) Да ещё и по всем канонам всех миров.
Внешне, когда получается несколько контейнеров - это ничем не отличается от микросервисов. Всякие хелс чекеры, кёркит брикеры и прочую нечисть можно спокойно вешать сюда. Настраивать метрики. Пилить QA тесты. Узлы системы масштабировать в кубере независимо друг от друга. 100% поведение микросервисов. Не найдёте ни одного отличия просто. Внутри - это 100% единая кодовая база. Слои которой живут своей жизнью. Поведение - правильного монолита.
А какие плюсы? +Отпадает часть коммуникаций между контейнерами. На это не тратятся ресурсы просто. +Человек нужно меньше на тоже самое. +Не нужно 100500 БД в СУБД и 15 СУБД. Нужна одна правильно построенная система хранилища под задачи бизнеса. +Кода меньше, чем при микросервисах (мы же выкинули шины между ними и их поддержку, как минимум)
А какие минусы? - Это не монолит. - Это БУДЕТ распределённый монолит, если не соблюдать правила догм монолита. - Это не те микросервисы, к которым привыкли большие команды. Более того это не подходит для числа людей когда часть сервисов на Go, например. Другая - на Python. Но не что не мешает объединить их в 2 команды по языку с другой стороны. =)
Идея понятна, и что-то похожее, кажется, даже упоминалось в документации. Но надо учитывать, что подобная техника написания запросов сильно подвержена ошибкам. Очень легко забыть вставить нужное условие, а заметно это будет только когда дубли уже просочились. Аналитические запросы и так бывают на несколько страниц текста, усложнять их еще дополнительной фильтрацией мало кому захочется
Хм. Кажется этот путь мы прошли уже своей командой. Он привёл нас к тому - что мы создали библиотеку, в которой пишем запросы, как набор JSON инструкций, которые движок потом в SQL на clickhouse переводит. Или в SQL на postgres. И у нас нет проблемы с поддержкой запросов и на 1000-10 000 строчек, не знаю сколько это в листах (в коде на JSON это мало строк - 100-300 в красивом если виде с отступами, обычно в 10-15 раз меньше и проще). Не подумал я, что большие запросы - это проблема, вот я к чему.
В аналитических отчётах 100% будет group by и агрегация и джоинов мешок и СКД. И рассказать разработчику что нужно ну argMax(field) писать вместо просто field ну не проблемно вроде (для нас точно). Поэтому и дальше идём этим курсом (версии строк).
Ценность в том, что на момент вставки не нужно ничего дедублицировать и вычислять что-то. Ресурсы не траться, как бы много данных не было на входе. И отдельная СУБД не нужна - с дополнительными кэшами. Вставляй-не хочу называется.
Да - запрос становиться чуть сложнее. И выполняется он чуть дольше. Процентов на 10%, что легко компенсировать дав кластеру не знаю, на 1-2 ядра больше на ноду, ну и разработчику - шоколадку с кофем, да и всё.
А если хочется и вовсе вернуться к прежнему запросу. То Можно 2 таблицы сделать. Одна первичная. А во вторую как раз свежак скидывать, и из неё уже черпать. Но это инпут-лаги. Например, сохранил документ в браузере, он такой ОК. А там не ок ещё) И тут Redis приехал или другой mem-cache. Ну кароче зоопарк. И зукипер ещё поставить за зоопарком смотреть. Или толстый фронт с кэшированием данных на клиенте. Или всё вместе...
А можно просто 1 таблицу и argMax вместо вот этого всего и 2 ядра по братски на кластер выбить за ящик пива.
А про clickhouse и его разработку думается - что там нет волшебной пелюли от дублей, потому что там как раз есть версии. Мы как эту волну поймали - так на ней и плывём на всех проектах.
Всё Вам правильно рассказывают. На стороне клиента/сервиса который складывает данные в Kafka - пишете сюда(version) метку времени (вплоть до наносекунды). Не важно сколько раз Вы там ошиблись или послали одно и тоже хоть 100 раз (Например в браузере пользователь судорожно жмёт на кнопку "Сохранить" и не останавливается). На стороне сервиса/потребителя СУБД, который строит отчёт - всё элементарно, как и сказали "argMax(field, version) с группировкой по pk." или СрезПоследних по-старинке, если не доверяете argMax. Вы всегда будете получать только свежие строки среди дублируемых (Например у вас 20 строк с номером=1 - на выходе запрос покажет одну - самую свежую).
Суть этой идеи в том, что вообще не надо бороться с дублями, а просто контролировать их поток и отбирать самое нужное на уровне языка запросов. Накладных расходов на эту идею в разы меньше, чем на супер схемы с MongoDB это уж точно. Так ещё и потом ClickHouse сам в фоне 19 строк грохнет =)
А это не про "Моно-репозиторий" случаем рассказ. Удобная штука, кстати. Экономит человеческие ресурсы. Вот для техно-гигантов это шок конечно читать такое, что одна команда тащит целый проект на себе. У них там по 15 человек на один микросервис. А тут человек 5-6 на проект. И надо микросервисно сделать условно Авито. Естественно язык там будет один. Естественно люди придут к моно-репе. Будут код делить на слои. Техно слой закатают в либу, опубликуют локально, ибо руководство против опен-сорса условно например. Крутой термин "Квантовый сервис". Мне зашёл. Такие решение появляются от квантовых бюджетов и сроков, кстати. И о чудо, они даже работают и rps держат не хуже истинных микросервисов. А почему, да потому что там даже связи бизнес модели можно не через шины делать а просто кодом. Огонь, пушка, топчик. И шок контент. Техно-гигантам не читать. Это не микросервисы. Это квантовые сервисы. За ними будущее. Как за квантовыми компьютерами.
На самом деле - надо больше таких статей. Чтобы всякие менеджеры, мечтающие заменить разработчиков, наконец осознали, что разработка - это наука точная. А генеративные ИИ они не думают, а генерируют. Им кормят килотонны данных и учат их играть в ностродамусов. Вместо того чтобы научить их абстрактному и критическому мышлениям. Вот пока они такое не умеют - все статьи будут похожи на эту: "Я поверил в то что без знаний языка я создам годный продукт - а чёт не пошло... ". Именно из за отсутствия у ИИ мышления как такового, его и не подключают ко всяким компиляторам и интерпретаторам, чтобы он банально сидел и анализировал хотя бы тот код который он выдаёт и сам бы составлял проект и запускал у себя там на сервере, а уже потом показывал. Потому что это всё точные операции, которые нужно подумать и сделать. Пока что ChatGPT - это новая ступень поисковика.
Ваша лучшая подушка - быть готовым к любой катастрофе, ждать самого худшего, надеяться на лучшее и во время употреблять спиртное. Иметь как минимум ящик хорошей выпивки в запасе. Всё это вместо 1000 книжек по психологии.
День первый. Приходит аналитик. Говорит фича нужна через неделю. Сотрудник Х - отвечает, а в чем её бизнес ценность? Аналитик ну вот в этом. Сотрудник Х - а точно, по причинам таким то таким то не особо то она и нужна. Аналитик - ну меня овнер убедил поговори с ним. Сотрудник Х - не пойду, передай ему - что не будем делать, не успеем за неделю.
День второй. Приходит овнер к сотруднику Х. Говорит мягко и нежно - почему это мы не будем делать фичу. Получает от сотрудника Х расчет отрицательной конверсии трат и выхлопа с фичи. Чешет затылок. Настаивает на реализации. После того как закончились все аргументы, говорит - ну меня СТО убедил, у него такие же примерно расчеты были. Говорит иди к СТО. Сотрудник Х говорит - ну ты ко мне сам пришел и он придет.
День третий. Приходит СТО к сотруднику Х. Говорит мягко и нежно - с каких пор СТО вообще должен обсуждать с сотрудниками Х то что бизнесу надо и что ему не надо, мы (сто+овнер+отряд аналитиков) уже все расчеты провели и конверсия точно вырастет, как ты вообще смог убедить их всех что этого не случиться??? Сотрудник Х - ну вы речь толкнули о том что всем надо вникать в бизнес, я вот вник. Вот расчеты с тратами и сроками реализации.
В тот день СТО испытал шок и ужас. Речь он толкал 3 дня назад. С сотрудником Х согласился. И поднял ему ЗП. В расчетах черным по белому было написано "Для реализации данной фичи не нашлось подходящей open source библиотеки на всех известных и не очень я зыках программирования, поэтому нужен рисёч, а это займёт от 3 месяцев на 2 чел/часов".
В таких статьях не хватает оценки времени на саму разработку. Ну, например, написали микросервис А за 10 часов, было нас 1 программист. На оптимизацию через пул процессов потратили 15 минут. Купили один сервак дополнительно, ибо могли. А потом пришли к нам и сказали что пора бюджет экономить.
Пошли переписывать на го. Потратили 15 дней, кодили в 7-ром. Цель достигнута. Получили премии с продажи лишнего сервака. И прирост fps по всем направлениям.
Это точно добавит аргументов в копилку "а надо ли переписывать".
Кодю на обоих языках. И почему-то создание одного и тогоже на го, занимает на порядок времени больше, чем на python. Об этом все фанаты оптимизации в го, почему то всегда умалчивают.
А про то что после переписи на го. Начинается уже оптимизация в го, тоже забывают рассказать. Где половина кода со всей динамикой и дженериками откидывается и все кодиться автогенератором кода с максимумом статики. Что тоже требует временных затрат.
А к чему это всё. Да потому что завтра к нам в отдел придёт менеджер и скажет, ну весь питон на го переписывают - вперед. Сколько времени надо - 2 дня хватит?
Чтобы ответить себе на вопрос "чем твой любимый язык лучше другого". Ну например, чем питон лучше java?
Надо взять двух мидлов. И дать мидлу java покидать камни в питон. Ну тоесть выслушать а чем же язык плох?
Потом обоим поставить одну и туже задачу. Ну например, сделать миркросервис, который читает/пишет данные в постгрес из 3х справочников. Создать, обновить, удалить, чтобы всё там работало. Завернули чтобы в докер и закинули в кубер. Ограничение 10 под.
Важнон условие, чтобы роуты одинаково работали и назывались.
А потом тестируем нагрузку на сервисы не питоном, а продуктом на джаве jmeter. Ну число одновременных пользователей, время отклика и прочие радости. Прогоните 10 тестов одинаковых
После тестов, вы - как минимум перестанете сравнивать языки и успакоитесь. Кто кидался камнями - перестанет. И наступит мир)
Потому что, окажется что в 4х тестах выиграет питон, в 4х java. А в двух последних упадёт кубер, ибо ингресс контроллер тоже оптимизировать надо. И разница в победе там не в разы, десятки киллограм, а на одну дольку апельсина.
Потом ещё с++ ника надите. С# писта. И всех недовольных кто кидает кирпичи.
Бенчмарки от институов забугорья это конечно прикольно, но реалии таковы, что для выкручивания языка на такие бенчмарки скилов днём с фонарём не сыщешь. И в итоге все на средних скоростях и работают. В коробку вам никто в опен сорс либы не заложил супер производительность. И в язык тоже не прикрутил в коробку. И вообще никому мы там не нужны, чтобы секреты супер быстрого кунфу нам раскрывать.
Все языки так или иначе потом в железо упираются и операционку. И кубер куберу кубернет. У кого на центосе, у кого на убунте.
Эх. Вымерли техлиды в умах живущих... У всех заканчивается ветка на тимлидстве
О, кто то вскрыл капсулу времени
Опять вторые после Гугла высказываются. Требуют знание сортировки в хэш таблицах, а потом растят крудошлёпов. 1С ники как минимум понимают язык запросов до уровня оптимизации и вращения OLAP кубов. Хватит их обижать.
В питоне json - это его суть. Если говорить языком го - то, например list[] в питоне - это []interface{} на го. При этом в питоне такой объект является примитивной конструкцией, не требующей как в го, например, утверждать типы(или копировать значения списка []int в слайс пустого) чтобы прочитать данные списка/слайса или положить данные в список/слайс.
Если это микросервис - то дешевле переписывать. Потому что его всё равно переделывать. И нужен супер скил, и книжек по оптимизации мешок, а в идеале готовый спец, умеющий код на питоне разгонять. А если взять Джуна с опытом в го. Он напишет хардкод месиво на коленке и оно уже будет быстрее работать.
А весь проект, да. Сложно сразу обуть на новые рельсы. Но слона по частям едят обычно
Пул потоков в питоне он не для CPU boud задач. Ну джсон на пуле потоков точно париться не будет паралельно.Там GIL воткнут.
Из наблюдений. Питон время измеряет стандартным пакетом в микросекундах. А Го - в нано.
Именно GIL не позволяет питону быть быстрее Го в cpu-bound задачах.
А пул процессов в питоне - он дорогой по оперативке. Особенно Спаун, который обычно более надёжен чем форк. Тут го опять выигрывает своими легковесными потоками-горутинами.
Однако в Го крайне легко словить дедлок. А в питоне так как там GIL. Про дедлок не слышали даже мидлы. И то что там гонки с данными бывают тоже никто не слыхал из питонистов.
Изучаю го, после питона (опыт 5 лет). Не могу понять для чего в Го рефлексия. Не мучаетесь, пройдите туториал по питону и шаблонизации текста и генерируйте код го через шаблоны ниндзя.
Ну, по сути, использование рефлексии в Го выглядит как попытка стать динамически типизированным, цепляясь за производительность. Не зря же многие умные люди говорят,что статическая типизация быстрее динамической. Знают чего небось. Профайлеры умеют включать.
Не усидеть с рефлексией на двух стульях. А если её прям НАДО использовать в кодогенераторах - то Вам в питон.
А если рефлексия нужна в ОРМ? ОРМ - это зло. Надо уметь понимать язык СУБД.
А если у меня универсально сложный анмаршл? И супер синтез структура - то Вам опять в питон (или вы ошиблись в архитектуре, посмотрите на бизнес кейсы внимательнее). Пока Го там будет пытаться сохранить производительность, питон просто её принесёт в жертву. И результата добьётесь за сутки.
Кароче хотите гибкости - учите питон. Хотите хайлоад - нафиг рефлексию. И никаких компромиссов.
Нужен генератор кода - идём в питон. Нужно что то супер абстрактное - идём в питон.
Книжки они там целые выпускают... О том как весь мир опутать одним инструментом. Знаем мы такие книжки. На питоне мешок книжек про оптимизацию. А смысл в этом? Под каждый кейс - свой инструмент. А язык - это инструмент)
Самый читаемый код - самый долго работающий. Самый не читаемый код - самый быстро-работающий.
Пример максимально читаемого кода: "Привет компьютер. Сходи в кафку, достань данные, положи в базу". Для запуска нужен чат жпт, ещё гора нейронок и сервисов под капотом ... Очень легко читается.
Пример самого производительного кода "01101101111.... 1000 000 строк спустя 001111011". Вообще не читается. Включить можно на куске из дерева
Когда ты тимлид, техлид, devops, архитектор и 2 твоих личности не смогли договориться.
Микросервисы - это уже не модно само по себе и антипаттерн для команд маленького размера и стартапов.
Да - прикольно пилить работу на 1000 человек через микросервисы - чтобы создать магазин косметики. И уже не прикольно делать это втроём в каморке как монолит в котором и фронт и бэк - всё в одном месте через шаблоны.
Но есть более интересная вещь - настоящий кошмар для любителей догм про микросервисы - "Квантовые сервисы". Квантовые сервисы позволяют создавать такие магазины командами от 5-ти человек (3 на Бэк и 2 на фронт, например). Квантовые сервисы берут лучшее от монолитов половину антипаттернов от микросервисов и немного их паттернов - и получается гремучая смесь.
Квантовый сервис - это один проект/репозиторий (моно-репа), который рождает несколько докер-контейнеров (обычно 5-20, команда то маленькая, а ещё тесты писать и нагрузочные тесты и QA тесты - и это всё тем 3-м ребятам с бэка). Кодовая база одна - безусловно. Код поделён на слои и грамотно. Можно масштабировать его хоть до бесконечности. Повторяющийся код-опыт выделяется в OpenSource решение, если это код, реализующий технологию. Бизнес-логика выделена в отдельный кодовый слой-ядро. А к ядру - любой слой интерфейса, gRPS, REST-API, что угодно. БД одна или несколько - зависит от проекта (не только Одна! или каждому контейнеру своя обязательно! А сколько выгодно - столько и баз). Так ещё и СУБД самих может быть несколько и это нормально.
CQRS - полезен и в квантовых сервисах, один контейнер наполняет БД, другой - строит запросы и отдаёт в дашборды.
Сага не нужна, так как между контейнерами связи нет (Вообще нет - вот оно, соблюдение супер-паттерна). Они не общаются. У них в ядре весь код всего проекта (да, эти страшные исходники легаси бизнес-логики на 5-20 мегабайт - лежат в каждом контейнере и "жутко бесят" Devops команду). Потребности через API дёргать функции друг у друга нет, весь код есть у каждого. Нужна очередь - включаем gRPC на RabbitMQ или что-то подобное.
И на удивление просто поддерживать квантовые сервисы. И расширять. Потому что у монолитов тоже были догмы. Одна из которых была "Включай голову, подключай ООП и дели код на слои".
Пример деления на слои:
Слой 1. Кодовая база (она же библиотеки, она же слой Технологий) - ничем не отличается от того, что все скачивают из OpenSource решений на гитхабе. Каждая своя библиотека/модуль/GoMod проходит тестирование и может использоваться на любом проекте как обычно (как и любые другие чужие).
Слой 2. Бизнес-легаси. Ядро проекта. Бизнес-логика - она всегда легаси, почти. Она постоянно меняется, хардкода там полно - заказчик так решил, ему надо было быстро - он дал денег. Если хардкод обретает смысл - он отправляется в слой 1. Постоянно идёт процесс осмысления того что есть технология, а что есть - просто логика и где можно паттерн ООП воткнуть, а где и хардкода достаточно.
Слой 3. Интерфейс. Здесь всё просто. Нужен REST - прикрутили REST. Нужен gRPS - прикрутили gRPS. Когда интерфейсов много они могут реализовывать разные вещи, или одинаковые но по-разному. Это всё вопросы интерфейсов.
Сумма трёх слоёв родит контейнер.
Не сложно догадаться что тут используется паттерн слабой связанности - а точнее её полное отсутствие между слоями. Технологии живут своей жизнью всегда, потому что часть вы скачали, а не создали. Легаси бизнеса - своей. А интерфейсы к нему - своей, потому что фронту неудобно то да сё. И что) Не пересобирать же двигатель машины - если у руля валики резиновые, а не кожанные. Логично - просто заменить валики.
А теперь шок-контент - если один квантовый сервис родит один контейнер - это будет микросервис =) Да ещё и по всем канонам всех миров.
Внешне, когда получается несколько контейнеров - это ничем не отличается от микросервисов. Всякие хелс чекеры, кёркит брикеры и прочую нечисть можно спокойно вешать сюда. Настраивать метрики. Пилить QA тесты. Узлы системы масштабировать в кубере независимо друг от друга. 100% поведение микросервисов. Не найдёте ни одного отличия просто. Внутри - это 100% единая кодовая база. Слои которой живут своей жизнью. Поведение - правильного монолита.
А какие плюсы?
+Отпадает часть коммуникаций между контейнерами. На это не тратятся ресурсы просто.
+Человек нужно меньше на тоже самое.
+Не нужно 100500 БД в СУБД и 15 СУБД. Нужна одна правильно построенная система хранилища под задачи бизнеса.
+Кода меньше, чем при микросервисах (мы же выкинули шины между ними и их поддержку, как минимум)
А какие минусы?
- Это не монолит.
- Это БУДЕТ распределённый монолит, если не соблюдать правила догм монолита.
- Это не те микросервисы, к которым привыкли большие команды. Более того это не подходит для числа людей когда часть сервисов на Go, например. Другая - на Python. Но не что не мешает объединить их в 2 команды по языку с другой стороны. =)
Хм. Кажется этот путь мы прошли уже своей командой. Он привёл нас к тому - что мы создали библиотеку, в которой пишем запросы, как набор JSON инструкций, которые движок потом в SQL на clickhouse переводит. Или в SQL на postgres. И у нас нет проблемы с поддержкой запросов и на 1000-10 000 строчек, не знаю сколько это в листах (в коде на JSON это мало строк - 100-300 в красивом если виде с отступами, обычно в 10-15 раз меньше и проще). Не подумал я, что большие запросы - это проблема, вот я к чему.
В аналитических отчётах 100% будет group by и агрегация и джоинов мешок и СКД. И рассказать разработчику что нужно ну argMax(field) писать вместо просто field ну не проблемно вроде (для нас точно). Поэтому и дальше идём этим курсом (версии строк).
Ценность в том, что на момент вставки не нужно ничего дедублицировать и вычислять что-то. Ресурсы не траться, как бы много данных не было на входе. И отдельная СУБД не нужна - с дополнительными кэшами. Вставляй-не хочу называется.
Да - запрос становиться чуть сложнее. И выполняется он чуть дольше. Процентов на 10%, что легко компенсировать дав кластеру не знаю, на 1-2 ядра больше на ноду, ну и разработчику - шоколадку с кофем, да и всё.
А если хочется и вовсе вернуться к прежнему запросу. То Можно 2 таблицы сделать. Одна первичная. А во вторую как раз свежак скидывать, и из неё уже черпать. Но это инпут-лаги. Например, сохранил документ в браузере, он такой ОК. А там не ок ещё) И тут Redis приехал или другой mem-cache. Ну кароче зоопарк. И зукипер ещё поставить за зоопарком смотреть. Или толстый фронт с кэшированием данных на клиенте. Или всё вместе...
А можно просто 1 таблицу и argMax вместо вот этого всего и 2 ядра по братски на кластер выбить за ящик пива.
А про clickhouse и его разработку думается - что там нет волшебной пелюли от дублей, потому что там как раз есть версии. Мы как эту волну поймали - так на ней и плывём на всех проектах.
Всё Вам правильно рассказывают. На стороне клиента/сервиса который складывает данные в Kafka - пишете сюда(version) метку времени (вплоть до наносекунды). Не важно сколько раз Вы там ошиблись или послали одно и тоже хоть 100 раз (Например в браузере пользователь судорожно жмёт на кнопку "Сохранить" и не останавливается). На стороне сервиса/потребителя СУБД, который строит отчёт - всё элементарно, как и сказали "argMax(field, version) с группировкой по pk." или СрезПоследних по-старинке, если не доверяете argMax. Вы всегда будете получать только свежие строки среди дублируемых (Например у вас 20 строк с номером=1 - на выходе запрос покажет одну - самую свежую).
Суть этой идеи в том, что вообще не надо бороться с дублями, а просто контролировать их поток и отбирать самое нужное на уровне языка запросов.
Накладных расходов на эту идею в разы меньше, чем на супер схемы с MongoDB это уж точно. Так ещё и потом ClickHouse сам в фоне 19 строк грохнет =)
А это не про "Моно-репозиторий" случаем рассказ. Удобная штука, кстати. Экономит человеческие ресурсы. Вот для техно-гигантов это шок конечно читать такое, что одна команда тащит целый проект на себе. У них там по 15 человек на один микросервис. А тут человек 5-6 на проект. И надо микросервисно сделать условно Авито. Естественно язык там будет один. Естественно люди придут к моно-репе. Будут код делить на слои. Техно слой закатают в либу, опубликуют локально, ибо руководство против опен-сорса условно например. Крутой термин "Квантовый сервис". Мне зашёл. Такие решение появляются от квантовых бюджетов и сроков, кстати. И о чудо, они даже работают и rps держат не хуже истинных микросервисов. А почему, да потому что там даже связи бизнес модели можно не через шины делать а просто кодом. Огонь, пушка, топчик. И шок контент. Техно-гигантам не читать. Это не микросервисы. Это квантовые сервисы. За ними будущее. Как за квантовыми компьютерами.
На самом деле - надо больше таких статей. Чтобы всякие менеджеры, мечтающие заменить разработчиков, наконец осознали, что разработка - это наука точная. А генеративные ИИ они не думают, а генерируют. Им кормят килотонны данных и учат их играть в ностродамусов. Вместо того чтобы научить их абстрактному и критическому мышлениям. Вот пока они такое не умеют - все статьи будут похожи на эту: "Я поверил в то что без знаний языка я создам годный продукт - а чёт не пошло... ". Именно из за отсутствия у ИИ мышления как такового, его и не подключают ко всяким компиляторам и интерпретаторам, чтобы он банально сидел и анализировал хотя бы тот код который он выдаёт и сам бы составлял проект и запускал у себя там на сервере, а уже потом показывал. Потому что это всё точные операции, которые нужно подумать и сделать. Пока что ChatGPT - это новая ступень поисковика.
Ваша лучшая подушка - быть готовым к любой катастрофе, ждать самого худшего, надеяться на лучшее и во время употреблять спиртное. Иметь как минимум ящик хорошей выпивки в запасе. Всё это вместо 1000 книжек по психологии.
СТО, овнеры, аналитики...
День первый. Приходит аналитик. Говорит фича нужна через неделю. Сотрудник Х - отвечает, а в чем её бизнес ценность? Аналитик ну вот в этом. Сотрудник Х - а точно, по причинам таким то таким то не особо то она и нужна. Аналитик - ну меня овнер убедил поговори с ним. Сотрудник Х - не пойду, передай ему - что не будем делать, не успеем за неделю.
День второй. Приходит овнер к сотруднику Х. Говорит мягко и нежно - почему это мы не будем делать фичу. Получает от сотрудника Х расчет отрицательной конверсии трат и выхлопа с фичи. Чешет затылок. Настаивает на реализации. После того как закончились все аргументы, говорит - ну меня СТО убедил, у него такие же примерно расчеты были. Говорит иди к СТО. Сотрудник Х говорит - ну ты ко мне сам пришел и он придет.
День третий. Приходит СТО к сотруднику Х. Говорит мягко и нежно - с каких пор СТО вообще должен обсуждать с сотрудниками Х то что бизнесу надо и что ему не надо, мы (сто+овнер+отряд аналитиков) уже все расчеты провели и конверсия точно вырастет, как ты вообще смог убедить их всех что этого не случиться??? Сотрудник Х - ну вы речь толкнули о том что всем надо вникать в бизнес, я вот вник. Вот расчеты с тратами и сроками реализации.
В тот день СТО испытал шок и ужас. Речь он толкал 3 дня назад. С сотрудником Х согласился. И поднял ему ЗП. В расчетах черным по белому было написано "Для реализации данной фичи не нашлось подходящей open source библиотеки на всех известных и не очень я зыках программирования, поэтому нужен рисёч, а это займёт от 3 месяцев на 2 чел/часов".
Сотрудник Х звался "Техлид".
В таких статьях не хватает оценки времени на саму разработку. Ну, например, написали микросервис А за 10 часов, было нас 1 программист. На оптимизацию через пул процессов потратили 15 минут. Купили один сервак дополнительно, ибо могли. А потом пришли к нам и сказали что пора бюджет экономить.
Пошли переписывать на го. Потратили 15 дней, кодили в 7-ром. Цель достигнута. Получили премии с продажи лишнего сервака. И прирост fps по всем направлениям.
Это точно добавит аргументов в копилку "а надо ли переписывать".
Кодю на обоих языках. И почему-то создание одного и тогоже на го, занимает на порядок времени больше, чем на python. Об этом все фанаты оптимизации в го, почему то всегда умалчивают.
А про то что после переписи на го. Начинается уже оптимизация в го, тоже забывают рассказать. Где половина кода со всей динамикой и дженериками откидывается и все кодиться автогенератором кода с максимумом статики. Что тоже требует временных затрат.
А к чему это всё. Да потому что завтра к нам в отдел придёт менеджер и скажет, ну весь питон на го переписывают - вперед. Сколько времени надо - 2 дня хватит?
Чтобы ответить себе на вопрос "чем твой любимый язык лучше другого". Ну например, чем питон лучше java?
Надо взять двух мидлов. И дать мидлу java покидать камни в питон. Ну тоесть выслушать а чем же язык плох?
Потом обоим поставить одну и туже задачу. Ну например, сделать миркросервис, который читает/пишет данные в постгрес из 3х справочников. Создать, обновить, удалить, чтобы всё там работало. Завернули чтобы в докер и закинули в кубер. Ограничение 10 под.
Важнон условие, чтобы роуты одинаково работали и назывались.
А потом тестируем нагрузку на сервисы не питоном, а продуктом на джаве jmeter. Ну число одновременных пользователей, время отклика и прочие радости. Прогоните 10 тестов одинаковых
После тестов, вы - как минимум перестанете сравнивать языки и успакоитесь. Кто кидался камнями - перестанет. И наступит мир)
Потому что, окажется что в 4х тестах выиграет питон, в 4х java. А в двух последних упадёт кубер, ибо ингресс контроллер тоже оптимизировать надо. И разница в победе там не в разы, десятки киллограм, а на одну дольку апельсина.
Потом ещё с++ ника надите. С# писта. И всех недовольных кто кидает кирпичи.
Бенчмарки от институов забугорья это конечно прикольно, но реалии таковы, что для выкручивания языка на такие бенчмарки скилов днём с фонарём не сыщешь. И в итоге все на средних скоростях и работают. В коробку вам никто в опен сорс либы не заложил супер производительность. И в язык тоже не прикрутил в коробку. И вообще никому мы там не нужны, чтобы секреты супер быстрого кунфу нам раскрывать.
Все языки так или иначе потом в железо упираются и операционку. И кубер куберу кубернет. У кого на центосе, у кого на убунте.
Ну а на питоне кодить - удовольствие)