В частности, есть правило, что микросервисы должны делиться так, чтобы не пересекать transaction boundary.
В идеале никакой сервис не должен дергать другой сервис. Если у вас после проектирования получилось так, что пайплайн запроса состоит из пяти микросервисов, то это серьёзная ошибка, имхо.
занятная мысль) но я видел немало таких длинных цепочек обработки запроса. И это не считая еще гейтвэя и может 1-2 доп. прокси. Понимаете, ваша мысль звучит вполне здраво, но те системы что я видел повсеместно нарушают это. Разве есть хоть какое-то доказательство (назовём это "закон длины цепочки для микросервисов") что любая распределенная система из микросервисов может быть спроектирована таким образом что длина цепочки обработки запроса не превышает заданного N ? Причем независимо от бизнес-логики и прочих факторов. Т.к. то что вы говорите, неявно опирается на веру в подобного рода закон. Netflix делал всё что мог чтоб сократить задержки, например client service discavery. А взять хотя бы distributed tracing? Вряд ли он возник из необходимости трасировать цепочки из 2 запросов. А значит такая ситуация длинных цепочек возникает нередко. То что такие штуки возникли, говорит о том что ваша идея расходится с реальностью.
Это не сетевой слой где не нужно, это граница неверно проложена
я тоже не понял вас. Если для обработки запроса нужно уложиться в 100 мс, а у вас обработка запроса проходит через 5 микросервисов, каждый из которых даёт latency пусть 30-60 мс, то как тут поможет установка границ? Лейтенси между микросервисами ненулевое же, так? И оно меньше чем лейтенси внутри одной ноды, так? Или вы имеете в виду что переход на асинхронность решает эту проблему? Т.е. message bus или просто реактивные сервисы.
Аллокация на стеке, куче, array фиксированного размера, слайсы - все это требует от разработчика заботиться о памяти в том же объеме, что в C++ или Rust
хз, может я не в теме, есть какие-то примеры подводных камней, связанных с тем что вы назвали? Утечку можно и в java сделать, скорее всего в Го тоже, но уровень мороки мне кажется меньше
заботиться о памяти в Раст по прежнему нужно, изменился только способ. Нужно постоянно учитывать владение, и время жизни объектов. Компилятор только говорит ошибки, код вместо программиста он не пишет.
Тут смысл в создании "экземпляра класса" String, а не литерала. Экземпляр нужен, чтобы у него "вызвать" drop(). Каковой вызов важен в заявленном контексте "Управление памятью".
типа литерал это строка которую нельзя менять? а нельзя такое решить спец. модификатором константности? если литерал от мутабельная строка-объект отличаются только этим объявлением то как тогда их отличать в коде? Скажем что можно менять а что нет. мне было бы яснее как-то так var s string = "hello" // mutable s const = "hello" // literal
Отменяет. Можно попробовать заменить «стартап» на любое другое явление с неопределённым будущим: «один ребёнок, приносящий пользу обществу после взросления, отбивает 100 детей, ставших социальными паразитами.» Откуда следует явно абсурдное утверждение, что ресурсы тратятся на детей впустую и они могли быть потрачены на что-то другое.
кому отменяет, а кому нет)
если так рассуждать то можно не заметить как система сама себя цапнет за задницу. И когда будет не 1 + на 100 минусов, а 1 на 1000, а потом 1 на 10 тысяч. Тут говорят о каких-то «доходах», но Uber убыточен до сих пор. Как и Амазон многие годы до этого. Но их стоимость на бирже огромна, не так ли? Все уже знают что Тесла это пузырь. Стоимость на бирже — это просто «насколько компании доверяют», т.е. это не реальные деньги.
Касательно общественной полезности — не всё так однозначно, касательно пользы и вреда. Вот мы тут «не владеем а предоставляем аренду», а потом потихонечку пересаживаем всех таксистов на свою платформу — без социалочки. А потом когда монополия — бац! и них уже нет выбора.
Многие компании из Долины скорее правые чем левые. Кодеркам то пофиг что писать — хоть ПО для космического корабля, хоть для газенвагена — абы технологии были новые и «интересно»
Очень обобщая. (Любая) Гипотеза интересна, если она хорошо (непротиворечиво) описывает наблюдаемый прошлый опыт — в смысле исходные данные — некая гипотеза (как функция) приносит результат, этот результат согласуется с наблюдаемыми данными… И ошибки на предыдущих (или доступных) данных не очень велики. Под доступными данными — подразумевается — вообще всё, что угодно. Опять же — никаких количественных оценок на данном уровне. Если гипотеза тестируется таким образом, то появляется желание использовать её для проверки — как дополнительных данных из прошлого, так и для возможных данных из будущего, для которых нет (в данный момент) наблюдаемого ответа.
я увлекался историей до программирования.
проблема в том что эти «данные» — это неточные и противоречивые сведения, которые дошли до нас (Фукидид писал не так как Геродот, Плутарх называл одну цифру армии Спартака, другие другую и тд). Потом на это всё накладывается переписывание/переводы источников. Потом — интерпретация этих данных. Есть даже термин — историография. Т.е. есть некие сложившиеся традиционные взгляды. И на всём это дальше строят «анализ»
ответ на самом деле очень простой — то что я знаю ответ на какой-то вопрос не значит что я хочу потратить н-ное время чтобы поделиться развернутым ответом на этот вопрос
у меня нет синдрома «в интернете кто-то не прав», я совершенно комфортно себя чувствую понимая что у нас разные мнения
влазить в костюм человека, не желающего впустую тратить время уже поздновато — после этой-то статьи.
за потраченное время диалога можно было бы уже и написать этот самый ответ вместо заявлений «я знаю правильные ответы».
а этого автора стоит почитать потому что это передний край экономики развития, это ж не просто публицистика какая-то, это текущий экономический консенсус
я спрашивал не о том почему стоит почитать этого автора, а почему правильна именно эта гипотеза а не другие. И каковы критерии этой правильности, и как проверить что именно правильно.
рекомендую почитать книгу
если вкратце — это построение инклюзивных институтов
мне это ничего не говорит и я не услышал здесь объяснения успеха британцев. Я говорил о том что это сложный вопрос, и внятного ответа на эту загадку на самом деле нет. Хорошо, книжку я допустим почитаю (все равно собирался), но странно когда читавший книгу не может ответить на вопрос. Если прочитавший хорошо понял книгу то обычно может ответить или перефразировать своими словами (иначе либо он плохо понял, или книга фуфло)
UPD
хорошо. Допустим такой вопрос: есть просто масса различных гипотез (как обо всём в истории), так почему стоит предпочесть именно эту и именно этого конкретного автора?
эта книга — переписанная человеческим языком абсолютно стройная экономическая теория под названием «экономика развития» и она дает ответ почему британцы стали успешны в свое время
+1 очевидное объяснение. Спасибо, обновляю свой счетчик очевидных и абсолютно стройных но разных объяснений до 17.
Например вы здесь говорите что у них была самая эффективная система управления. Но это тоже следствие чего-то, а вы даёте это как причину. И как именно доказать что именно эта причина была самой важной, что ли? Таких мнений ведь много. Отсутствие места — это тоже не очень так сказать «атомарная» причина.
эта книга — переписанная человеческим языком абсолютно стройная экономическая теория под названием «экономика развития» и она дает ответ почему британцы стали успешны в свое время
но состоявшиеся сейчас специалисты спокойно доработают до пенсии (если не застынут в развитии).
да, согласен. Но по-моему в отрасли идёт постепенное увеличение числа программистов. Раз происходит рост, то значит будет и точка насыщения, а потом возможно и откат, но неточно. Касательно Рима — я имел в виду что сам принцип, что экстраполяция прошлого может не работать. У Нассима Талеба в его книге Черный лебедь лучше объясняется. Что-то кажется невозможным, и буквально несколько событий могут поменять всё до такой ситуации которую не мог предсказать никто.
Вспомнил свою юность в 90-е годы, когда официант имел доходы намного круче ITшника.
официанты на кораблях которые «под флагом» (работают на иностранных судах) могут получать сравнимо или больше мидлов ангулара. Конечно работать на корабле тоже непросто, но они ещё и питаются не со своих денег во время плавания, т.е. ещё одна статья экономии.
Угу. Но в прошлом у таких заявлений тоже были свои «фазовые переходы». Например появление первых ИИ или появление первых IDE с Intellisense или появление первых статических анализаторов кода или…
То есть я такое слышу уже не в первый раз и каждый раз была причина почему «вот в этот раз обязательно так будет»...
то что это не случилось — не доказывает что это не случится. Докажет если кто-то даст формальное доказательство что это невозможно.
Я такого рода заголовки видел ну где-то лет десять назад уже. Не так уж и quickly, получается.
безотносительно прогнозов, такая экстраполяция в общем-то не годится.
«476 год нашей эры. Мы пережили не одно нападение, переживём и это — сказали римляне об Аларихе»
то есть никакой микросервис не может вызывать другой микросервис?
занятная мысль)
но я видел немало таких длинных цепочек обработки запроса. И это не считая еще гейтвэя и может 1-2 доп. прокси. Понимаете, ваша мысль звучит вполне здраво, но те системы что я видел повсеместно нарушают это. Разве есть хоть какое-то доказательство (назовём это "закон длины цепочки для микросервисов") что любая распределенная система из микросервисов может быть спроектирована таким образом что длина цепочки обработки запроса не превышает заданного N ? Причем независимо от бизнес-логики и прочих факторов. Т.к. то что вы говорите, неявно опирается на веру в подобного рода закон.
Netflix делал всё что мог чтоб сократить задержки, например client service discavery. А взять хотя бы distributed tracing? Вряд ли он возник из необходимости трасировать цепочки из 2 запросов. А значит такая ситуация длинных цепочек возникает нередко. То что такие штуки возникли, говорит о том что ваша идея расходится с реальностью.
я тоже не понял вас. Если для обработки запроса нужно уложиться в 100 мс, а у вас обработка запроса проходит через 5 микросервисов, каждый из которых даёт latency пусть 30-60 мс, то как тут поможет установка границ? Лейтенси между микросервисами ненулевое же, так? И оно меньше чем лейтенси внутри одной ноды, так?
Или вы имеете в виду что переход на асинхронность решает эту проблему? Т.е. message bus или просто реактивные сервисы.
ща подтянутся адвокаты микросервисов ))
хз, может я не в теме, есть какие-то примеры подводных камней, связанных с тем что вы назвали? Утечку можно и в java сделать, скорее всего в Го тоже, но уровень мороки мне кажется меньше
заботиться о памяти в Раст по прежнему нужно, изменился только способ. Нужно постоянно учитывать владение, и время жизни объектов. Компилятор только говорит ошибки, код вместо программиста он не пишет.
еще одно самое самое правильное мнение о настоящих синьорах
типа литерал это строка которую нельзя менять?
а нельзя такое решить спец. модификатором константности?
если литерал от мутабельная строка-объект отличаются только этим объявлением то как тогда их отличать в коде? Скажем что можно менять а что нет.
мне было бы яснее как-то так
var s string = "hello" // mutable
s const = "hello" // literal
а почему был выбран такой способ создания строковых литералов? Почему не просто
s string = "hello"
или хотя бы
s string = string("hello")
кому отменяет, а кому нет)
если так рассуждать то можно не заметить как система сама себя цапнет за задницу. И когда будет не 1 + на 100 минусов, а 1 на 1000, а потом 1 на 10 тысяч. Тут говорят о каких-то «доходах», но Uber убыточен до сих пор. Как и Амазон многие годы до этого. Но их стоимость на бирже огромна, не так ли? Все уже знают что Тесла это пузырь. Стоимость на бирже — это просто «насколько компании доверяют», т.е. это не реальные деньги.
Касательно общественной полезности — не всё так однозначно, касательно пользы и вреда. Вот мы тут «не владеем а предоставляем аренду», а потом потихонечку пересаживаем всех таксистов на свою платформу — без социалочки. А потом когда монополия — бац! и них уже нет выбора.
Многие компании из Долины скорее правые чем левые. Кодеркам то пофиг что писать — хоть ПО для космического корабля, хоть для газенвагена — абы технологии были новые и «интересно»
я увлекался историей до программирования.
проблема в том что эти «данные» — это неточные и противоречивые сведения, которые дошли до нас (Фукидид писал не так как Геродот, Плутарх называл одну цифру армии Спартака, другие другую и тд). Потом на это всё накладывается переписывание/переводы источников. Потом — интерпретация этих данных. Есть даже термин — историография. Т.е. есть некие сложившиеся традиционные взгляды. И на всём это дальше строят «анализ»
влазить в костюм человека, не желающего впустую тратить время уже поздновато — после этой-то статьи.
за потраченное время диалога можно было бы уже и написать этот самый ответ вместо заявлений «я знаю правильные ответы».
я спрашивал не о том почему стоит почитать этого автора, а почему правильна именно эта гипотеза а не другие. И каковы критерии этой правильности, и как проверить что именно правильно.
мне это ничего не говорит и я не услышал здесь объяснения успеха британцев. Я говорил о том что это сложный вопрос, и внятного ответа на эту загадку на самом деле нет. Хорошо, книжку я допустим почитаю (все равно собирался), но странно когда читавший книгу не может ответить на вопрос. Если прочитавший хорошо понял книгу то обычно может ответить или перефразировать своими словами (иначе либо он плохо понял, или книга фуфло)
UPD
хорошо. Допустим такой вопрос: есть просто масса различных гипотез (как обо всём в истории), так почему стоит предпочесть именно эту и именно этого конкретного автора?
+1 очевидное объяснение. Спасибо, обновляю свой счетчик очевидных и абсолютно стройных но разных объяснений до 17.
Например вы здесь говорите что у них была самая эффективная система управления. Но это тоже следствие чего-то, а вы даёте это как причину. И как именно доказать что именно эта причина была самой важной, что ли? Таких мнений ведь много. Отсутствие места — это тоже не очень так сказать «атомарная» причина.
ну ок, и что это за ответ?
да, согласен. Но по-моему в отрасли идёт постепенное увеличение числа программистов. Раз происходит рост, то значит будет и точка насыщения, а потом возможно и откат, но неточно. Касательно Рима — я имел в виду что сам принцип, что экстраполяция прошлого может не работать. У Нассима Талеба в его книге Черный лебедь лучше объясняется. Что-то кажется невозможным, и буквально несколько событий могут поменять всё до такой ситуации которую не мог предсказать никто.
скепсис тоже ничего не доказывает :) Равно как и сомнения :) И как перевод стрелок о доказательстве не доказывает ни того ни другого :)
официанты на кораблях которые «под флагом» (работают на иностранных судах) могут получать сравнимо или больше мидлов ангулара. Конечно работать на корабле тоже непросто, но они ещё и питаются не со своих денег во время плавания, т.е. ещё одна статья экономии.
то что это не случилось — не доказывает что это не случится. Докажет если кто-то даст формальное доказательство что это невозможно.
безотносительно прогнозов, такая экстраполяция в общем-то не годится.
«476 год нашей эры. Мы пережили не одно нападение, переживём и это — сказали римляне об Аларихе»