Хорошо-хорошо, я и из прошлого сообщения прекрасно понял, что вам не нравится Твиттер, нравятся изменения в Твиттере и не нравятся новости о Маске/Твиттере на Хабре. Однако не понимаю, почему вы это противопоставляете моему замечанию относительно потенциальной важности таких новостей, да еще и постоянно передергиваете: я ведь не говорил ни о качестве, ни о запретах там, ни о запретах здесь. Хотите поговорить - давайте поговорим, но попрошу не использовать меня как манекен для упражнений в словоблудии, да еще и с подобной лексикой.
Ну... Скопировать Джобса кому-то удалось, чтобы следовать примеру Маска?)
При чем тут Джобс? Посыл всей этой истории с Твиттером достаточно простой и доступный для эксперимента: "можно разогнать всех этих тупых бездельников и станет лучше". Для этого вовсе не надо пытаться создавать культ личности или строить транснациональные корпорации, достаточно иметь нескольких подчиненных.
"в одной из крупнейших айтишных компаний" - которая жила сама в себе и по факту была пузырём? Кучу народу разогнали. Твиттер не рухнух, а наконец начал хоть какие то признаки жизни подавать.
К чему это уничижение? Твиттер, тухлый или нет, - заметная точка на картине мира, у него огромная аудитория и уже много лет. А рухнул или не рухнул - еще рано судить имхо, запас прочности неизвестен. Кстати, соседние новости не радуют: https://habr.com/ru/news/t/720888/
"Некоторые компании следуют примеру" - идиотов везде хватает. Вы о корпоративной культуре и её реализации в СНГ забыли?
Идиотов везде хватает, иногда мы даже на них работаем. А вообще этот ваш тезис кажется несколько противоречивым: изменения в Твиттере вы явно считаете положительными, но руководителей, которые попробуют делать так же, считаете идиотами? Корпоративная культура в СНГ меняется. Да и многие нынче работают не в СНГ.
Давайте прямо: что могло и коснулось хабровчан тут - умалчивается, а вот всякая мелкая хайповая фигня - пожалуйста. Или реально считаете, что бредовые новости о Маске важнее?
Пожалуйста, не передергивайте: никто ведь не заставляет публиковать строго либо одно, либо другое. Или вы реально считаете, что некоторые темы недостаточно освещаются из-за новостей о Маске?
Мне кажется, вы зря сыпете сарказмом, потому что игнорируете ключевые моменты. Если бы это была новость, что "какой-то миллиардер нанял пару охранников", то я бы с вами согласился. Конкретно здесь примечательно, что охрана теперь (она и раньше существовала) сопровождает Маска внутри офиса Твиттера, куда просто так с улицы не зайдешь - это явный признак опасения угрозы со стороны сотрудников, что выглядит особенно контрастно на фоне "обнимашек" в прошлом. А в целом имхо новость здесь не потому, что "невообразимый Илон Маск", а потому что касается нашумевшей и продолжающейся истории с радикальными переделками в одной из крупнейших айтишных компаний. Некоторые компании следуют примеру, так что происходящее вполне может так или иначе стать трендом, а это уже может даже коснуться и хабровчан.
Зацепил момент с лидерами и аутсайдерами охвата. Это действительно так просто - одни молодцы, а другие нет? Когда речь заходит о коммуникациях, всегда есть противопоставление двух типов личностей, обычно (и не совсем точно) называемых экстравертами и интровертами. Как бы не получилось, что есть лидер по охвату и вовлеченности, который целыми днями общается со всеми подряд, но ничего толком не делает - и он хороший, а есть аутсайдер, который молча в углу что-то там пилит и делает почти всю работу - и он плохой. Можно ли, так сказать, "переходить на личности"? Кажется, что вовлеченность очень общий показатель, хорошо работает только на среднем/большом масштабе и только в совокупности с другими как косвенный признак, что именно в команде не так. Если команда выглядит невовлеченной, но по прочим признакам не особо отличается от остальных - надо ли вмешиваться?
Именно. Если подробнее, то операции и их порядок примерно (я все же тут не эксперт) таковы:
int (int n) {
int * ptr = malloc(sizeof(int));
*ptr = 1;
free(ptr);
return n+1;
}
На входе в контекст (грубо говоря, в функцию) в конце стека выделяется место под n, возвращаемый результат и ptr, как если бы все объявления переменных были смещены в начало функции и не имели инициализации значением. В аргумент же автоматически копируется значение из места вызова. До самого конца размер стека не меняется. И этот пункт стоит уточнить, поскольку аргументы функций (первые 4, кажется) и возвращаемые значения могут передаваться даже не через оперативку, а через регистры процессора.
У кучи запрашивается непрерывный кусок памяти размера sizeof(int). Если в свободных областях есть такое место, то куча его отделит по размеру, пометит занятым и отдаст указатель на начало области. Если же сводного места нет вовсе, или есть, но оно фрагментировано, т.е. состоит из нескольких частей меньшего требуемого размера и не идущих подряд, то куча сообщает операционке, что увеличивает свой размер. Операционка в свою очередь проверит, не превышает ли процесс заданный лимит на память, и подыскивает в физической памяти кусок нужного размера. Тут надо отметить, что память процесса - виртуальная, "лоскутная". Операционка сшивает несколько разных областей памяти, которые могут быть даже на разных типах устройств, и создает новое адресное пространство, которые выглядит цельным и непрерывным для процесса. Куча поэтому просто сообщает операционке, что хочет вырасти на определенный размер, а операционка подшивает к виртуальной памяти еще один кусок физической. Получив еще памяти, куча теперь может выделить запрошенный через malloc кусок или бросить исключение, если не получилось.
В стековую переменную ptr записывается адрес начала выделенной кучей области.
Из стековой переменной ptr считывается хранящийся там адрес в куче.
По считанному адресу в куче записывается интовая единица.
Куча получает запрос на освобождение: она помечает у себя, что область, начинающаяся с ptr, теперь свободна и снова может быть использована. Если есть соседние свободные области, то куча их объединит в одну большую, а при определенных условиях может еще и память операционке вернуть (тут уже подробностей совсем не знаю). На каждый malloc со временной выделенной областью должен приходиться ровно один free с тем же адресом.
По адресу возвращаемого результата на стеке записывается интовое n+1.
На завершении контекста у n и ptr вызвался бы деструктор, не будь они базовыми типами.
В месте вызова этой функции используется адрес ее возвращаемого значения, а указатель конца стека смещается до того положения, где он был до вызова. То же замечание, что и к пункту 1.
@stalker320, пожалуйста, удалите упоминание меня из статьи :) ну или хотя бы давайте уберем или поправим те пару абзацев про стек и кучу, а то вы хоть и молодец, что трудитесь над исправлением/дополнением, но все же странных вещей написали.
WARNING: написанное я все равно не стал бы включать в статью, т.к. сильно упрощал и оставил много неточностей. Это слишком обширная и сложная тема.
Стек вы описали как просто тип данных, а не модель памяти. Это маленькая область памяти ограниченного размера, в него попадают, если коротко, локальные переменные, аргументы функций и возвращаемые значения. Вызвали функцию - положили в конец аргументы, продвинулись по стеку. Создали переменную - еще продвинулись. Вызвали еще функцию - еще дальше ушли. Вышли из функции - локальные переменные и аргументы стали не нужны и мы просто вернулись по стеку обратно.
Про кучу и динамически выделяемые данные не очень понятно получилось. Данные-то вполне могут быть динамическими, но размещаться в стеке, а важно тут выделение области памяти: стек ее получает статически, однократно при запуске программы, а куча может меняться в процессе работы программы, сколько операционка позволяет процессу: нет в уже имеющейся памяти непрерывного куска нужного размера - запросили у операционки (на самом деле тут одновременно и сложнее, и проще, т.к. это виртуальная память) еще кусок памяти и продолжаем в ней сами себе выделять области - этим занимается рантайм языка. И наоборот, когда память освобождается, то она может вернуться операционке. За счет этих манипуляций выделение памяти в куче медленее, чем на стеке. "Куча может в программе и не появиться" - это все-таки контролируется вручную, т.к. такое ограничение могут накладывать целевые платформы - микроконтроллеры, например. Еще из важных отличий, что в куче можно хранить куда бОльшие объемы данных (стек же маленький) и ее можно шарить между потоками (у потоков собственные стеки).
В очистке памяти вы описали затирание данных с точки зрения безопасности, а не возвращение в кучу, что, собственно, в контексте управления памятью обычно очисткой и называется. Вот вы запросили в куче память, получили указатель. Куча у себя отметила, что область с N по N' занята, ее больше нельзя использовать при последующих запросах. Когда эта область перестала быть вам нужна, куча-то все еще считает, что память занята. А если вы даже и указатель не сохранили, то получается классическая утечка памяти: область занята, но у нас практически нет возможности это понять и ее освободить для дальнейшего использования, она так и будет висеть мертвым грузом до завершения процесса. Вот для этого возвращения и нужна очистка через free: куча отмечает область свободной и может вам в дальнейшем снова выдать в ней место даже без обращения к операционке.
Не минусовал и уж точно не гений, но выскажу предположения.
Для начала статья по объему и полноте на руководство имхо, уж извините, совсем не тянет. В статье про память ни разу даже не упомянули стек и кучу, страницы памяти и кеш, не объяснили, как пользоваться и зачем вообще нужны malloc/free и очень-очень много чего еще. Этому явно способствует еще и ваш личный контекст, словно (вы даже это упомянули) пишете только о том, что сами недавно узнали/уточнили, и спешите с кем-то поделиться новостями.
Довольно много неточных/спорных утверждений, а это огромный минус для обучающего материала.
Наконец, для кого вы писали? Из новичков имхо мало кому поможет, слишком обрывочные сведения и неясен порог входа, а ведь в обучении очень важны системность и последовательность. Более опытные не увидят ни новых фактов, ни приемов/практик. Получается, что у статьи толком нет аудитории, ее некому положительно оценить.
Ну и несколько вещей, которые мне кольнули глаз:
Указатели [...] При этом мы не сами выделяем память, а просим операционную систему выделить память нам нужное количество байтов.
За всю статью об управлении памятью не были даже упомянуты стек и куча - собственно, память программы. Сам по себе указатель не требует выделения памяти через *alloc - у вас ниже даже пример такой есть, с использованием ссылки. Самой кучи, кстати, может вовсе не быть.
Итак, перед тем, как рассказывать про байты, я приведу один точный пример, чтобы разубедить всех, что программирование работает с битами.
Программирование вполне работает с битами: в подавляющем большинстве языков есть как минимум битовые операции и даже распространенные приемы - битовая маска, например. Наверное, хотели сказать, что минимальная адресуамая единица - это байт, но сказали не это.
И если привести одну структуру к другой, даже если они имеют одинаковый размер, невозможно, то union позволяет сотворить чудо.
Union позволяет хакнуть информацию о типе: положили под одним, прочитали словно там другой, но при этом мы потеряли часть гарантий, которые давал компилятор, а это неиссякаемый источник ошибок, так что чудо довольно грязное. И это не единственный способ: того же можно добиться, например, кастом через указатель или копированием памяти.
Указатель - это число с размером разрядности компьютера. Но даже если размер не совпадает с разрядностью, размер указателя точно будет совпадать с размером uintptr_t.
Так размер совпадает или не совпадает с "разрядностью компьютера"?
*pvalue += 1; // обращаемся к значению и увеличиваем на один. // *(px++) (Или *px++) - это получить значение и сместить указатель на байт.
В отрыве от разбора операций и комбинаций (" px++", "*(++px)", "(*px)++" и т.д.) выглядит заклинанием.
Массив указателей можно назвать списком из python. Правда отсутствие записи информации о типах данных различных элементов делает его сложным для обработки, хотя это решается структурами.
Используете термин из другого языка, известный вам, но не объясняете его читателю.
Прощу прощения за надоедливость и малограмотность в вопросе, но я пытаюсь разобраться и все еще не понимаю, хотя и приближаюсь.
В случае с ВВП и вмененной рентой все хорошо, не вижу проблем. Допустим, была аренда квартиры на сумму N рублей, учтенная в ВВП. Арендатор получил услугу, арендодатель - деньги. Затем владелец сам въехал в квартиру. Услугу по предоставлению жилья он оказывает сам себе в том же объеме, но обмена на деньги не происходит, поэтому стоимость труда оказывается не учтена - это просто недостаток способа фиксации через денежные транзакции. Для фиксации таких результатов труда придумали виртуальный показатель, предположение, сколько могла бы стоить эта услуга, будь она оказана другому человеку - вмененная рента. Точно так же можно было бы учитывать, например, услугу по завариванию кофе самому себе с утра. Здесь вмененная рента нужна, т.к. ВВП пытается выразить результат всего человеческого труда в деньгах. Я потрудился и создал/оказал услугу стоимостью N рублей - если для себя, то получил саму услугу, если для другого - то получил возмещение в N рублей. Результат труда в любом случае оказался оценен.
Вы же говорите о вмененной ренте лишь как о постоянном расходе, хотя и сами упоминаете, что показатель состоит одновременно из дохода и расхода на одну и ту же сумму. Учитываете расход, но почему-то игнорируете доход. Хотя даже по вашей ссылке на статью вполне конкретно говорится, что вмененную ренту можно считать частью чистого дохода. Вот этот момент для меня совершенно непонятен, т.к. получаются деньги вникуда, которыми вы компенсируете скачок коэффициента.
Вернемся к арендатору и владельцу. Владелец потрудился, создал услугу по предоставлению жилья и сам же эту услугу потребил. У него есть расход труда на оказание услуги и доход в виде ее результатов, деньги в процессе не участвуют. Арендатор потребил услугу своего арендодателя, обменяв ее на деньги, но сам не создал никакой ценности, труд арендатора в процессе не поучаствовал. Получается разница: оба получили услугу, но арендатор затратил деньги, а владелец затратил свой труд. Можно ли одно к другому приравнять? Рыночная стоимость одинакова, но покупка услуги по предоставлению жилья все-таки уменьшает запас денег арендатора быстрее, чем у владельца. Если отходить от "странной модели с деньгами под матрасом", то вместе со вмененной рентой надо учитывать состояние финансового рынка и рынка жилья, ведь только заметное превалирование роста вложений над изменением цен на жилье может поднять арендатора до уровня владельца по совокупной стоимости имущества. Если же не переусложнять, то для выравнивания имхо надо либо сказать, что расчет предполагает определенное состояние рынков, либо как-то учесть, что арендатор меньше трудится - это потенциальный доход.
По сравнению в стартовой точке согласен, т.к. можно в момент времени сконвертировать все имущество в денежный эквивалент, таким образом поставив арендатора и владельца в абсолютно равные условия, так что останется сравнить лишь их капитал и расходы. Но если не учитывать особенности различных ситуаций, то показатель будет строиться лишь на обезличенных данных в прошлом, что серьезно уменьшает предсказательную способность. То, что вам все-таки пришлось использовать вмененную ренту, уже говорит, что особенности важны.
Сам факт, что для поддержания стабильности коэффициента надо в него включать виртуальную метрику, не может же быть обоснованием для такого действия, это своего рода тавтология. Этот вопрос и в статье мне показался ошибочным, и сейчас кажется в обсуждении. Давайте вернемся к экономике домохозяйств и собственно сути вашего коэффициента: на сколько времени хватит имеющихся средств (или их денежных эквивалентов). Арендатор продолжает тратить больше, чем владелец - с этим мы можем согласиться? Смоделируем ситуацию: у обоих исчез доход. Оба остались с некоторой суммой денег, причем, у владельца квартиры эти деньги надо будет получить продажей квартиры. Цифры для удобства: 20 млн у арендатора, 10млн + квартира стоимостью 10млн у владельца, 100к стоимость аренды, 100к ежемесячные расходы у обоих. Арендатор тратит по 200к в месяц - 20млн ему хватит на 100 месяцев. Владелец сначала тратит по 100к в месяц, пока не закончатся свободные деньги - так он протянет 100 месяцев. Отметим, что к данному моменту у арендатора уже нет ничего. Затем владелец продает квартиру, получает 10млн и начинает тратить уже по 200к в месяц на обычные расходы и аренду. Так он протянет еще 50 месяцев - итого 150 против 100 арендатора. Очевидно, КФС в данном случае должен быть выше. Если же владелец квартиры не имеет свободных денег, то ему сразу придется продать квартиру и он оказывается ровно в такой же ситуации, как и арендатор и протянет те же 100 месяцев. Разницы нет. Если же у владельца квартиры есть долги - допустим, он купил в ипотеку квартиру за 12млн и 2млн + проценты еще остался должен, - то он протянет даже меньше арендатора, т.к. потеряет на процентах.
Таким образом имхо, приравнивать в общем случае коэффициенты нельзя, они зависят как минимум от соотношения имущества, свободных денег и долгов у владельца.
Раз это виртуальная сумма, которую я плачу сам себе - ее размер не имеет значения при подсчете месячного баланса. Если я зарабатываю 10к в месяц, а трачу 5к, то моя рента может быть и 1к, и 1млн - по итогу месяца у меня останется 5к.
А если я точно так же зарабатываю 10к и 5к трачу, но плачу еще 5к аренды - по итогу месяца у меня остается ноль.
Хорошо, значит вмененная рента для проживающего в собственной квартире - это ноль, "доходы и расходы как бы остаются те же". Тогда что противопоставить расходу на аренду чужого жилья? Там-то расход реальный, ничем не компенсированный.
Еще меньше стал понимать вашу идею. Цитата из статьи, которую вы скинули
Imputed rents can alternatively be understood as returns to investments in assets. On these grounds, imputed rents might be included in disposable income, e.g. when calculating indices of income distribution.
Тут предлагается вмененную ренту учитывать как чистый доход, а не расход. Ее даже налогом пытались облагать в некоторых странах. Как это можно сопоставлять расходам на аренду - я совершенно не понимаю.
Вы взяли и приравняли вмененную ренту к арендной плате - на мой взгляд, это принципиально неверно. Давайте сначала термин согласуем: вмененная рента - это расходы владельца на поддержание состояния квартиры. Ремонт, страховка, минимальная обязательная коммуналка и т.д. Ппосмотрим на проживание: к расходам добавляем эту вмененную ренту. Здесь все просто. Теперь рассмотрим сдачу квартиры в аренду. Как арендатору, мне нет никакого смысла выставлять стоимость аренды равной вмененной ренте: получится себестоимость и я попросту выйду в ноль, когда план все-таки заработать. Такой сценарий работает, только если цены на рынке уже обрушены до минимума и перед владельцем стоит выбор оставить квартиру пустой и платить за ее содержание, либо сдавать за копейки и хотя бы не терять деньги. Во всех других случаях стоимость аренды будет выше вмененной ренты на некую прибыль - жилье по всему миру все-таки дорого, как для покупки, так и для аренды. Еще надо учесть, что порча имущества в арендном договоре может покрываться за счет арендатора, напрямую по факту или залогом, тогда значимость вмененной ренты становится еще меньше. Коммуналку, кстати, тоже некоторые включают в плату. В итоге мне видится, что почти всегда разница в доходах все-таки существует и арендатор платит больше на сумму прибыли арендодателя. А, значит, расходы арендатора выше, чем расходы владельца.
Вы почему-то не учитываете арендную плату как часть расходов. Василий-арендатор тратит в месяц больше Василия-владельца квартиры. А раз его траты больше, то при равных сбережениях он истратит деньги раньше. Следовательно, в ваших терминах его финансовая свобода должна быть меньше.
Когда сравнивают похожие по назначению структуры данных, ожидаешь хотя бы пару слов о сложности операций (в идеале в O-нотации) и предпочтительности выбора в разных ситуациях, опирающихся не только на удобство стандартной библиотеки: методы можно найти в сторонних библиотеках или написать самому, а вот плюсы и минусы разных подходов весьма постоянны и структуру надо подбирать исходя из назначения. С VBA совсем не знаком, но быстрый гуглеж говорит, что ArrayList - это динамический массив, а Collection вовсе построен на (дву-?) связном списке и хеш-таблице одновременно, так что сразу можно предположить, например, что в Collection будет самый быстрый поиск - O(log n), по скорости вставки статический массив всех уделает с O(1) (без учета расширения), ну и так далее. С ростом n разница быстро становится гигантской.
Где-то я читал, что на низком уровне (да простят меня знатоки, я не знаю правильно ли я применяю это словосочетание здесь) есть свои нюансы в плане производительности, но, откровенно говоря, за все время использования этого объекта каких-либо проблем я не замечал и время работы макроса из-за него если и растет вообще, то совсем не критично.
Думаю, вам будет интересно таки поглубже изучить классические структуры данных: они не зависят от языка, так что это знание очень универсально. Да и объем материала не особенно велик. А вот предсказывать производительность на глаз очень не рекомендую: даже программистам сложно осознать, насколько быстры современные компьютеры, вот хорошая статья была https://habr.com/ru/post/578232/. На глаз не увидеть разницу ни между наносекундой и микросекундой, ни даже между микросекундой и миллисекундой, а это, между прочим, уже 1000x1000. Так бывает, что в деве разработчик запустит метод с условными 100 единицами данных и решит, что он работает практически мгновенно, а на проде туда придет 10 тысяч и все внезапно встанет намертво. О-нотация тем и хороша, что предсказывает, как быстро будет "плохеть" программе при увеличении объема обрабатываемых данных.
Проблема не в инстансах, а в подключенных клиентах. В том же твиттере в каждый момент открыты тысячи сессий. Им всем придётся умереть.
А что вы предлагаете в качестве решения? Оно имхо будет одинаковое что для монолита, что для микросервиса. Идеального и бесшовного я, кстати, вовсе не знаю... Не доводилось делать. Может, кто подскажет, как надо :) Видится мне так: клиенты ж не напрямую к сервисам подключаются, а через балансировщики, так что клиентская сессия останется живой. Дальше варианты: если нет проброса постоянного коннекта, а общение идет в режиме запрос-ответ, то проблемы никакой нет: балансировщик будет выбирать один из оставшихся инстансов. Недошедшие запросы можно отправить другому инстансу (понадобится защита, если они не идемпотентные), ну или ответить клиенту ошибкой. С каким-нибудь сокетом сложнее - его может быть сложно полноценно переинициализировать непосредственно на балансировщике, но и тут достаточно отправить клиенту сообщение о необходимости переподключения и закрыть коннект. Клиент тут же создаст новый коннект через тот же балансировщик к другому инстансу, а для пользователя все пройдет как меньше-чем-секундный лаг.
Повторю из статьи - там разный алгоритм. В монолите некуда переключатьcя. А в микросервисе есть.
Тоже повторю: по взаимодействию вызов высокоуровневой функции похож обращению к сервису. И там, и там есть входные/выходные данные, и там, и там есть какая-то скрытая логика и наверняка работа с чтением/сохранением данных, и там, и там есть вероятность неудачи: функция выбросит исключение, сервис вернет ошибку. Значит, у нас появляется ветвление: что делать, если что-то пошло не так. Если же предполагаемая функция принципиально не допускает неудачи и ветвления не было бы, как Вы говорите, то она, скорее всего, воплощает чистую логику без работы с другими сервисами и хранилищами данных и в сервис ее выносить попросту нет смысла. В свою очередь это значит, что ваш пример справедлив только для плохой архитектуры, а сравнивать обычные монолиты и плохие микросервисы несколько несправедливо...
О ком знает микросервис - зависит от архитектора (о чём опять же было написано). А сама необходимость введения шины нам говорит лишь об одном - квадратичный рост является проблемой и один из способов борьбы - шина.
Согласен, зависит в том числе и от архитектора. Можно действительно наворотить дурацкую систему с неимоверным количеством сетевых взаимодействий, да на разных протоколах, да разных версий. Но кол-во связей и трудоемкость их реализации все равно не будут настолько безумными, я лишь прошу не впадать в крайности.
Общая шина данных используется не только в микросервисной архитектуре - во многих фреймворках реализован observer и я во многих проектах видел использование внутри монолита.
Речь о проблемах микросервисов, да? Но ведь дурацкие связи - это и для монолита актуально, просто там последствия менее очевидны. Пустить поток данных через десятки классов, потом на внутренние события завернуть, плюс глобальными флагами приправить, да еще триггеров в базе данных понаписать - наверняка ж видели такое. И это тоже ненормально.
Вносимая асинхронность с вами несогласна. Есть и другие специфические моменты.
Какая асинхронность? Речь же была о реализации и документировании API. Один раз описываем и реализуем driving интерфейс при создании сервиса - какой-нибудь REST API для примера. Для сервисов, которые будут его использовать, потребуется клиент: либо действительно в каждом пишем свою копию, либо создаем общий и переиспользуем. Тут здорово могут помочь какие-нибудь protobuf/gRPC. Один раз описываешь структуры и получаешь и документацию, и болванку сервера, и клиенты под кучу языков. Никакого бойлерплейта. А составление исходного описания сопоставимо по затратам с описанием интерфейса какого-нибудь фасада в монолите. Ну и один раз накладные расходы на регистрацию нового API в балансировщике - копипаст нескольких строк + деплой. Если же Вам принципиально не нравится, что тут появляются сетевые задержки, то да, это недостаток. Но тут я напомню, что микросервисы обычно появляются тогда, когда вертикальное масштабирование становится невозможным, поэтому возможности избежать сетевых запросов в этом вопросе попросту не существует. Микросервисы на микроскопических проектах без перспектив большого роста, надеюсь, тут не рассматриваем :)
Если вы имеете в виду внешние интерфейсы, то да, они мало меняются. Но зачем же забывать о создании тысячи внутренних?
Выше уже расписал - они повторяют те же внутренние интерфейсы модулей монолита на свой лад, так что много времени и сил не отнимают, особенно при использовании удобных инструментов.
Если вы здесь имеете в виду мониторинг внутренних интерфейсов, то на тысячу сервисов нам потребуется тысяча описаний. Даже если они выполняются один раз. Сравните с отсутствием потребности в тысяче описаний для альтернативы.
Не об интерфейсах речь, я имел в виду два типа мониторинга: бизнес-метрики и технические. Бизнес-метрики в любом случае нужно реализовывать что в монолите, что в сервисах: нужно знать активность пользователей, отслеживать платежи, контролировать воронки активаций, проводить А/Б-тесты и т.д. Это не зависит от архитектуры проекта. А технические метрики типа доступности сервиса, кол-ва ошибок, дисконнектов, состояния железок и виртуалок и т.д. мало зависят от реализации софтины и обычно являются шаблонными: вот шаблон метрик по железке, вот по nginx/apache, вот по MySQL/PostgreSQL/noSQL. И тут особо нет разницы, условный HTTP API один на 1000 методов в монолите или их 10 по 100 методов для фронта плюс еще 100 по 10 методов для внутреннего взаимодействия. Даже не копипаста, а массовое применение один раз написанного шаблона.
А здесь вы уже вышли за рамки аргументированных возражений, и потому я оставлю дальнейшее без комментариев.
Т.к. тут вы выходили за рамки подтверждаемых утверждений - туше.
Если приложение монолитное, то перезапустить придётся всё приложение целиком. Это означает, что миллионы пользователей Твиттера начнут страдать. Они перезапускают один мкросервис, при этом его работу никто не выполняет
Вовсе нет. Что микросервис, что монолит можно поднять в нескольких инстансах и переключать - green/blue deployment, довольно простая штука. В больших системах желательно каждый сервис делать с оглядкой на горизонтальное масштабирование - обычно это несложно, если изначально заложить.
Второе - все должны знать, что делать, если соседний ёжик не хочет работать.
Что внутри монолита выполнение функции может прерваться с выбросом исключения, что при обращении к сервису запрос может вернуть ошибку. Обрабатывать нужно в любом случае, просто по-разному. А чем больше проект и больше пользователей, тем чаще случаются даже крайне маловероятные ситуации.
Когда есть сотня микросервисов, то взаимодействие между ними требует налаживания десяти тысяч связей (пропорционально квадрату от количества сервисов)
Как внутри монолита делили код на модули/пакеты/неймспейсы и старались ослаблять связи, так и с микросервисами. Каждый отдельный микросервис знает о считанных единицах других, а некоторые и вовсе могут никого не знать и общаться, например, исключительно через общую шину данных. И еще забываете, что один раз создав и описав входящий/исходящий интерфейсы сервиса, это будет переиспользовано другими сервисами, а не делаться каждый раз с нуля. Если, конечно, в проекте языков не перебор.
Подняв тысячу микросервисов, мы сразу получим задачу на мониторинг этого зоопарка.
Для монолита тоже мониторинг нужен по предметным областям и тут пофиг, это монолит или сервисы. А предметно-независимый, то бишь инфраструктурный мониторинг вообще-то шаблонный, его тоже достаточно один раз описать и переиспользовать.
И, как мы видим, сотрудники Твиттера её решили просто - покупаем 100 000 серверов (не виртуальных), нанимаем 10 000 человек, и вуаля - у нас даже что-то работает.
Вы хорошо знаете, какие проблемы возникали и как решались в Твиттере, или просто "да я это сделаю за ночь и бутылку водки"?
В идеале, миллион независимых микро-сервисов легко переключится на другой адрес при падении одного из миллиона участников. [...] Но чаще всего получается как в Твиттере - 100 000 серверов и миллиарды в год на содержание бегемота.
Опять голословное утверждение. И уже миллионы - курток замшевых уже минимум три, видимо. Неужели в Твиттере не знают о балансировщиках? Кстати, как кол-во серверов помогает сервисам переключаться при падениях? Не понял эту мысль. И еще, пожалуйста, подскажите хоть примерно, сколько примерно из этих 100 000 ушло на такое бездумное дублирование? Можно ограничиться двумя-тремя наиболее жирными микросервисами Твиттера. Я вот затрудняюсь сделать такую оценку на основе новостей.
Здесь люди идут по проторенной дорожке, что означает - действие по шаблону. Они смотрят, а что там у соседа. Если у соседа что-то работает и по меркам индустрии затраты приемлемые, то вывод здесь простой - я хочу так же.
Пожалуйста, не экстраполируйте плохие практики на всю индустрию, если не знаете наверняка. И опять-таки, подскажите, пожалуйста, какие конкретно шаблонные действия совершали разработчики Твиттера и какой у них был выбор? Я не уловил таких подробностей в информационных потоках.
Не понял из статьи, как подмененная софтина смогла создать пользователя с привилегированными правами, причем даже не локального, а доменного, запустившись лишь под ограниченной учеткой какого-то пользователя. Или ее потом кто-то запустил из-под учетки с правами администратора домена? Тогда это тоже можно бы исправить - нечего "сидеть под рутом". Еще не понял, с чего началось проникновение: как и кем был подменен экзешник. Либо это сделали намеренно, либо было заражение какой-то машины этим зловредом, который сам нашел доступный для перезаписи экзешник на общем ресурсе. Без расследования этой информации имхо остается возможность повторения инцидента даже после всех принятых мер.
Хорошо-хорошо, я и из прошлого сообщения прекрасно понял, что вам не нравится Твиттер, нравятся изменения в Твиттере и не нравятся новости о Маске/Твиттере на Хабре. Однако не понимаю, почему вы это противопоставляете моему замечанию относительно потенциальной важности таких новостей, да еще и постоянно передергиваете: я ведь не говорил ни о качестве, ни о запретах там, ни о запретах здесь. Хотите поговорить - давайте поговорим, но попрошу не использовать меня как манекен для упражнений в словоблудии, да еще и с подобной лексикой.
При чем тут Джобс? Посыл всей этой истории с Твиттером достаточно простой и доступный для эксперимента: "можно разогнать всех этих тупых бездельников и станет лучше". Для этого вовсе не надо пытаться создавать культ личности или строить транснациональные корпорации, достаточно иметь нескольких подчиненных.
К чему это уничижение? Твиттер, тухлый или нет, - заметная точка на картине мира, у него огромная аудитория и уже много лет. А рухнул или не рухнул - еще рано судить имхо, запас прочности неизвестен. Кстати, соседние новости не радуют: https://habr.com/ru/news/t/720888/
Идиотов везде хватает, иногда мы даже на них работаем. А вообще этот ваш тезис кажется несколько противоречивым: изменения в Твиттере вы явно считаете положительными, но руководителей, которые попробуют делать так же, считаете идиотами?
Корпоративная культура в СНГ меняется. Да и многие нынче работают не в СНГ.
Пожалуйста, не передергивайте: никто ведь не заставляет публиковать строго либо одно, либо другое. Или вы реально считаете, что некоторые темы недостаточно освещаются из-за новостей о Маске?
Мне кажется, вы зря сыпете сарказмом, потому что игнорируете ключевые моменты. Если бы это была новость, что "какой-то миллиардер нанял пару охранников", то я бы с вами согласился. Конкретно здесь примечательно, что охрана теперь (она и раньше существовала) сопровождает Маска внутри офиса Твиттера, куда просто так с улицы не зайдешь - это явный признак опасения угрозы со стороны сотрудников, что выглядит особенно контрастно на фоне "обнимашек" в прошлом. А в целом имхо новость здесь не потому, что "невообразимый Илон Маск", а потому что касается нашумевшей и продолжающейся истории с радикальными переделками в одной из крупнейших айтишных компаний. Некоторые компании следуют примеру, так что происходящее вполне может так или иначе стать трендом, а это уже может даже коснуться и хабровчан.
Воистину "toxic manager". Даже не знаю, как со всеми этими правилами и время-то выкроить на чтение прорекламированного телеграм-канала.
Зацепил момент с лидерами и аутсайдерами охвата. Это действительно так просто - одни молодцы, а другие нет? Когда речь заходит о коммуникациях, всегда есть противопоставление двух типов личностей, обычно (и не совсем точно) называемых экстравертами и интровертами. Как бы не получилось, что есть лидер по охвату и вовлеченности, который целыми днями общается со всеми подряд, но ничего толком не делает - и он хороший, а есть аутсайдер, который молча в углу что-то там пилит и делает почти всю работу - и он плохой. Можно ли, так сказать, "переходить на личности"?
Кажется, что вовлеченность очень общий показатель, хорошо работает только на среднем/большом масштабе и только в совокупности с другими как косвенный признак, что именно в команде не так. Если команда выглядит невовлеченной, но по прочим признакам не особо отличается от остальных - надо ли вмешиваться?
Затем, что злой умысел часто маскируется под глупость/недосмотр, особенно в случаях "прокатит - не прокатит".
Именно. Если подробнее, то операции и их порядок примерно (я все же тут не эксперт) таковы:
На входе в контекст (грубо говоря, в функцию) в конце стека выделяется место под n, возвращаемый результат и ptr, как если бы все объявления переменных были смещены в начало функции и не имели инициализации значением. В аргумент же автоматически копируется значение из места вызова. До самого конца размер стека не меняется. И этот пункт стоит уточнить, поскольку аргументы функций (первые 4, кажется) и возвращаемые значения могут передаваться даже не через оперативку, а через регистры процессора.
У кучи запрашивается непрерывный кусок памяти размера sizeof(int). Если в свободных областях есть такое место, то куча его отделит по размеру, пометит занятым и отдаст указатель на начало области. Если же сводного места нет вовсе, или есть, но оно фрагментировано, т.е. состоит из нескольких частей меньшего требуемого размера и не идущих подряд, то куча сообщает операционке, что увеличивает свой размер. Операционка в свою очередь проверит, не превышает ли процесс заданный лимит на память, и подыскивает в физической памяти кусок нужного размера. Тут надо отметить, что память процесса - виртуальная, "лоскутная". Операционка сшивает несколько разных областей памяти, которые могут быть даже на разных типах устройств, и создает новое адресное пространство, которые выглядит цельным и непрерывным для процесса. Куча поэтому просто сообщает операционке, что хочет вырасти на определенный размер, а операционка подшивает к виртуальной памяти еще один кусок физической. Получив еще памяти, куча теперь может выделить запрошенный через malloc кусок или бросить исключение, если не получилось.
В стековую переменную ptr записывается адрес начала выделенной кучей области.
Из стековой переменной ptr считывается хранящийся там адрес в куче.
По считанному адресу в куче записывается интовая единица.
Куча получает запрос на освобождение: она помечает у себя, что область, начинающаяся с ptr, теперь свободна и снова может быть использована. Если есть соседние свободные области, то куча их объединит в одну большую, а при определенных условиях может еще и память операционке вернуть (тут уже подробностей совсем не знаю). На каждый malloc со временной выделенной областью должен приходиться ровно один free с тем же адресом.
По адресу возвращаемого результата на стеке записывается интовое n+1.
На завершении контекста у n и ptr вызвался бы деструктор, не будь они базовыми типами.
В месте вызова этой функции используется адрес ее возвращаемого значения, а указатель конца стека смещается до того положения, где он был до вызова. То же замечание, что и к пункту 1.
@stalker320, пожалуйста, удалите упоминание меня из статьи :) ну или хотя бы давайте уберем или поправим те пару абзацев про стек и кучу, а то вы хоть и молодец, что трудитесь над исправлением/дополнением, но все же странных вещей написали.
WARNING: написанное я все равно не стал бы включать в статью, т.к. сильно упрощал и оставил много неточностей. Это слишком обширная и сложная тема.
Стек вы описали как просто тип данных, а не модель памяти. Это маленькая область памяти ограниченного размера, в него попадают, если коротко, локальные переменные, аргументы функций и возвращаемые значения. Вызвали функцию - положили в конец аргументы, продвинулись по стеку. Создали переменную - еще продвинулись. Вызвали еще функцию - еще дальше ушли. Вышли из функции - локальные переменные и аргументы стали не нужны и мы просто вернулись по стеку обратно.
Про кучу и динамически выделяемые данные не очень понятно получилось. Данные-то вполне могут быть динамическими, но размещаться в стеке, а важно тут выделение области памяти: стек ее получает статически, однократно при запуске программы, а куча может меняться в процессе работы программы, сколько операционка позволяет процессу: нет в уже имеющейся памяти непрерывного куска нужного размера - запросили у операционки (на самом деле тут одновременно и сложнее, и проще, т.к. это виртуальная память) еще кусок памяти и продолжаем в ней сами себе выделять области - этим занимается рантайм языка. И наоборот, когда память освобождается, то она может вернуться операционке. За счет этих манипуляций выделение памяти в куче медленее, чем на стеке. "Куча может в программе и не появиться" - это все-таки контролируется вручную, т.к. такое ограничение могут накладывать целевые платформы - микроконтроллеры, например. Еще из важных отличий, что в куче можно хранить куда бОльшие объемы данных (стек же маленький) и ее можно шарить между потоками (у потоков собственные стеки).
В очистке памяти вы описали затирание данных с точки зрения безопасности, а не возвращение в кучу, что, собственно, в контексте управления памятью обычно очисткой и называется. Вот вы запросили в куче память, получили указатель. Куча у себя отметила, что область с N по N' занята, ее больше нельзя использовать при последующих запросах. Когда эта область перестала быть вам нужна, куча-то все еще считает, что память занята. А если вы даже и указатель не сохранили, то получается классическая утечка памяти: область занята, но у нас практически нет возможности это понять и ее освободить для дальнейшего использования, она так и будет висеть мертвым грузом до завершения процесса. Вот для этого возвращения и нужна очистка через free: куча отмечает область свободной и может вам в дальнейшем снова выдать в ней место даже без обращения к операционке.
Подобрал несколько хороших ссылок по теме
https://habr.com/ru/post/270009/
https://habr.com/ru/post/345766/
https://habr.com/ru/post/489360/
https://www.ibm.com/docs/ru/aix/7.1?topic=concepts-system-memory-allocation-using-malloc-subsystem
Не минусовал и уж точно не гений, но выскажу предположения.
Для начала статья по объему и полноте на руководство имхо, уж извините, совсем не тянет. В статье про память ни разу даже не упомянули стек и кучу, страницы памяти и кеш, не объяснили, как пользоваться и зачем вообще нужны malloc/free и очень-очень много чего еще. Этому явно способствует еще и ваш личный контекст, словно (вы даже это упомянули) пишете только о том, что сами недавно узнали/уточнили, и спешите с кем-то поделиться новостями.
Довольно много неточных/спорных утверждений, а это огромный минус для обучающего материала.
Наконец, для кого вы писали? Из новичков имхо мало кому поможет, слишком обрывочные сведения и неясен порог входа, а ведь в обучении очень важны системность и последовательность. Более опытные не увидят ни новых фактов, ни приемов/практик. Получается, что у статьи толком нет аудитории, ее некому положительно оценить.
Ну и несколько вещей, которые мне кольнули глаз:
За всю статью об управлении памятью не были даже упомянуты стек и куча - собственно, память программы. Сам по себе указатель не требует выделения памяти через *alloc - у вас ниже даже пример такой есть, с использованием ссылки. Самой кучи, кстати, может вовсе не быть.
Программирование вполне работает с битами: в подавляющем большинстве языков есть как минимум битовые операции и даже распространенные приемы - битовая маска, например. Наверное, хотели сказать, что минимальная адресуамая единица - это байт, но сказали не это.
Union позволяет хакнуть информацию о типе: положили под одним, прочитали словно там другой, но при этом мы потеряли часть гарантий, которые давал компилятор, а это неиссякаемый источник ошибок, так что чудо довольно грязное. И это не единственный способ: того же можно добиться, например, кастом через указатель или копированием памяти.
Так размер совпадает или не совпадает с "разрядностью компьютера"?
В отрыве от разбора операций и комбинаций (" px++", "*(++px)", "(*px)++" и т.д.) выглядит заклинанием.
Используете термин из другого языка, известный вам, но не объясняете его читателю.
Прощу прощения за надоедливость и малограмотность в вопросе, но я пытаюсь разобраться и все еще не понимаю, хотя и приближаюсь.
В случае с ВВП и вмененной рентой все хорошо, не вижу проблем. Допустим, была аренда квартиры на сумму N рублей, учтенная в ВВП. Арендатор получил услугу, арендодатель - деньги. Затем владелец сам въехал в квартиру. Услугу по предоставлению жилья он оказывает сам себе в том же объеме, но обмена на деньги не происходит, поэтому стоимость труда оказывается не учтена - это просто недостаток способа фиксации через денежные транзакции. Для фиксации таких результатов труда придумали виртуальный показатель, предположение, сколько могла бы стоить эта услуга, будь она оказана другому человеку - вмененная рента. Точно так же можно было бы учитывать, например, услугу по завариванию кофе самому себе с утра. Здесь вмененная рента нужна, т.к. ВВП пытается выразить результат всего человеческого труда в деньгах. Я потрудился и создал/оказал услугу стоимостью N рублей - если для себя, то получил саму услугу, если для другого - то получил возмещение в N рублей. Результат труда в любом случае оказался оценен.
Вы же говорите о вмененной ренте лишь как о постоянном расходе, хотя и сами упоминаете, что показатель состоит одновременно из дохода и расхода на одну и ту же сумму. Учитываете расход, но почему-то игнорируете доход. Хотя даже по вашей ссылке на статью вполне конкретно говорится, что вмененную ренту можно считать частью чистого дохода. Вот этот момент для меня совершенно непонятен, т.к. получаются деньги вникуда, которыми вы компенсируете скачок коэффициента.
Вернемся к арендатору и владельцу. Владелец потрудился, создал услугу по предоставлению жилья и сам же эту услугу потребил. У него есть расход труда на оказание услуги и доход в виде ее результатов, деньги в процессе не участвуют. Арендатор потребил услугу своего арендодателя, обменяв ее на деньги, но сам не создал никакой ценности, труд арендатора в процессе не поучаствовал. Получается разница: оба получили услугу, но арендатор затратил деньги, а владелец затратил свой труд. Можно ли одно к другому приравнять? Рыночная стоимость одинакова, но покупка услуги по предоставлению жилья все-таки уменьшает запас денег арендатора быстрее, чем у владельца. Если отходить от "странной модели с деньгами под матрасом", то вместе со вмененной рентой надо учитывать состояние финансового рынка и рынка жилья, ведь только заметное превалирование роста вложений над изменением цен на жилье может поднять арендатора до уровня владельца по совокупной стоимости имущества. Если же не переусложнять, то для выравнивания имхо надо либо сказать, что расчет предполагает определенное состояние рынков, либо как-то учесть, что арендатор меньше трудится - это потенциальный доход.
По сравнению в стартовой точке согласен, т.к. можно в момент времени сконвертировать все имущество в денежный эквивалент, таким образом поставив арендатора и владельца в абсолютно равные условия, так что останется сравнить лишь их капитал и расходы. Но если не учитывать особенности различных ситуаций, то показатель будет строиться лишь на обезличенных данных в прошлом, что серьезно уменьшает предсказательную способность. То, что вам все-таки пришлось использовать вмененную ренту, уже говорит, что особенности важны.
Сам факт, что для поддержания стабильности коэффициента надо в него включать виртуальную метрику, не может же быть обоснованием для такого действия, это своего рода тавтология. Этот вопрос и в статье мне показался ошибочным, и сейчас кажется в обсуждении.
Давайте вернемся к экономике домохозяйств и собственно сути вашего коэффициента: на сколько времени хватит имеющихся средств (или их денежных эквивалентов). Арендатор продолжает тратить больше, чем владелец - с этим мы можем согласиться? Смоделируем ситуацию: у обоих исчез доход. Оба остались с некоторой суммой денег, причем, у владельца квартиры эти деньги надо будет получить продажей квартиры. Цифры для удобства: 20 млн у арендатора, 10млн + квартира стоимостью 10млн у владельца, 100к стоимость аренды, 100к ежемесячные расходы у обоих.
Арендатор тратит по 200к в месяц - 20млн ему хватит на 100 месяцев. Владелец сначала тратит по 100к в месяц, пока не закончатся свободные деньги - так он протянет 100 месяцев. Отметим, что к данному моменту у арендатора уже нет ничего. Затем владелец продает квартиру, получает 10млн и начинает тратить уже по 200к в месяц на обычные расходы и аренду. Так он протянет еще 50 месяцев - итого 150 против 100 арендатора. Очевидно, КФС в данном случае должен быть выше.
Если же владелец квартиры не имеет свободных денег, то ему сразу придется продать квартиру и он оказывается ровно в такой же ситуации, как и арендатор и протянет те же 100 месяцев. Разницы нет.
Если же у владельца квартиры есть долги - допустим, он купил в ипотеку квартиру за 12млн и 2млн + проценты еще остался должен, - то он протянет даже меньше арендатора, т.к. потеряет на процентах.
Таким образом имхо, приравнивать в общем случае коэффициенты нельзя, они зависят как минимум от соотношения имущества, свободных денег и долгов у владельца.
Раз это виртуальная сумма, которую я плачу сам себе - ее размер не имеет значения при подсчете месячного баланса. Если я зарабатываю 10к в месяц, а трачу 5к, то моя рента может быть и 1к, и 1млн - по итогу месяца у меня останется 5к.
А если я точно так же зарабатываю 10к и 5к трачу, но плачу еще 5к аренды - по итогу месяца у меня остается ноль.
Хорошо, значит вмененная рента для проживающего в собственной квартире - это ноль, "доходы и расходы как бы остаются те же". Тогда что противопоставить расходу на аренду чужого жилья? Там-то расход реальный, ничем не компенсированный.
Еще меньше стал понимать вашу идею. Цитата из статьи, которую вы скинули
Тут предлагается вмененную ренту учитывать как чистый доход, а не расход. Ее даже налогом пытались облагать в некоторых странах. Как это можно сопоставлять расходам на аренду - я совершенно не понимаю.
Вы взяли и приравняли вмененную ренту к арендной плате - на мой взгляд, это принципиально неверно.
Давайте сначала термин согласуем: вмененная рента - это расходы владельца на поддержание состояния квартиры. Ремонт, страховка, минимальная обязательная коммуналка и т.д.
Ппосмотрим на проживание: к расходам добавляем эту вмененную ренту. Здесь все просто.
Теперь рассмотрим сдачу квартиры в аренду. Как арендатору, мне нет никакого смысла выставлять стоимость аренды равной вмененной ренте: получится себестоимость и я попросту выйду в ноль, когда план все-таки заработать. Такой сценарий работает, только если цены на рынке уже обрушены до минимума и перед владельцем стоит выбор оставить квартиру пустой и платить за ее содержание, либо сдавать за копейки и хотя бы не терять деньги. Во всех других случаях стоимость аренды будет выше вмененной ренты на некую прибыль - жилье по всему миру все-таки дорого, как для покупки, так и для аренды. Еще надо учесть, что порча имущества в арендном договоре может покрываться за счет арендатора, напрямую по факту или залогом, тогда значимость вмененной ренты становится еще меньше. Коммуналку, кстати, тоже некоторые включают в плату.
В итоге мне видится, что почти всегда разница в доходах все-таки существует и арендатор платит больше на сумму прибыли арендодателя. А, значит, расходы арендатора выше, чем расходы владельца.
Вы почему-то не учитываете арендную плату как часть расходов. Василий-арендатор тратит в месяц больше Василия-владельца квартиры. А раз его траты больше, то при равных сбережениях он истратит деньги раньше. Следовательно, в ваших терминах его финансовая свобода должна быть меньше.
Когда сравнивают похожие по назначению структуры данных, ожидаешь хотя бы пару слов о сложности операций (в идеале в O-нотации) и предпочтительности выбора в разных ситуациях, опирающихся не только на удобство стандартной библиотеки: методы можно найти в сторонних библиотеках или написать самому, а вот плюсы и минусы разных подходов весьма постоянны и структуру надо подбирать исходя из назначения.
С VBA совсем не знаком, но быстрый гуглеж говорит, что ArrayList - это динамический массив, а Collection вовсе построен на (дву-?) связном списке и хеш-таблице одновременно, так что сразу можно предположить, например, что в Collection будет самый быстрый поиск - O(log n), по скорости вставки статический массив всех уделает с O(1) (без учета расширения), ну и так далее. С ростом n разница быстро становится гигантской.
Думаю, вам будет интересно таки поглубже изучить классические структуры данных: они не зависят от языка, так что это знание очень универсально. Да и объем материала не особенно велик.
А вот предсказывать производительность на глаз очень не рекомендую: даже программистам сложно осознать, насколько быстры современные компьютеры, вот хорошая статья была https://habr.com/ru/post/578232/. На глаз не увидеть разницу ни между наносекундой и микросекундой, ни даже между микросекундой и миллисекундой, а это, между прочим, уже 1000x1000. Так бывает, что в деве разработчик запустит метод с условными 100 единицами данных и решит, что он работает практически мгновенно, а на проде туда придет 10 тысяч и все внезапно встанет намертво. О-нотация тем и хороша, что предсказывает, как быстро будет "плохеть" программе при увеличении объема обрабатываемых данных.
А что вы предлагаете в качестве решения? Оно имхо будет одинаковое что для монолита, что для микросервиса. Идеального и бесшовного я, кстати, вовсе не знаю... Не доводилось делать. Может, кто подскажет, как надо :)
Видится мне так: клиенты ж не напрямую к сервисам подключаются, а через балансировщики, так что клиентская сессия останется живой. Дальше варианты: если нет проброса постоянного коннекта, а общение идет в режиме запрос-ответ, то проблемы никакой нет: балансировщик будет выбирать один из оставшихся инстансов. Недошедшие запросы можно отправить другому инстансу (понадобится защита, если они не идемпотентные), ну или ответить клиенту ошибкой. С каким-нибудь сокетом сложнее - его может быть сложно полноценно переинициализировать непосредственно на балансировщике, но и тут достаточно отправить клиенту сообщение о необходимости переподключения и закрыть коннект. Клиент тут же создаст новый коннект через тот же балансировщик к другому инстансу, а для пользователя все пройдет как меньше-чем-секундный лаг.
Тоже повторю: по взаимодействию вызов высокоуровневой функции похож обращению к сервису. И там, и там есть входные/выходные данные, и там, и там есть какая-то скрытая логика и наверняка работа с чтением/сохранением данных, и там, и там есть вероятность неудачи: функция выбросит исключение, сервис вернет ошибку. Значит, у нас появляется ветвление: что делать, если что-то пошло не так. Если же предполагаемая функция принципиально не допускает неудачи и ветвления не было бы, как Вы говорите, то она, скорее всего, воплощает чистую логику без работы с другими сервисами и хранилищами данных и в сервис ее выносить попросту нет смысла. В свою очередь это значит, что ваш пример справедлив только для плохой архитектуры, а сравнивать обычные монолиты и плохие микросервисы несколько несправедливо...
Согласен, зависит в том числе и от архитектора. Можно действительно наворотить дурацкую систему с неимоверным количеством сетевых взаимодействий, да на разных протоколах, да разных версий. Но кол-во связей и трудоемкость их реализации все равно не будут настолько безумными, я лишь прошу не впадать в крайности.
Общая шина данных используется не только в микросервисной архитектуре - во многих фреймворках реализован observer и я во многих проектах видел использование внутри монолита.
Речь о проблемах микросервисов, да? Но ведь дурацкие связи - это и для монолита актуально, просто там последствия менее очевидны. Пустить поток данных через десятки классов, потом на внутренние события завернуть, плюс глобальными флагами приправить, да еще триггеров в базе данных понаписать - наверняка ж видели такое. И это тоже ненормально.
Какая асинхронность? Речь же была о реализации и документировании API. Один раз описываем и реализуем driving интерфейс при создании сервиса - какой-нибудь REST API для примера. Для сервисов, которые будут его использовать, потребуется клиент: либо действительно в каждом пишем свою копию, либо создаем общий и переиспользуем. Тут здорово могут помочь какие-нибудь protobuf/gRPC. Один раз описываешь структуры и получаешь и документацию, и болванку сервера, и клиенты под кучу языков. Никакого бойлерплейта. А составление исходного описания сопоставимо по затратам с описанием интерфейса какого-нибудь фасада в монолите. Ну и один раз накладные расходы на регистрацию нового API в балансировщике - копипаст нескольких строк + деплой.
Если же Вам принципиально не нравится, что тут появляются сетевые задержки, то да, это недостаток. Но тут я напомню, что микросервисы обычно появляются тогда, когда вертикальное масштабирование становится невозможным, поэтому возможности избежать сетевых запросов в этом вопросе попросту не существует. Микросервисы на микроскопических проектах без перспектив большого роста, надеюсь, тут не рассматриваем :)
Выше уже расписал - они повторяют те же внутренние интерфейсы модулей монолита на свой лад, так что много времени и сил не отнимают, особенно при использовании удобных инструментов.
Не об интерфейсах речь, я имел в виду два типа мониторинга: бизнес-метрики и технические. Бизнес-метрики в любом случае нужно реализовывать что в монолите, что в сервисах: нужно знать активность пользователей, отслеживать платежи, контролировать воронки активаций, проводить А/Б-тесты и т.д. Это не зависит от архитектуры проекта. А технические метрики типа доступности сервиса, кол-ва ошибок, дисконнектов, состояния железок и виртуалок и т.д. мало зависят от реализации софтины и обычно являются шаблонными: вот шаблон метрик по железке, вот по nginx/apache, вот по MySQL/PostgreSQL/noSQL. И тут особо нет разницы, условный HTTP API один на 1000 методов в монолите или их 10 по 100 методов для фронта плюс еще 100 по 10 методов для внутреннего взаимодействия. Даже не копипаста, а массовое применение один раз написанного шаблона.
Т.к. тут вы выходили за рамки подтверждаемых утверждений - туше.
Вовсе нет. Что микросервис, что монолит можно поднять в нескольких инстансах и переключать - green/blue deployment, довольно простая штука. В больших системах желательно каждый сервис делать с оглядкой на горизонтальное масштабирование - обычно это несложно, если изначально заложить.
Что внутри монолита выполнение функции может прерваться с выбросом исключения, что при обращении к сервису запрос может вернуть ошибку. Обрабатывать нужно в любом случае, просто по-разному. А чем больше проект и больше пользователей, тем чаще случаются даже крайне маловероятные ситуации.
Как внутри монолита делили код на модули/пакеты/неймспейсы и старались ослаблять связи, так и с микросервисами. Каждый отдельный микросервис знает о считанных единицах других, а некоторые и вовсе могут никого не знать и общаться, например, исключительно через общую шину данных. И еще забываете, что один раз создав и описав входящий/исходящий интерфейсы сервиса, это будет переиспользовано другими сервисами, а не делаться каждый раз с нуля. Если, конечно, в проекте языков не перебор.
Для монолита тоже мониторинг нужен по предметным областям и тут пофиг, это монолит или сервисы. А предметно-независимый, то бишь инфраструктурный мониторинг вообще-то шаблонный, его тоже достаточно один раз описать и переиспользовать.
Вы хорошо знаете, какие проблемы возникали и как решались в Твиттере, или просто "да я это сделаю за ночь и бутылку водки"?
Опять голословное утверждение. И уже миллионы - курток замшевых уже минимум три, видимо. Неужели в Твиттере не знают о балансировщиках? Кстати, как кол-во серверов помогает сервисам переключаться при падениях? Не понял эту мысль. И еще, пожалуйста, подскажите хоть примерно, сколько примерно из этих 100 000 ушло на такое бездумное дублирование? Можно ограничиться двумя-тремя наиболее жирными микросервисами Твиттера. Я вот затрудняюсь сделать такую оценку на основе новостей.
Пожалуйста, не экстраполируйте плохие практики на всю индустрию, если не знаете наверняка. И опять-таки, подскажите, пожалуйста, какие конкретно шаблонные действия совершали разработчики Твиттера и какой у них был выбор? Я не уловил таких подробностей в информационных потоках.
Не понял из статьи, как подмененная софтина смогла создать пользователя с привилегированными правами, причем даже не локального, а доменного, запустившись лишь под ограниченной учеткой какого-то пользователя. Или ее потом кто-то запустил из-под учетки с правами администратора домена? Тогда это тоже можно бы исправить - нечего "сидеть под рутом".
Еще не понял, с чего началось проникновение: как и кем был подменен экзешник. Либо это сделали намеренно, либо было заражение какой-то машины этим зловредом, который сам нашел доступный для перезаписи экзешник на общем ресурсе. Без расследования этой информации имхо остается возможность повторения инцидента даже после всех принятых мер.