Здравствуйте, SkyDance, Вы писали:

A>>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.

SD>Технологически это невозможно, в силу CAP.
мсье говорит про клауд, и говорит (практически оретъ), что ему не надо виртуалок .. надо понимать, что клауд это — хардварно-софтверное решение, где хардвар складывается как легаси, хард-диск контроллеры, контроллеры памяти берется с шасси (стойки) в общем, берется покупаемое клиентом железо, и в целях оптимизации на нем стартуех гипервизор, что необходимо, чтобы стартануть виртуалку, то что вы наблюдаете в виде ssh \ terminal service и прочая есть — виртуалка на концах архитектуры.

так вот прозрачная миграция виртуалок — объективная реальность. соостветственно отсюда и могут идти отправные точки для имплементора майкросрвисес, тупо ждать нужны чаннел, и сомтреть когда эта — миграция свершилась (синхронизация етц, дабы было понятно почему это возможно), потому опираясь на эти реперные точки мсье мг бы получить что ему хотелось, но мсье не надо виртуалок .. кошмар

SD>Пользователь все равно заметит. Либо потому, что потребуется перезапустить какую-то операцию (которая приземлилась на этот экземпляр, и была невосстановимо утеряна), либо операция займет существенно больше обычного (latency), если реализованы всякие там retry loop (тоже спорный вопрос, на каком уровне хорошо иметь retry, но по факту они есть почти везде).
сбой — штатная ситуация, кто сказал, что его не должно быть видно? разве, что "сбой" технологический аля неудавшаяся операция вставки в локфри, если не удалось — пусть продолжит THREAD-помогатель, либо запустим второй раз.

SD>Скорее, вопрос ставится как "не выйти за границы SLA", т.е. "не более чем N failed requests" и "не выше XX секунд среднего времени исполнения запроса". Конкретные пользователи все равно будут задеты, но в общем и целом оно как бы работает.

SD>Беда с этими системами в том, что такой подход зачастую маскирует и реальные проблемы (особенно если SLA очень расслабленые). Но это вопрос цены/качество.
а вы можете расшифровывать SLA SLAMrequest вы-же тут не читаете?

Здравствуйте, SkyDance, Вы писали:

A>>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.

SD>Технологически это невозможно, в силу CAP.
мсье говорит про клауд, и говорит (практически оретъ), что ему не надо виртуалок .. надо понимать, что клауд это — хардварно-софтверное решение, где хардвар складывается как ЛЕГО, хард-диск контроллеры, контроллеры памяти берется с шасси (стойки) в общем, берется покупаемое клиентом железо, и в целях оптимизации на нем стартуех гипервизор, что необходимо, чтобы стартануть виртуалку, то что вы наблюдаете в виде ssh \ terminal service и прочая есть — виртуалка на концах архитектуры.

так вот прозрачная миграция виртуалок — объективная реальность. соостветственно отсюда и могут идти отправные точки для имплементора майкросрвисес, тупо ждать нужны чаннел, и сомтреть когда эта — миграция свершилась (синхронизация етц, дабы было понятно почему это возможно), потому опираясь на эти реперные точки мсье мг бы получить что ему хотелось, но мсье не надо виртуалок .. кошмар

SD>Пользователь все равно заметит. Либо потому, что потребуется перезапустить какую-то операцию (которая приземлилась на этот экземпляр, и была невосстановимо утеряна), либо операция займет существенно больше обычного (latency), если реализованы всякие там retry loop (тоже спорный вопрос, на каком уровне хорошо иметь retry, но по факту они есть почти везде).
сбой — штатная ситуация, кто сказал, что его не должно быть видно? разве, что "сбой" технологический аля неудавшаяся операция вставки в локфри, если не удалось — пусть продолжит THREAD-помогатель, либо запустим второй раз.

SD>Скорее, вопрос ставится как "не выйти за границы SLA", т.е. "не более чем N failed requests" и "не выше XX секунд среднего времени исполнения запроса". Конкретные пользователи все равно будут задеты, но в общем и целом оно как бы работает.

SD>Беда с этими системами в том, что такой подход зачастую маскирует и реальные проблемы (особенно если SLA очень расслабленые). Но это вопрос цены/качество.
а вы можете расшифровывать SLA SLAMrequest вы-же тут не читаете?