Комментарии 40
Пора пропускать такие статьи через железного болтуна ака LLM чтобы хоть что-то понять. Кожаные совсем истрепались.
Вопросы:
Вы кто?
Термины причешите: какой монолит, какой fms, щито?
В чём была проблема? Сначала в бизнес терминах, а потом техническую сторону.
Что вы пытаетесь мне продать?Если хотите обобщить и предложить как шаблон решения у других и у меня, то шаблон мне должен быть понятный и узнаваемый. А вы на каком то птичьем языке говорите.Если не хотите предложить как общий шаблон, просто ваш личный опыт, который нельзя скопировать, пишете лишь бы похвастаться, то это вам в серию "упал - отжался"
Это здорово, что вы хотите поделиться опытом. Но вы тратите время читателя.
...
Вот читаю: был монолит, через несколько абзацев было два монолита (представляю себе две настольные программы, связанные одной БД), ещё чуть позже два монолита и чаты (много чатов). Потом онлайн таблицы. Потом квадратики где видно 4+ раздельных программ. Вас трудно понять! ©
Через 5 минут становится уже всё равно...
Лет 300 назад жизнь была неспешной и стиль книг тоже был неспешный. Повествование могло минут сорок идти про природу и не имело стройного сюжета с временнОй линией, показано мироощущение, а не конкретная история.
Вот такое же ощущение.
Привет!
- Вы кто? Достаточно открыть глазки и прочитать первые предложения статьи. Я - Даня :)
- Все тоже самое - что такое FMS в первых же предложениях статьи. Все еще достаточно открыть глазки
- Про птичий язык комментировать не буду:)
- Нет никаких предложений, нет никаких советов. Описан только лишь наш путь создания большой системы и приложения и распил монолита в очень сжатые сроки и очень маленьким составом команды. Может быть он кому-то покажется интересным, ни на что не претендуем, только лишь рассказываем.
Через 5 минут становится уже всё равно? но коммент на несколько абзацев написали, значит не все равно.
К слову, у вас есть примеры из работы на питончике о создании подобных систем и приложений? Поделитесь, пожалуйста. Посмотрел ваши статьи, и у меня тот же вопрос: "Вы кто?"
Вы не можете объяснить даже что у вас было до того как полезли лапать грязными руками
а вы кто?
Архитектор и разработчик.
Жаль вас огорчать, но вы сделали микро приложение, потратив вдвое больше ресурсов чем следовало. Архитектурные решения не обоснованы. Зато использовали взрослые инструменты типа микросервисов и кубера. Молодцы, потом будет что в резюме написать.
А потом побежали писать сюда в самовлюбленном формате, не заботясь об удобстве чтения, погружения читателя в контекст проблемы.
Молодые ещё. Ну, продолжайте, тренируйтесь за счёт работодателя.
P.S. я вас старше на 20 лет. Надеюсь, у вас всё получится, успехов.
покажите, пожалуйста, примеры вашего приложения на 300+ экранов
и 11 микросервисов, а пока вопрос всё тот же: "кто вы?"
С другой стороны, ладно с этими 300+ экранами и строками кода
Понимаю, + 20 лет, тяжело читать большие технические и продуктовые статьи, но хотел бы увидеть примеры с вашей стороны, как вы меняли бизнесс-процессы и растили метрики с помощью приложения и новых систем.
И если делали, то как вы умещаете такой путь в более короткую статью
А раз нет статьи и рассказа, то и хвалится нечем?
+ 20 лет это скорее минус, чем плюс :)
Дорогу молодым:)
Кстати, по поводу пункта "А потом побежали писать сюда в самовлюбленном формате, не заботясь об удобстве чтения, погружения читателя в контекст проблемы."
В статье, в самом начале, хотя понимаю, что сложно и "многа букав", но всё же, в самом начале, пункт 1. Как все было устроено до
Вы определитесь, то вам много букв, то погрузите еще сильнее
Я бы не был столь категоричен, но в целом поддерживаю предыдущего оратора. :)
Меня другое место заинтересовало:
«JSON-описание флоу выполнения задач
Одна из главных целей — создать систему, которая поддерживает любые типы задач, любые флоу и любые действия над задачами без изменения кода бэкенда/мобильного приложения. Поэтому сам процесс выполнения задачи формируется на сервере и передаётся в мобильное приложение в виде JSON-объекта.»
Де-факто автор поста переписал html на JSON. Похоже пока это работают, посмотрим что будет через год.
Не проще-ли было бы вернуться к старому доброму html, который можно менять как угодно без изменения кода в мобильном приложении?
По поводу без изменения кода в backend- верится с трудом. Если конечно накидать 10 задач вместо 5 то наверно можно, поскольку интерфейс одинаковый, но кто из зависимости и как описывать будет? Если только пользователь «руками» в БД сделает изменения, но вопрос в том, насколько GUI развит чтобы можно было на уровне GUI/ декларативного описания с использованием JSON описывать бизнес логику?
Есть конечно вариант взять pgSQL и описать все на нем, но это не «стильно молодежно» …
Хотя тут точно - можно без изменения кода back-end и приложений много чего накодить.
Привет! кидать HTML на мобилку? Сильное решение
Ну а если серьезно,не совсем понятно, как планируется использовать html при том выборе стека мобильного приложения, который мы сделали.
Но даже если бы мультиплатформа без костылей поддерживала html, то концепция остается той же. На бэкенде мы храним схему задачи, только генерируем по ней не JSON, а HTML? Звучит сомнительно по многим причинам. Как минимум встает вопрос, а кто будет верстать такое чудо, бэкенд разработчик или фронтенд разработчик, или же нанимать фулл-стека?
Насчет рисков, здесь вы правы, использование BPMN схем, как и любое другое архитектурное решение (хотя даже больше чем любое другое!) сопряжено с определенными рисками и имеет определенные трейд-оффы. Цель архитектора эти риски грамотно просчитать, принять часть из них и отдать решение в разработку.
Ну и спойлер: с этими рисками, я считаю, мы справились :) Потому что мы имеем на руках дизайны остальных флоу задач, и наша архитектура их поддерживает ровно настолько, насколько мы изначально это просчитали: на остальные задачи будут созданы не более, чем новые микросервисы-стратегии
У вас было 2 монолита , которые хранили данные в БД (PostgreSql) теперь вы их распилил на микросервисы, которые взаимодействуют уют с помощью Kafka, gRPC и хранят состояние в БД - тот же PostgreSQL.
Вы пишите: “Такие операции выполняются асинхронно, либо через сообщение в Kafka, с контролем выполнения операции через статусы в бд, либо через горутины (в случае с системами, которые не поддерживают коммуникацию через кафку)”
Т.е. у вас тут получился «зоопарк» кто с кем и как взаимодействует.
Если все в итоге льется в одну БД то при чем тут микро-сервисная архитектура? Только в том что части «монолита» в виде отдельных exe файлов выполнены?
Если строить распределенную архитектуру то имеет смысл в «центр» поставить систему обмена сообщениями. Или вашу Kafka, или RabbitMQ/ Matt. И плясать уже от этого. Тогда у вас не может быть сервисов которые «не поддерживают» вашу архитектуру обмена сообщениями.
По поводу фронт-енд на HTML - на приведенных вами скриншотах есть изображение автомобиля - выглядит прикольно но для обслуживания не нужно- занимает место, ресурсы. Достаточно просто написать марку и модель. Тогда большую часть интерфейса можно свести к табличному виду и ряду кнопок. Что упрощает фронт-енд и работу с ним.
Это на «трендово-молодежно» зато «дёшево,надежно и практично».
Привет!
В статье нигде не написано, что у наших микросервисов общая бд :) По умолчанию микросервисная архитектура подразумевает подход database per mocroservice, чего мы и придерживаемся.
Взаимодействие через Кафку ведется с теми системами, которые сейчас поддерживаются в компании. Но есть старые системы, в том числе и монолиты, которые поддерживают только REST и написаны на другом языке, а дописывать их никто не планирует. Что лучше - нанять нового разработчика, который разберется в монолите, докрутит к нему Кафку и спустя полгода задержек эта схема заработает, либо же отправить в монолит REST запрос отдельной горутиной?
Насчет HTML, не совсем понял ваш аргумент. Насчет HTML на стороне мобильного приложения дал ответ выше. Если вы говорите о реализации фронтенда на чистом HTML, то эта практика стала неактуальной уже году в 2010 в связи с тем, что плюсов в сравнении с тем же React у нее нет, а вот минусов полно
Я не вижу тут доводов за распределенную архитектуру, а вы?
Какие бывают доводы:
Требования к безопасности. Например, платежи почти всегда это отдельный модуль.
Уже есть несколько модулей, унаследованных или закупленных
Много команд разработки, сложности в их координации. Обычно, это играет роль при масштабе от 10 команд от 10 человек каждая. И только при условии что предметная область хорошо известна, не меняется. Иначе, изменение границ домена ведёт к большой переделке. Monolith first это не просто так придумали.
Чертов легаси, который надо сопровождать, но его никто не понимает
Мультитехнологические команды
Высокие требования к масштабированию (ага, не тянет на 100 ядерном сервере) или требования к географической распределенности
Ещё CI/ CD когда один из модулей меняется несколько раз в день. Но это решаемо и дешевле. Разве что если бизнес создаёт огромный поток ad-hoc нешаблонных задач, которые не будут развиваться, а команды перекинут через пару месяцев на другие галеры. Такой мусор, действительно, стоит изолировать в виде отдельного сервиса, чтобы стоял и не мешал никому.
Всё. Желание команды потренироваться это плохой довод.
Нет, просто монолиты были популярны в вашей молодости, сейчас тенденции другие
Простите, что не следуем канонам:)
Нет
Микросервисы это ваши грабли. Вы обязательно должны набить своих шишек если не можете учиться на чужом опыте. Но в итоге, вы сможете находить оптимальное архитектурное решение для каждой конкретной задачи. Я в вас верю!
И повторю конкретный пример: монолит бы вы написали вдвое быстрее. 11000 строк 3 человека 3 месяца это слишком долго (это ведь только бэк? Иначе совсем плохо)
Стоит все таки было написать монолитик?
Если бы вы внимательно читали, то поняли - мы закладывали архитектуру сразу, под дальнейшее развитие приложения - задач выполняемых через него, как и пользователей станет больше. И мы готовы к такому масштабированию, даже код почти дописывать не надо, все ляжет идеально.
Это и отличает грамотного архитектора который смотрит в будущее от разработчика, который хочет таким быть, но пока только пишет статьи с указанием сухих "функциональные и нефункциональные" требований и не думает наперед.
Ещё вариант масштабирования - поставить сервис помощнее. Я ужу несколько раз постил ссылки на статью автора DuckDB - что bid data is dead. По закону Мура мощность процессоров удваивается каждые сколько-там лет, т.е у вас экспоненциальный рост модности, а масштабирование с помощью микросервисов - линейный рост. Вы не можете удваивать их количество без увеличения машинной парка. Так что вы проиграете монолиту. Если бы вы были Amazon/ Uber и т.д. То да, экспансия на разные рыкни требует своих заморочек, но вы вроде пока не собираетесь туда выходить. А когда соберетесь - проблемы будут совсем другие
И повторю конкретный пример: монолит бы вы написали вдвое быстрее. 11000 строк 3 человека 3 месяца это слишком долго (это ведь только бэк? Иначе совсем плохо)
вот это в вас и выдает человека который не думает наперед. В решении между монолитом и микросервисной архитектурой выбрать первое, потому что написать монолит быстрее.
Все прям как у Галича:
"А то, что придется потом платить
Так ведь это ж, пойми, — потом!"
Ещё одна архитектурная ошибка тратить усилия на возможное масштабирование/ расширение если оно не подтверждено бизнесом деньгами. А вы уже потратили на это лишних 5-6 человеко месяцев.
Вы просто кладбище кладезь архитектурных ошибок.
А откуда у вас уверенность в этом? Судите, что это ошибка? А судьи то кто?:)
Пока складывается впечатление, что вы действительно не читали статью. Задач которые появятся в приложение будет около 150. Сейчас там всего 2 - это мойки машин. Для остальных и закладывалось это:)
Прошу вас, прочитайте вы уже статью, потратьте свое время, там все ответы на ваши не очень корректные, но язвительные комментарии. Надеюсь у вас все хорошо, а то прям токсом отдает:) При чем токсом такого явного сноба, который "я в IT с 80-х, а вы тут лезете"
Что вы пытаетесь доказать? Что нужно писать монолиты, вместо того, чтобы закладывать будущее? Повторюсь, мы уже активно переносим остальные задачи под ту архитектуру, что уже сделали:) Кстати, напишем об этом в отдельной статье, приглашу вас почитать, вряд ли вы до того момента сделаете что-то стоящее, чтобы об этом рассказать. Вот поэтому придется тащить нам, молодым :)
Удачи вам, ждем ваших успехов, присылайте почитать, как что-то будет
Молодость без башни. Я почти завидую.
А бизнесу это всё не важно. Просто я заработаю эти же деньги потратив меньше времени и усилий.
С нетерпением ждём продолжения. Очень хочется посмотреть как будет работать 150 задач закодированных.в JSON без изменения front-back-end..
на HTML бы точно завелось?
Это не я обещал реализовать фичи без изменения front-end и back-end кода. Но в общем и целом - да.
Идея REST в том что у вас систем самоописывающася, вот только чтобы все работало у вас фронт-енд должен по сложности приблизиться к браузеру :).
Поэтому упростить интерфейс - свести его в идеале к табличке
Параметр, значение, кнопки действия и передавать в виде server side generated html будет выходом.
Какая вам нужна фича в клиенте, которую html5 не поддерживает?
Прочитал ваше коммент в другой теме
"Я наконец то понял что такое микросервисы
Я мало работал с микросервисами и точно не видел когда их нужно сотни и тысячи."
Тут комментировать - только портить
оставим это тут:)
Платежи и наследованные модули (системы), это наверное будет интеграция, а не свой модуль в системе?
разный код? можно делать вызов внешних функций, будет быстрее чем сетовое
мусорные задачи - модули в базу
обновления - плагины?
Что остается только в микросервисе, чего не может монолит? ... остается только job security?
Что есть в монолите, чего не может микросервис - удобное тестирование, как минимум.
Такое впечатление, что автор путает одиночный сервер (единственны экземпляр приложения) и монолит. Нет, это не так. Можно весь код собрать в один deployable artifact и запускать их тысячи копий, каждую хоть, на своем железе - микросервисом это не станет. А как все будет работать - с Кафкой, grpc, или с разными базами, вообще без разницы.
Изоляция данных карт PAN, CVV и вообще персональные данные надо хранить в отдельном контуре с минимальным периметром взаимодействия с остальными частями. Правда, реально не все этим заморачиваются
Сильно зависит от сложности платежного модуля. Если это чужой модуль подключаемый через iframe то не надо
Вау! Очень круто
Я давний пользователь Ситидрайва и всегда была интересна операционка.
Есть 3 вопроса:
В поле компания указано везде citydrive. А есть другие? Предоставляете операционное обслуживание другим компаниям?
Как с самозанятостью присоединиться к вам и по возможности покатать машины на мойки и заправки?
Хочу работать с вами ♥️ (бывший QA-lead, ныне аналитик)
От монолита и чатов к FMS и FMS App: новый уровень управления каршерингом с автопарком 19 000+ авто