Там где база меняется - куда более глубокое обновление. Если мы представим какой-то большой проект с большой по объему и количеству хостов базой, то любое изменение структуры базы это не простой процесс
поэтому правила хорошего тона на больших проектах нанимать инженера который проектирует базу и разрабатывает схемы расширения. И если он проектирует так, что раз в год туда что-то добавляют нарушая фрагментацию…ну такой инженер и грустно будет всем на каждом обновлении, возможно даже с ночевкой в офисе
Я не ищу чистый код. Ищу внятную доку или хорошие комментарии. А если все работает, стараюсь не лезть по капот.
что такое чистый код сам по себе, в отрыве от языков
В отрыве от языков? Например в Golang жестко фиксировали язык при разработке и за это большое спасибо Гуглу. Любой чужой проект читается на одном дыхании.
Отсюда я делаю вывод что красиво писать - про язык, про наличие гайдов в публичном доступе на тему «как правильно».
Мне статья не понравилась, вода водой, про высокие материи и без понимания предмета
Я правильно прочитал статью: Вместо того чтобы потратить деньги на железо для расширения емкости, надо заставить менеджеров по финансам и разработки (если таких нет, нанять) заниматься FinOps чтобы распределять деньги на ресурсы которые стоят в 10-ки раз больше.
Безусловно облака ситуативно нужны, когда надо резко в моменте нарастить емкость каналов или распределить нагрузку. Но это ситуативно и всегда есть возможность это реализовать отдельно. Потому что при хорошей нагрузки счета будет равняться покупки сервера.
Берем пример счета в статье. 3 месяца и можно купить сервер в 4 раза превышающий емкость по RAM/CPU и памяти. Итого: Мы не смотрим на графики нагрузки, не считаем дельту, потому что ресурсов в 4 раза больше и их за глаза. Бухгалтерия пищит от счастья. Или я все равно не то что-то говорю?
Я вам описал полностью всю схему обновления. Если у вас есть критика этой схемы, то укажите шаг на котором кто-то может создать такую проблему что положит весь монолит и не даст собрать
Действительно, я плохо понимаю о чем вы говорите и создается впечатление что вы не понимаете что такое "монолит" и мы говорим о разном.
Как минимум потому что я могу только в страшном сне представить что такое монолит на php. Это хороший язык, но давайте не будет рожденного ходить заставлять летать. Краем глаза видел, добавили какую-то там ассинхронку через какие-то неведомые костыли. Честно, я не видел монолитов на PHP и не хочу видеть
И если там реально существует проект с 500+ разработчиками которые пилят на PHP монолит....у меня много вопросов. ОЧЕНЬ МНОГО ВОПРОСОВ
В данный момент я работаю с огромным монолитом на PHP.
В данный момент на монолите более 500+
Можно есть суп вилкой. Не пробовал, но говорят очень интересно. Удивительно что человек со стека java/kotlin участвует в этом и я пожелаю вам удачи.
Плохой пример, Выглядит как общая библиотека, если в ней что то поменять и не предупредить другие команды, я думаю многие много хороших слов скажут.
Вы точно знаете как работают репозитории?
import в go работает совсем по другому принципу. Если я добавляю какой-то внешний импорт из репозитория, то я должен инициализировать его через go mod. Т.е go его скачивает в момент установки и в проекте go.mod добавляет ссылку на локальную папку (cache) с ВЕРСИЕЙ. Вот для примера go.mod
И когда ты делаешь import github.com/shopspring/decimal то берется версия 1.3.1 которая находится локально на сервере разработки
Все тоже самое только в профиль и менее удобно на C++. Но вот так просто там кто-то поменял во внешнем пакете и у тебя нагнулась сборка – такого нет (уважаемые программисты на C++ не кидайте камни, я совсем чу-чуть знаю этот язык и местами его использую в стеке с Go. Возможно там есть какие-то другие варианты о которых я просто не знаю)
И когда к примеру мне надо сменить версию внешнего пакета я:
1. Создаю новую ветку 2. Обновляю один за другим пакеты 3. Тестирую 4. Если все хорошо, делаю merge (по-сути merge одного файла go.mod где меняет версия пакета из кэша на более новую)
И опять же – всегда есть ветки и пакеты могут находится внутри монолита. Каждым конкретным пакетом может заниматься команда и в конце делается merge. За счет строгой типизации ошибки сведены к минимуму.
И в заключение, если есть внешний пакет и нет защит от самого языка, то эту защиту должен предусмотреть тот кто руководит проектом. Если он этого не умеет – научить. Если не хочет...ну тут я не знаю какие бабки мне надо платить чтоб я согласился учавствовать в таком цирке шапито.
Потому что менеджер стал жертвой маркетинга или такой вариант не рассматривается?
Расскажу свежую историю.
Приходит мой друг и говорит: "можешь зайти оценить проект системы бронирования. Мне надо понять что делать с ним дальше" Он сразу сказал что её разрабатывал человек 5 лет назад который только учился программировать, сейчас его нет...а система тормозит. Надо что-то делать, клиенты жалуются.
Захожу на виртуалу мат.....много мата разного и красочного. Через пару часов я наконец понял как эта шайтан машина работает. Для человека который учился программировать он сделал невероятное, пусть и криво и выбрал технологии которые я бы никогда не выбрал.
Он использовал Nodejs и плохого в этом нет, смог подцепить всякие фреймворки и даже разобрался с многопоточностью из микросервисов. Краеугольным камнем стала база – Mongo DB. База выросла, стала тормозить. Более того там вопросы и к самой структуре базы. Лаги не только от того что она выросла, а и из-за того что в структуре допущены ошибки и Nodejs выполнял лишние действия.
После всей оценки мое заключение простое: Замена базы на более подходящую и переписывания всего проекта.Переписать все там проще, чем разбираться как это вообще работает чтобы производить какие-то модификации. Тем более проект реально не сложный с базовым функционалом без сложных функций.
На вот это заключение я от друга получил вопросы от которых сам удивился, не дословный диалог:
Д: А чем база тебя не устроила? Я: А вы почему Mongo выбрали? Д: Ну, я посмотрел везде про нее тогда писали. Решил выбрать её Я: Надо использовать простую базу типа Mysql, без всяких свистелок и перделок. Специалистов на данную базу больше чем на Mongo. В случае вот таких проблем когда программист ушел надо искать специалиста по Mongo. Д: Окей. А можно не переписывать? Тут пару фрилансеров смотрело, говорят можно просто микросервисов добавить и будет побыстрее ---
Я: Сколько они за это хотят? (в этот момент я уже выпал из реальности. Посмотреть на проект с Mongo DB и сказать что, а давайте его клонирумем и разрастемся еще больше. Хотя тормоз как в базе, так и в скриптовый части) Д: один 250к, другой 300-400k Я: Разработка с нуля за 3-4 недели будет стоить тебе у средней руки специалиста 400-500k рублей. Зато это будет красиво, будет работать быстро и надежно и на другой нормальной БД
Далее я объяснил что и как более подробно, все таки друг. Дал им знакомого который все сделал за 200к и за неделю. Писают кипятком Конец.
И я надеюсь вы увидели контекст истории. И про то как модные-молодежные базы попадают в прод и про то как лихо можно сказать слово "микросервисы" и сразу бабок нарубить.
И думаю менеджеры коим является мой друг искал фрилансеров по принципу: где-то услышал
Лично я вас не понимаю. Возьмем Golang, есть условно блок математики находящийся в пакете math. Сейчас, данный пакет находится в одном репозитории с монолитом и вдруг мне понадобилось чтобы этот пакет разрабатывали отдельно от центрального.
Я открываю новый репозитория, кладу туда math. Добавляю разрабов которые будут им заниматься и делаю импорт из нового места Монолит остается монолитом, т.к при сборке импортирует этот пакет просто с другого репозитория.
И так попилить можно весь проект на части. Но я бы делал кучу веток, которыми занимаются отдельные люди ответственные за модуль.
вероятность багов не меньше. зачастую если меньше кода, то его проще поддерживать и писать адекватные тесты.
Гениальную вещь пишите. В Монолите всегда кода меньше, потому что отсутствуют блоки соединения и мониторинга микросервисов
Разработчик вообще об этом не заботится.
Вы очень лихо как фокусник манипулируете словами. Это конечно замечательно, но пока что все ваши аргументы либо связаны с "плохими" разработчиками, либо у вас какие-то языки такие странные типа Nodejs и подобное где в принципе нормально монолит не сделать потому что они симулирую асинхронность и многопоточность.
Тут я хочу по поводу сети добавить один нюанс. Почему-то многие кто любят микросервисы забывают о том что сетевая нагрузка (не утилизация полосы, а именно CPU) стремится к нулю. Но это далеко от правды. Так что помимо точки отказа, там еще дополнительная нагрузка на CPU трафиком, который как вы правильно заметили при монолите сводится к нулю.
Код стоит из модулей/пакетов, раскинул их по разным репозиторием...и все. В чем проблема?
Раздолбайство не лечится архитектурой.
Это правда. Только в случае монолита вероятность проблем со сборкой увеличивается. У нормальной команды проблемы со сборкой должны вызвать как минимум дополнительные тесты. Да и в целом, выше писал что монолит заставляет делать тестов больше и вероятности багов просто меньше.
Если ты почитаешь статью, то автор говорит о том что разработка должна быть без сложностей
Выше уже написали, что в любом случае помимо кода самого функционала нужно писать или использовать фреймвяорки для того чтобы микросервисы общались. Это ли не есть усложнение?
не будет, у тебя отдельный микросервис у команды, она его деплоит когда хочет и никого не ждет. понятно что надо соблюсти все понятия обратносовместимости и версионнирования. но это полностью отвязывает от ожидания других команд.
Это при условии что микросервисы стоят не в цепочке. Т.е от отказа одного сервиса весь проект потеряет какую-то одну функцию. А если там все в цепочке, то истории: одна команда независимо разрабатывает и делает деплой – становится не более чем фантастикой. И хорошо если при такой системе просто все остановится. Но бывают более комичные случаи, когда все продолжает работать. Но результат одного микросервиса влияет на конечный результат всей системы.
Тут я хотел бы отметить, и думаю вы тоже это понимаете если есть условный монолит который утилизирует вычислительную мощность 1 условного сервера, то при появлении запроса на расширение этой мощности – доработать монолит для "клонирования" не является сверхзадачей. Это субъективно мое мнение.
Вы довольно четко попали в мою математику по соотношению 1:10 (у меня 1:8 получилось). Если представить гипотетическую ситуацию что некий проект начат с микросервисов и растет как на грибах...допустим, он вырос до 100 серверов. Рано или поздно кто-то появится и займется оптимизацией. Оптимизировать такое – дорого (я даже не говорю о том чтобы переписать все на монолит, а просто уменьшить количество микросервисов для увеличения утилизации ресурсов) и при всем при этом это надо все поддерживать чтобы работало. Ну и конечно не забываем о самом оборудовании, чем больше количество – тем больше отказов
А если мы возьмем обратную ситуацию, написан изначально монолит и хочется зачем-то перевести его на микросервис – это довольно просто будет, считай дробишь одно на какие-то части и налаживаешь связку. Хотя я не особо представляю такой кейс.
Пока честно, я пытаюсь представить различные кейсы в голове при каких условиях надо начинать проект с микросервисов и не могу их придумать. Может кто-то придет и расскажет свое видение, с удовольствием почитаю
Был проект который с самого начала писался мной, состоял он из *ярда микросервисов. Притом были микросервисы которые писал я, были те которые взяты с других проектов или сделаны другими людьми. Естественно, проект не обошло все то что любят сисадмины: много всяких разных виртуалок, кучу систем мониторинга каждого пука. Все выглядело как рождественская елка которую наряжали годами, там у тебя API с WS, там ZeroMQ...там еще что-то. И скажу честно, на тот момент я верил что система идеальна.
Но идеального нет и мир был прекрасен до того момента пока не появилась задача ускорить работу. И тут стоит отметить что сама задача имела четкое финансовое обоснование – быстрее, значит больше денег приносит.
Я начал поиски как же ускорить и то что лежало на поверхности – различные протоколы взаимодействия микросервисов. Во время теста зоопарка протоколов включая IPC и UDP даже дошел до варианта убить де/сериализацию с помощью байтового представления. Т.е пакет кидал прям в байтах чтобы избежать трату времени на разбор. Но результаты оказались скромные, если мне не изменяет память была 1мс, стало 0.4мс. Конечно, кому-то покажется что это результат-результат, но на самом деле это как раз ускорение на базе UDP протокола где использовался бинар и требовалось очень много переписывать. Т.е 0.6мс не стоят этого.
В итоге пришло все к думам на тему монолита. Мозг не хотел принимать эту схему, самые частые мысли – а если ошибка в коде, там же все рухнет. И привычка дело такое, что на первой стадии разработки мысли эти не покидали. Тогда мозг не хотел понимать, что если в одном из микросервисов ошибка – все и так не будет корректно работать
Год я переписывал это чудо. Помню что лишь через 2-3 месяца от начала разработки до меня стало доезжать насколько микросервисы – пережиток прошлого и некий рекламный булшит. Отчетливо помню, как при разработке отыгрывали старые привычки: "о тут надо же сделать мониторинг...а потом такой – а зачем тут мониторинг, оно и так имеет только два статуса: либо работает, либо все рухнуло сразу вместе с приложением"
И когда все было закончено и запущено в прод тогда-то и наступило осознание, что надо было делать это раньше. Не говорю о скорости взаимодействия, которое теперь измеряется в тысячах наносекунд, – все таки это специфическая задача конкретного проекта. Говорю о том что подход к коду стал "ответственнее", ушло кучу мусора в том числе различных мониторингов, виртуалок и тд...освободились ресурсы. Вот к примеру про ресурсы, с 8 серверов которые были загружены под 70% теперь все живет на одном. А эти 7 перепрофилировали на резерв и различные другие функции. Что освободится такое количество ресурсов даже в сказке представить никто не мог.
В заключение хочу сказать вот что. Безусловно, микросервисная архитектура имеет право на жизнь, где-то она действительно необходима (хотя после моего опыта придумать у меня не получается). Но если перевести в понятную математику, то получится что запустить условно приложение на микросервисах понадобится наверное на 20% времени меньше и это плюс...более быстрый запуск так сказать, но обслуживание потом будет тратить это время в геометрической прогрессии с увеличением самого проекта. И хорошо если это время чье-то чужое или оплачиваемое, а не ваше личное.
А потом когда все это купили и весь народ нанят, надо еще сверху купить 20% и потратить еще 50% человекоресурсов чтобы подключить/настроить/создать систему мониторинга. А то как же руководству потом показывать красивые графики?
Там кинули "какульку" в Go. Что какие-то паники среды и бла-бла-бла. Разрабатываю довольно высоконагруженныe ассинхронные приложения на нем, со сложными структурами. У меня таких проблем нет. Есть нюансы, есть где подумать…много иногда кода приходится писать лишнего…но чтоб так…не, такого нет.
из всех проблем Go которые мне не нравится - бинарные деревья. Они очень медленные по скорости. В моих приложениях нужна именно скорость исполнения и это то что печалит. Но от версии к версии становится быстрее. За последние 2 года они ускорились процентов на 20-30. Но не дотчгивают до раста и c++. поэтому пришлось немного подпрыгнуть и придумать обход этого узкого места.
ПС: прошел год, я не увидел (но и не сильно и пытался увидеть) статью где показан пример работы на Rust после которой сидишь и думаешь: «ну, да…на go сделать такое сложно или невозможно, или будет крайне медленно»
Да, знаю что некоторые блоки у различных корпораций переписаны на Rust (тот же Cloudflare), но это не является причиной для того чтобы бежать его и учить. И всегда может возникнуть вопрос: А может C++...специалистов, фреймворков и прочего для него как грязи.
Прошел год назад, когда перестраивал софт на монолит тк нужна была скорость обработки в наносекундах. Честно, я очень боялся, но когда все сделал - мир заиграл новыми красками. Нет тонн софта обслуги, упростилось проектирование api…пропали тонны протоколов для взаимодействия. Сократилось количество виртуалок…пропали ситуации когда какой-то там микросервис начинал жрать память, который делался при царе горохе. Потом сидишь и пытаешься вспомнить как он вообще работает.
Один минус - перезапуск монолита сложная задача, это надо проектировать при разработке.
а про эффективность вообще молчу, лично у меня нагрузка упала на 70% общая по серверам.
А на тему рациональности использования, хорошо звучит и правильно…дескать мяса много жрать тоже вредно. Но предполагаю что везде температура по больнице будет +- одна, просто рост в геометрической прогрессии и уследить за этим очень сложно
Справедливости ради, речь тут о тойоте. В ней не понятно когда и почему, но в мерседесах/бмв и точно в РР уже с 2016 года нет классической кан шины. Там МультиКан и т.п. каждый называет по своему. И уже там используется оптика для обмена, поэтому последние года «взломы» машин для перепрошивки или активаций каких-то функций стал появляются с большой задержкой.
на самом деле это и к лучшему. Но запчасти станут дороже. К примеру раньше были обычные тормоза…так сказать простые. А теперь новая можа - электрические. С одной стороны они очень крутые, с другой ты потом будешь очень рад узнать при ремонте что оказывается у тебя на суппорте тормоза не просто моторчик который колодку зажимает, а моторчик с мозгом который получает команды по оптике, просчитывает параметры и делает действия. И естественно это не ремонтируется и меняется блоком стоимость…вообщем вы поняли
При этом в инстаграмме китайцы продают классический ss пока что. Все таки повторюсь, классно что технологии есть, развиваются. Но пока они слишком избыточны.
а как эти новые технологии по скорости доступа, насколько все плохо или хорошо. Потому что классический ovpn рвет даже первую итерацию SS как тузик грелку. На сайтах в целом разницы не видишь, зато видно как проседает скорость при скачивании к примеру больших файлов с сайтов. Например тот же самый ютуб если запроксировать, заметно становится сразу на 4к роликах он прям туго начинает кэшировать
Статья интересная, так почитать что что-то там придумали. Но классический ShadowSocket избыточен на данный с chacha20. Китайцы ходят вроде на ура и без проблем. А на тему заглушек актуально наверное для тех кто предоставляет это как сервис. А когда ты и твои друзья условно пользуются одним сервером – вряд ли будут ползать искать
Сейчас у меня две виртуалки, одна в РФ и там нет роскомнадзора, другая в США для нетфликса и прочих сервисов которые наши айпи забанили. Заплатил сразу за год, обе обошлись мне в 2800 в сумме. 230 рублей/мес это не такие уж большие деньги за комфорт.
Поставил Shadowsocks одной командой, сделал sub для shadowrocket. Туда указал два сервера, и определил с помощь config какие ресурсы куда должны ходить. 4 месяца – идеально. Макбук и iphone ходит в зависимости от адреса через нужную проксю. Но большая часть в Direct.
Год назад выбирали язык на который переписывать высоконагруженный сервиcs. Было 3 варианта:
Golang, C++, Rust. После небольшого исследования в неделю, остались C++ и Golang. По итогу выбрали последний.
Хотели выбрать C++ он все же немного в наших задачах быстрее golang особенно в вопросе бинарных деревьев. Но победила быстрая разворачиваемость Golang. Притом базовых функций unsafe для доступа к DLL/SO библиотекам хватает. Собственно модуль который работает с бинарными деревьями написан на C++ и подключается в Golang
Почему не Rust ответ дали те люди которые и на C++ и на Rust. Когда в задаче всплывали сторонние библиотеки DLL и часть чужого кода С/С++ они сами же и отговаривали от Rust. Дополнительно поясняя что "какбэ" в данной задаче еще и жуткая "многопоточность" и опыта на C++ в этом у них значительно больше. И это мнение 10-ка человек. Притом когда я спрашивал ребят, а зачем Rust-то учили. Все без исключения ответили что-то из разряда: "Появилась задача на хайпе, решили попробовать что-то новое"
Моё личное мнение после исследования такое, отвечу с точки зрения бизнеса: 1. Найти другого программиста на С++ проще, чем искать на Rust. Я говорю не о разработчиках средней руки, а именно о тех кто решает сложные задачи. 2. Прибавки в скорости по бенчам по сравнению с С++ не увидел. Либо она настолько ничтожна что в современном мире можно списать на погрешность 3. Под С/С++ написано больше чем много. Если стоит вопрос подключения библиотек сторонних и не дай бог еще они "закрытые". Несмотря на совместимость какую-то и возможность подключения (хотя лично мне кажется она такая же как на golang, просто чуть лучше) я с трудом могу представить ситуацию:
"Нам нужно сделать приложение. Будем использовать 10 библиотек готовых, проверенных на C++ [список]. Поэтому очевидно что наше приложение будет на Rust"
4. Не мог не обратить внимание на то что те статьи и комментарии которые я читал еще тогда, собственно как и эта статья напоминает: "Rust это круто и узнав его ты станешь элитой. C++/golang/python....[плохое слово]". Очень мало статей банально на реализации действительно сложных задач. 95% статей собственно как это.
А теперь по статье:
"Проекты, такие как QUIC и HTTP/3"
насколько мне не изменяет память, это Cloudflare открыла исходники на языке Rust. И на сколько я помню там Google делал на C++ изначально. А то что Cloudflare решил на Rust не говорит ни о чем. Захотели и сделали. Могут себе позволить.
"Rust и Веб-разработка"
С трудом представляю реализацию всего этого, код ради кода. Мы хоть не пользуемся контейнерами типа кубов, но пользуемся микросервисной архитектурой. Последнее что приходит на ум вставлять в JS бинарный код чтобы сцеплять их с языком программирования. Хотя реализация REST/GRPC вполне самодостаточная и не требует специфичных знаний для 99.99999% веб приложений. Могу ошибаться конечно, но выглядит как какая-то херня.
Там где база меняется - куда более глубокое обновление. Если мы представим какой-то большой проект с большой по объему и количеству хостов базой, то любое изменение структуры базы это не простой процесс
поэтому правила хорошего тона на больших проектах нанимать инженера который проектирует базу и разрабатывает схемы расширения. И если он проектирует так, что раз в год туда что-то добавляют нарушая фрагментацию…ну такой инженер и грустно будет всем на каждом обновлении, возможно даже с ночевкой в офисе
Я не ищу чистый код. Ищу внятную доку или хорошие комментарии. А если все работает, стараюсь не лезть по капот.
В отрыве от языков? Например в Golang жестко фиксировали язык при разработке и за это большое спасибо Гуглу. Любой чужой проект читается на одном дыхании.
Отсюда я делаю вывод что красиво писать - про язык, про наличие гайдов в публичном доступе на тему «как правильно».
Мне статья не понравилась, вода водой, про высокие материи и без понимания предмета
Я правильно прочитал статью: Вместо того чтобы потратить деньги на железо для расширения емкости, надо заставить менеджеров по финансам и разработки (если таких нет, нанять) заниматься FinOps чтобы распределять деньги на ресурсы которые стоят в 10-ки раз больше.
Безусловно облака ситуативно нужны, когда надо резко в моменте нарастить емкость каналов или распределить нагрузку. Но это ситуативно и всегда есть возможность это реализовать отдельно. Потому что при хорошей нагрузки счета будет равняться покупки сервера.
Берем пример счета в статье. 3 месяца и можно купить сервер в 4 раза превышающий емкость по RAM/CPU и памяти.
Итого: Мы не смотрим на графики нагрузки, не считаем дельту, потому что ресурсов в 4 раза больше и их за глаза. Бухгалтерия пищит от счастья. Или я все равно не то что-то говорю?
Я вам описал полностью всю схему обновления. Если у вас есть критика этой схемы, то укажите шаг на котором кто-то может создать такую проблему что положит весь монолит и не даст собрать
Действительно, я плохо понимаю о чем вы говорите и создается впечатление что вы не понимаете что такое "монолит" и мы говорим о разном.
Как минимум потому что я могу только в страшном сне представить что такое монолит на php. Это хороший язык, но давайте не будет рожденного ходить заставлять летать. Краем глаза видел, добавили какую-то там ассинхронку через какие-то неведомые костыли.
Честно, я не видел монолитов на PHP и не хочу видеть
И если там реально существует проект с 500+ разработчиками которые пилят на PHP монолит....у меня много вопросов. ОЧЕНЬ МНОГО ВОПРОСОВ
Можно есть суп вилкой. Не пробовал, но говорят очень интересно.
Удивительно что человек со стека java/kotlin участвует в этом и я пожелаю вам удачи.
Вы точно знаете как работают репозитории?
import в go работает совсем по другому принципу. Если я добавляю какой-то внешний импорт из репозитория, то я должен инициализировать его через go mod. Т.е go его скачивает в момент установки и в проекте go.mod добавляет ссылку на локальную папку (cache) с ВЕРСИЕЙ.
Вот для примера go.mod
И когда ты делаешь import github.com/shopspring/decimal то берется версия 1.3.1 которая находится локально на сервере разработки
Все тоже самое только в профиль и менее удобно на C++. Но вот так просто там кто-то поменял во внешнем пакете и у тебя нагнулась сборка – такого нет (уважаемые программисты на C++ не кидайте камни, я совсем чу-чуть знаю этот язык и местами его использую в стеке с Go. Возможно там есть какие-то другие варианты о которых я просто не знаю)
И когда к примеру мне надо сменить версию внешнего пакета я:
1. Создаю новую ветку
2. Обновляю один за другим пакеты
3. Тестирую
4. Если все хорошо, делаю merge (по-сути merge одного файла go.mod где меняет версия пакета из кэша на более новую)
И опять же – всегда есть ветки и пакеты могут находится внутри монолита. Каждым конкретным пакетом может заниматься команда и в конце делается merge. За счет строгой типизации ошибки сведены к минимуму.
И в заключение, если есть внешний пакет и нет защит от самого языка, то эту защиту должен предусмотреть тот кто руководит проектом. Если он этого не умеет – научить. Если не хочет...ну тут я не знаю какие бабки мне надо платить чтоб я согласился учавствовать в таком цирке шапито.
Потому что менеджер стал жертвой маркетинга или такой вариант не рассматривается?
Расскажу свежую историю.
Приходит мой друг и говорит: "можешь зайти оценить проект системы бронирования. Мне надо понять что делать с ним дальше"
Он сразу сказал что её разрабатывал человек 5 лет назад который только учился программировать, сейчас его нет...а система тормозит. Надо что-то делать, клиенты жалуются.
Захожу на виртуалу мат.....много мата разного и красочного. Через пару часов я наконец понял как эта шайтан машина работает. Для человека который учился программировать он сделал невероятное, пусть и криво и выбрал технологии которые я бы никогда не выбрал.
Он использовал Nodejs и плохого в этом нет, смог подцепить всякие фреймворки и даже разобрался с многопоточностью из микросервисов. Краеугольным камнем стала база – Mongo DB. База выросла, стала тормозить. Более того там вопросы и к самой структуре базы. Лаги не только от того что она выросла, а и из-за того что в структуре допущены ошибки и Nodejs выполнял лишние действия.
После всей оценки мое заключение простое: Замена базы на более подходящую и переписывания всего проекта.Переписать все там проще, чем разбираться как это вообще работает чтобы производить какие-то модификации. Тем более проект реально не сложный с базовым функционалом без сложных функций.
На вот это заключение я от друга получил вопросы от которых сам удивился, не дословный диалог:
Д: А чем база тебя не устроила?
Я: А вы почему Mongo выбрали?
Д: Ну, я посмотрел везде про нее тогда писали. Решил выбрать её
Я: Надо использовать простую базу типа Mysql, без всяких свистелок и перделок. Специалистов на данную базу больше чем на Mongo. В случае вот таких проблем когда программист ушел надо искать специалиста по Mongo.
Д: Окей. А можно не переписывать? Тут пару фрилансеров смотрело, говорят можно просто микросервисов добавить и будет побыстрее
---
Я: Сколько они за это хотят? (в этот момент я уже выпал из реальности. Посмотреть на проект с Mongo DB и сказать что, а давайте его клонирумем и разрастемся еще больше. Хотя тормоз как в базе, так и в скриптовый части)
Д: один 250к, другой 300-400k
Я: Разработка с нуля за 3-4 недели будет стоить тебе у средней руки специалиста 400-500k рублей. Зато это будет красиво, будет работать быстро и надежно и на другой нормальной БД
Далее я объяснил что и как более подробно, все таки друг. Дал им знакомого который все сделал за 200к и за неделю. Писают кипятком
Конец.
И я надеюсь вы увидели контекст истории. И про то как модные-молодежные базы попадают в прод и про то как лихо можно сказать слово "микросервисы" и сразу бабок нарубить.
И думаю менеджеры коим является мой друг искал фрилансеров по принципу: где-то услышал
Лично я вас не понимаю.
Возьмем Golang, есть условно блок математики находящийся в пакете math. Сейчас, данный пакет находится в одном репозитории с монолитом и вдруг мне понадобилось чтобы этот пакет разрабатывали отдельно от центрального.
Я открываю новый репозитория, кладу туда math. Добавляю разрабов которые будут им заниматься и делаю импорт из нового места
Монолит остается монолитом, т.к при сборке импортирует этот пакет просто с другого репозитория.
И так попилить можно весь проект на части. Но я бы делал кучу веток, которыми занимаются отдельные люди ответственные за модуль.
Гениальную вещь пишите. В Монолите всегда кода меньше, потому что отсутствуют блоки соединения и мониторинга микросервисов
Вы очень лихо как фокусник манипулируете словами. Это конечно замечательно, но пока что все ваши аргументы либо связаны с "плохими" разработчиками, либо у вас какие-то языки такие странные типа Nodejs и подобное где в принципе нормально монолит не сделать потому что они симулирую асинхронность и многопоточность.
Тут я хочу по поводу сети добавить один нюанс. Почему-то многие кто любят микросервисы забывают о том что сетевая нагрузка (не утилизация полосы, а именно CPU) стремится к нулю. Но это далеко от правды. Так что помимо точки отказа, там еще дополнительная нагрузка на CPU трафиком, который как вы правильно заметили при монолите сводится к нулю.
Код стоит из модулей/пакетов, раскинул их по разным репозиторием...и все. В чем проблема?
Это правда. Только в случае монолита вероятность проблем со сборкой увеличивается. У нормальной команды проблемы со сборкой должны вызвать как минимум дополнительные тесты. Да и в целом, выше писал что монолит заставляет делать тестов больше и вероятности багов просто меньше.
Выше уже написали, что в любом случае помимо кода самого функционала нужно писать или использовать фреймвяорки для того чтобы микросервисы общались. Это ли не есть усложнение?
Это при условии что микросервисы стоят не в цепочке. Т.е от отказа одного сервиса весь проект потеряет какую-то одну функцию. А если там все в цепочке, то истории: одна команда независимо разрабатывает и делает деплой – становится не более чем фантастикой.
И хорошо если при такой системе просто все остановится. Но бывают более комичные случаи, когда все продолжает работать. Но результат одного микросервиса влияет на конечный результат всей системы.
Тут я хотел бы отметить, и думаю вы тоже это понимаете если есть условный монолит который утилизирует вычислительную мощность 1 условного сервера, то при появлении запроса на расширение этой мощности – доработать монолит для "клонирования" не является сверхзадачей. Это субъективно мое мнение.
Вы довольно четко попали в мою математику по соотношению 1:10 (у меня 1:8 получилось). Если представить гипотетическую ситуацию что некий проект начат с микросервисов и растет как на грибах...допустим, он вырос до 100 серверов. Рано или поздно кто-то появится и займется оптимизацией. Оптимизировать такое – дорого (я даже не говорю о том чтобы переписать все на монолит, а просто уменьшить количество микросервисов для увеличения утилизации ресурсов) и при всем при этом это надо все поддерживать чтобы работало. Ну и конечно не забываем о самом оборудовании, чем больше количество – тем больше отказов
А если мы возьмем обратную ситуацию, написан изначально монолит и хочется зачем-то перевести его на микросервис – это довольно просто будет, считай дробишь одно на какие-то части и налаживаешь связку. Хотя я не особо представляю такой кейс.
Пока честно, я пытаюсь представить различные кейсы в голове при каких условиях надо начинать проект с микросервисов и не могу их придумать. Может кто-то придет и расскажет свое видение, с удовольствием почитаю
Расскажу свою историю
Был проект который с самого начала писался мной, состоял он из *ярда микросервисов. Притом были микросервисы которые писал я, были те которые взяты с других проектов или сделаны другими людьми. Естественно, проект не обошло все то что любят сисадмины: много всяких разных виртуалок, кучу систем мониторинга каждого пука. Все выглядело как рождественская елка которую наряжали годами, там у тебя API с WS, там ZeroMQ...там еще что-то. И скажу честно, на тот момент я верил что система идеальна.
Но идеального нет и мир был прекрасен до того момента пока не появилась задача ускорить работу. И тут стоит отметить что сама задача имела четкое финансовое обоснование – быстрее, значит больше денег приносит.
Я начал поиски как же ускорить и то что лежало на поверхности – различные протоколы взаимодействия микросервисов. Во время теста зоопарка протоколов включая IPC и UDP даже дошел до варианта убить де/сериализацию с помощью байтового представления. Т.е пакет кидал прям в байтах чтобы избежать трату времени на разбор. Но результаты оказались скромные, если мне не изменяет память была 1мс, стало 0.4мс. Конечно, кому-то покажется что это результат-результат, но на самом деле это как раз ускорение на базе UDP протокола где использовался бинар и требовалось очень много переписывать. Т.е 0.6мс не стоят этого.
В итоге пришло все к думам на тему монолита. Мозг не хотел принимать эту схему, самые частые мысли – а если ошибка в коде, там же все рухнет. И привычка дело такое, что на первой стадии разработки мысли эти не покидали. Тогда мозг не хотел понимать, что если в одном из микросервисов ошибка – все и так не будет корректно работать
Год я переписывал это чудо. Помню что лишь через 2-3 месяца от начала разработки до меня стало доезжать насколько микросервисы – пережиток прошлого и некий рекламный булшит. Отчетливо помню, как при разработке отыгрывали старые привычки: "о тут надо же сделать мониторинг...а потом такой – а зачем тут мониторинг, оно и так имеет только два статуса: либо работает, либо все рухнуло сразу вместе с приложением"
И когда все было закончено и запущено в прод тогда-то и наступило осознание, что надо было делать это раньше. Не говорю о скорости взаимодействия, которое теперь измеряется в тысячах наносекунд, – все таки это специфическая задача конкретного проекта. Говорю о том что подход к коду стал "ответственнее", ушло кучу мусора в том числе различных мониторингов, виртуалок и тд...освободились ресурсы. Вот к примеру про ресурсы, с 8 серверов которые были загружены под 70% теперь все живет на одном. А эти 7 перепрофилировали на резерв и различные другие функции. Что освободится такое количество ресурсов даже в сказке представить никто не мог.
В заключение хочу сказать вот что. Безусловно, микросервисная архитектура имеет право на жизнь, где-то она действительно необходима (хотя после моего опыта придумать у меня не получается). Но если перевести в понятную математику, то получится что запустить условно приложение на микросервисах понадобится наверное на 20% времени меньше и это плюс...более быстрый запуск так сказать, но обслуживание потом будет тратить это время в геометрической прогрессии с увеличением самого проекта. И хорошо если это время чье-то чужое или оплачиваемое, а не ваше личное.
А потом когда все это купили и весь народ нанят, надо еще сверху купить 20% и потратить еще 50% человекоресурсов чтобы подключить/настроить/создать систему мониторинга. А то как же руководству потом показывать красивые графики?
Там кинули "какульку" в Go. Что какие-то паники среды и бла-бла-бла. Разрабатываю довольно высоконагруженныe ассинхронные приложения на нем, со сложными структурами. У меня таких проблем нет. Есть нюансы, есть где подумать…много иногда кода приходится писать лишнего…но чтоб так…не, такого нет.
из всех проблем Go которые мне не нравится - бинарные деревья. Они очень медленные по скорости. В моих приложениях нужна именно скорость исполнения и это то что печалит. Но от версии к версии становится быстрее. За последние 2 года они ускорились процентов на 20-30. Но не дотчгивают до раста и c++. поэтому пришлось немного подпрыгнуть и придумать обход этого узкого места.
ПС: прошел год, я не увидел (но и не сильно и пытался увидеть) статью где показан пример работы на Rust после которой сидишь и думаешь: «ну, да…на go сделать такое сложно или невозможно, или будет крайне медленно»
Да, знаю что некоторые блоки у различных корпораций переписаны на Rust (тот же Cloudflare), но это не является причиной для того чтобы бежать его и учить. И всегда может возникнуть вопрос: А может C++...специалистов, фреймворков и прочего для него как грязи.
Прошел год назад, когда перестраивал софт на монолит тк нужна была скорость обработки в наносекундах. Честно, я очень боялся, но когда все сделал - мир заиграл новыми красками. Нет тонн софта обслуги, упростилось проектирование api…пропали тонны протоколов для взаимодействия. Сократилось количество виртуалок…пропали ситуации когда какой-то там микросервис начинал жрать память, который делался при царе горохе. Потом сидишь и пытаешься вспомнить как он вообще работает.
Один минус - перезапуск монолита сложная задача, это надо проектировать при разработке.
а про эффективность вообще молчу, лично у меня нагрузка упала на 70% общая по серверам.
А на тему рациональности использования, хорошо звучит и правильно…дескать мяса много жрать тоже вредно. Но предполагаю что везде температура по больнице будет +- одна, просто рост в геометрической прогрессии и уследить за этим очень сложно
Справедливости ради, речь тут о тойоте. В ней не понятно когда и почему, но в мерседесах/бмв и точно в РР уже с 2016 года нет классической кан шины. Там МультиКан и т.п. каждый называет по своему. И уже там используется оптика для обмена, поэтому последние года «взломы» машин для перепрошивки или активаций каких-то функций стал появляются с большой задержкой.
на самом деле это и к лучшему. Но запчасти станут дороже. К примеру раньше были обычные тормоза…так сказать простые. А теперь новая можа - электрические. С одной стороны они очень крутые, с другой ты потом будешь очень рад узнать при ремонте что оказывается у тебя на суппорте тормоза не просто моторчик который колодку зажимает, а моторчик с мозгом который получает команды по оптике, просчитывает параметры и делает действия. И естественно это не ремонтируется и меняется блоком стоимость…вообщем вы поняли
При этом в инстаграмме китайцы продают классический ss пока что. Все таки повторюсь, классно что технологии есть, развиваются. Но пока они слишком избыточны.
а как эти новые технологии по скорости доступа, насколько все плохо или хорошо. Потому что классический ovpn рвет даже первую итерацию SS как тузик грелку. На сайтах в целом разницы не видишь, зато видно как проседает скорость при скачивании к примеру больших файлов с сайтов. Например тот же самый ютуб если запроксировать, заметно становится сразу на 4к роликах он прям туго начинает кэшировать
Статья интересная, так почитать что что-то там придумали. Но классический ShadowSocket избыточен на данный с chacha20. Китайцы ходят вроде на ура и без проблем. А на тему заглушек актуально наверное для тех кто предоставляет это как сервис. А когда ты и твои друзья условно пользуются одним сервером – вряд ли будут ползать искать
Сейчас у меня две виртуалки, одна в РФ и там нет роскомнадзора, другая в США для нетфликса и прочих сервисов которые наши айпи забанили. Заплатил сразу за год, обе обошлись мне в 2800 в сумме. 230 рублей/мес это не такие уж большие деньги за комфорт.
Поставил Shadowsocks одной командой, сделал sub для shadowrocket. Туда указал два сервера, и определил с помощь config какие ресурсы куда должны ходить. 4 месяца – идеально. Макбук и iphone ходит в зависимости от адреса через нужную проксю. Но большая часть в Direct.
Отдельно доставляет как Rust в обоих списках занимает лидирующие места :)
Год назад выбирали язык на который переписывать высоконагруженный сервиcs. Было 3 варианта:
Golang, C++, Rust. После небольшого исследования в неделю, остались C++ и Golang. По итогу выбрали последний.
Хотели выбрать C++ он все же немного в наших задачах быстрее golang особенно в вопросе бинарных деревьев. Но победила быстрая разворачиваемость Golang. Притом базовых функций unsafe для доступа к DLL/SO библиотекам хватает. Собственно модуль который работает с бинарными деревьями написан на C++ и подключается в Golang
Почему не Rust ответ дали те люди которые и на C++ и на Rust. Когда в задаче всплывали сторонние библиотеки DLL и часть чужого кода С/С++ они сами же и отговаривали от Rust. Дополнительно поясняя что "какбэ" в данной задаче еще и жуткая "многопоточность" и опыта на C++ в этом у них значительно больше. И это мнение 10-ка человек. Притом когда я спрашивал ребят, а зачем Rust-то учили. Все без исключения ответили что-то из разряда:
"Появилась задача на хайпе, решили попробовать что-то новое"
Моё личное мнение после исследования такое, отвечу с точки зрения бизнеса:
1. Найти другого программиста на С++ проще, чем искать на Rust. Я говорю не о разработчиках средней руки, а именно о тех кто решает сложные задачи.
2. Прибавки в скорости по бенчам по сравнению с С++ не увидел. Либо она настолько ничтожна что в современном мире можно списать на погрешность
3. Под С/С++ написано больше чем много. Если стоит вопрос подключения библиотек сторонних и не дай бог еще они "закрытые". Несмотря на совместимость какую-то и возможность подключения (хотя лично мне кажется она такая же как на golang, просто чуть лучше) я с трудом могу представить ситуацию:
"Нам нужно сделать приложение. Будем использовать 10 библиотек готовых, проверенных на C++ [список]. Поэтому очевидно что наше приложение будет на Rust"
4. Не мог не обратить внимание на то что те статьи и комментарии которые я читал еще тогда, собственно как и эта статья напоминает: "Rust это круто и узнав его ты станешь элитой. C++/golang/python....[плохое слово]". Очень мало статей банально на реализации действительно сложных задач. 95% статей собственно как это.
А теперь по статье:
"Проекты, такие как QUIC и HTTP/3"
насколько мне не изменяет память, это Cloudflare открыла исходники на языке Rust. И на сколько я помню там Google делал на C++ изначально. А то что Cloudflare решил на Rust не говорит ни о чем. Захотели и сделали. Могут себе позволить.
"Rust и Веб-разработка"
С трудом представляю реализацию всего этого, код ради кода. Мы хоть не пользуемся контейнерами типа кубов, но пользуемся микросервисной архитектурой. Последнее что приходит на ум вставлять в JS бинарный код чтобы сцеплять их с языком программирования. Хотя реализация REST/GRPC вполне самодостаточная и не требует специфичных знаний для 99.99999% веб приложений. Могу ошибаться конечно, но выглядит как какая-то херня.