Здравствуйте, white_znake, Вы писали:
_>В некоторых проектах такое норм. В некоторых не прохиляет. Смотри пример. В одном из проектов нужно было распознавать объекты с потокового видео. _>Так, вот сервис этот был ресурсозатратным и дорогим, естественно, его масштабировали при достижении пиковых нагрузок, разворачивая довольно дорогие инстансы виртуалок в облаке. _>А был ряд сервисов по-проще, у которых нагрузка была гораздо меньшей. И за чем эти сервисы хостить на дорогих инстансах? _>И тут встает финансовый вопрос. Если у нас монолит, то при необходимости масштабировать сервисы, которые требуют минимальных ресурсов, придется их деплоить на более производительные инстансы. _>Или задача автоматического масштабирования становится очень интересной.
Монолит не подразумевает отсутствие сервисов. Более того, все, что можно вынести в сервисы — выносится. Распознавание отличный пример.
_>Тут дело не только в масштабировании бд. _>Для сущностей одного домена лучше подойдет реляционная бд, для сущностей другого домена лучше подойдет джокументная бд, для сущностей 3-го домена, лучше подойдет графовая бд. _>Понятно, что все можно запилить на реляционной БД, но в некоторых случаях — это будет сложнее.
Монолит может спокойно юзать все эти разные БД. Можно сделать монолит на домен. Для этого не обязательно переходить на микросервисы.
_>P.S. В общем, все зависит от задачи.
Здравствуйте, Ziaw, Вы писали:
Z>Какие стандартные отработанные решения в зрелой технологии позволяют прогнозировать SLA? Вот я привел тебе гипотетический пример SLA и результатов НТ. Как тебе может помочь здесь микросервисная технология?
Да ровно те же что и в монолите. Берешь сценарии, которые составляют SLA, определяешь сервисы, которые в них задействованы, тестируешь, снимаешь метрики, анализируешь. Плюс именно микросервисов в грануляции метрик. В монолите ты получаешь ответ "приложение делает 100RPS на стенде" и делай с таким ответом что хочешь, ни в чем себе не отказывай. Можешь профайлер запустить, если не встраивает. В микросервисах ты получаешь ответ "сервис А делает 20k RPS, Сервис Б делает 100k RPS, сервис В делает 100RPS и упирается в CPU" и тебе понятно что и как нужно масштабировать. Более того, ты эти же метрики получаешь и из продакшена и имеешь относительно адекватные профили нагрузки именно для твоего сервиса, без необходимости извлекать их из зашумленных профилей всего приложения.
Z>Я как раз хочу понять, что они такого предлагают, что вдруг стало легче? Куда делать объективная сложность, если ее помножили на сложность взаимодействия множества микросервисов? Пока получаю ответы в стиле — теперь легко делать трейсинг и сервис локаторы. Такой себе профит, по сравнению с отсутствием необходимости их делать.
Сложность, как метрика неоднородности, естественно никуда не делась. Микросервисная архитектура упрощает лишь организацию разработки путем навязывания нормальных инструментов для формализации API, мониторинга, тестирования и деплоя. Без таких инструментов микросервисы не взлетают. В отличие от монолита, где все это внедряется по остаточному принципу когда уже зад начинает пригорать. Микросервисная архитектура упрощает взаимодействие между командами благодаря тому, что у них остается меньше точек взаимодействия.
Z>Самой серьезной проблемой монолита я считаю возможность протащить туда фиговую архитектуру, рефакторинг которой станет фактически невозможным в реалиях скрама и всего такого.
2 человека и даже 20 человек это вообще не про микросервисы. Ну т.е. можно поиграться, но профита не будет. Вот 200 человек это про микросервисы. Представь себе монолит с командой в 200 человек. Да плевать уже на переиспользование алгоритмов, у них даже мердж веток в мастер будет требовать отдельного протокола и занимать недели. С микросервисами ты делишь эти 200 человек на ~20 команд которые пилят собственные модули, версионируют и документируют API, независимо деплоятся и взаимодействуют друг с другом очень ограниченно. Не особо важно что они не могут переиспользовать алгоритмы, когда одна команда пишет на python и tensorflow, а другая на Java и SQL.
Здравствуйте, Sinclair, Вы писали:
S>Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны
Если уделенный сервер не отвечает, не имеет значения, выделяешь ты по треду на запрос, используешь асинхронный io или сервер очередей. В любом случае на вызывающей стороне начинают копиться запросы и она рано или поздно падает по исчерпанию ресурса. Какой именно ресурс исчерпается первым, не очень важно. А когда принимающая сторона оживет ее завалит лавиной запросов и все вообще встанет. Каскадные отказы это действительно серьезная проблема для любых систем, даже энергосистемы с многократным резервированием, бывает, разваливаются.
Здравствуйте, Ziaw, Вы писали:
Z>Монолит не подразумевает отсутствие сервисов. Более того, все, что можно вынести в сервисы — выносится. Распознавание отличный пример.
И в чем же тогда разница между микросервисами и монолитом?
Здравствуйте, Miroff, Вы писали:
M>И в чем же тогда разница между микросервисами и монолитом?
В микросервисной архитектуре сервис выполняет одну простую функцию и крайне рекомендуется не шарить одно хранилище между несколькими микросервисами. Нет какого-то главного микросервиса.
У монолита есть крупное основное приложение с основных хранилищем, возможно какие-то изолированные сервисы развернуты отдельно.
Здравствуйте, Miroff, Вы писали:
M>Да ровно те же что и в монолите. Берешь сценарии, которые составляют SLA, определяешь сервисы, которые в них задействованы, тестируешь, снимаешь метрики, анализируешь. Плюс именно микросервисов в грануляции метрик. В монолите ты получаешь ответ "приложение делает 100RPS на стенде" и делай с таким ответом что хочешь, ни в чем себе не отказывай. Можешь профайлер запустить, если не встраивает. В микросервисах ты получаешь ответ "сервис А делает 20k RPS, Сервис Б делает 100k RPS, сервис В делает 100RPS и упирается в CPU" и тебе понятно что и как нужно масштабировать. Более того, ты эти же метрики получаешь и из продакшена и имеешь относительно адекватные профили нагрузки именно для твоего сервиса, без необходимости извлекать их из зашумленных профилей всего приложения.
Чтобы было ровно то же, метрик должно быть столько же, а это не так, метрик на порядок больше и 100% CPU на одном сервисе в НТ на стейдже нам говорит только о том, что дав этому сервису больше CPU мы возможно что-то ускорим. Это собственно все, остальное исследуем на проде.
M>Сложность, как метрика неоднородности, естественно никуда не делась. Микросервисная архитектура упрощает лишь организацию разработки путем навязывания нормальных инструментов для формализации API, мониторинга, тестирования и деплоя. Без таких инструментов микросервисы не взлетают. В отличие от монолита, где все это внедряется по остаточному принципу когда уже зад начинает пригорать. Микросервисная архитектура упрощает взаимодействие между командами благодаря тому, что у них остается меньше точек взаимодействия.
Формализация API, мониторинг, тестирование и деплой маст хев в любом случае.
M>2 человека и даже 20 человек это вообще не про микросервисы.
Это как пример перехода.
M>Ну т.е. можно поиграться, но профита не будет. Вот 200 человек это про микросервисы. Представь себе монолит с командой в 200 человек. Да плевать уже на переиспользование алгоритмов, у них даже мердж веток в мастер будет требовать отдельного протокола и занимать недели. С микросервисами ты делишь эти 200 человек на ~20 команд которые пилят собственные модули, версионируют и документируют API, независимо деплоятся и взаимодействуют друг с другом очень ограниченно. Не особо важно что они не могут переиспользовать алгоритмы, когда одна команда пишет на python и tensorflow, а другая на Java и SQL.
200 это именно комиттеры или общий размер команд? Если комиттеры именно в один неделимый проект, то понятное дело, что таких проектов единицы и к ним надо подходить с особыми мерками. Монолит с командой в несколько десятков комитеров мне и представлять не нужно, есть опыт. Разбить его на микросервисы и 200 человек не хватит потом для поддержки.
Здравствуйте, Sinclair, Вы писали:
S>Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны
Но в этом случае отвалится вся видимость (observability)! И с доступом к базе данных могут быть забавные эффекты. В Spring и вообще большинстве java-инструментом много чего завязано на потоковые переменные (ThreadLocal). Например, идентификаторы запроса (для distributed tracing) будут в этих переменных.
У нас как-то добавили мониторинг из серии "просто добавь агента". Самое заметное — трассы запросов вида "мы ответили за 1 секунду, из которой 1.5 секунды заняло обращение к внешнему сервису". Диалог с их продажниками:
— А что у вас мониторинг чушь показывает?
— Вы многопоточность используете?
— Ну да, а как еще?
— А мы такое не поддерживаем.
Через какое-то время. Тот же сервис, тот же мониторинг. Прибегает высокое начальство.
— А что у вас все тормозит???
По трейсам — среднее время больше 5 секунд. Какие-то запросы вообще нарисованы по 30 секунд. Я смотрю в альтернативный мониторинг (у нас свой рукопашный, который умеет все, что нужно):
— А в чем проблема? Большинство запросов выполняются меньше 3 секунд (там вызовы других сервисов, которые всегда были медленные). Больше 5 секунд вообще не вижу запросов. И вообще мы же выяснили, что многопоточность ваш мониторинг не поддерживают .
— Ну как же? Раз графики фигню показывают, нужно чинить! Как вы там вообще без статистики?
— (Зло, так как систему без нас выбирали). Кому надо? У меня свои метрики, там все видно и нормально. Вам надо? Бэклог вот там. И он вашими хотелками забит. Приоритизируете ваши графики — с удовольствием сделаю. (в бэклоге лежит огромный compliance, который много времени занимает в том числе из-за того, что нам не давали времени на рефакторинг).
Ну ладно, там Akka. Может там сложности с инструментацией какие. Все-таки не стандарт. Но у нас есть и совершенно станартное JEE-приложение с использованием внедренной (embedded) Jetty. Так там мониторинг вообще стабильно показывает несколько миллисекунд на запрос (при фактическом времени 1-3 секунды). А все почему? Да потому что стандартные асинхронные сервлеты выглядят в духе
public void doRequest(HttpRequest request, HttpResponse response) {
AsyncContext ctx = request.startAsync();
// send context to the pool, complete on ctx later.
}
И вот их "инструментирование" вызов doRequest измеряет! А вот более сложно подменять (и измерять) request им было лень. Видимо, не нужно это никому
Здрав ствуйте, gyraboo, Вы писали:
G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.
Это все красивая теория. На практике с "современными технологиями" можно прекрасно наблюдать эффекты интерференции между приложениями.
У нас тоже есть прекрасно обстрелянное нагрузкой приложение. С реальными k8s cpu constraints и симуляторами внешних сервисов (с необходимой задержкой "обработки"). И вот в какой-то момент выясняется, что один экземпляр приложения тормозит в боевой системе на нагрузке заметно ниже рассчетной. Я иду наезжать на наших опсов и архитекторов, отвечающих за k8s. Какого, мол, у вас среда такая? В perf были нормальные машины, а на проде вы закупили каких-то pentium pro. Дайте мне на perf самое худшее, что вообще бывает! Я тогда пропишу самые пессимистичные лимиты и все будет хорошо. Ну они поразбирались, все оказалось еще интереснее.
Наш экземпляр (который тормозит), попал на машину с тяжелой нагрузкой (для сравнения — у нас лимит в 1CPU, у них что-то вроде 4CPU). Вроде как эта нагрузка привела к троттлингу CPU. Планировщик считает CPU Time (не такты), так что зацепило вообще все приложения на хосте. И тут что тестируй, что не тестируй — все равно тормоза. В теории есть еше эффекты на CPU Cache (больше проявляются если много мелких приложений). Как-то вроде разрулили. Дали тяжелым задачам отдельный пул. Но осадочек остался.
Конкретно у k8s в его стандартных настройках есть и еще один замечательный эффект. При планировании исполнения k8s считает, что есть 150% CPU от того, что на хосте. Это хорошо подоходит Гуглу. У них много разноплановых приложений, какие-то работают близко к пределу, другие — используют минимум ресурсов. А у нас не так! У нас основное бизнес-приложение одно. Когда увеличивается входящая нагрузка, она разливается и по остальным зависимостям. Т.е. большинство сервисов приближаются к верхней границе потребностей одновременно. В результате на одном хосте потребность (demand) превышает 100% CPU, все начинает тормозить. И приводит к каскадным эффектам, замедляет обработку запросов выше, повышает требования по памяти. Ну и да, CPU опять греется и троттлится (или просто кончается burst capacity).
S>Ведь известно, что на каждый запрос выделяется отдельный тред. Запрос /animals/any заставляет тред веб-сервера Zoo висеть в ожидании ответа от Random Animal — то есть не дает треду быстро освободиться. А пул тредов на веб-сервере ограничен и един: он обслуживает и запросы /animals/any, и запросы /ticket и любые другие.
S>Уах-хах-хаа! S>Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны
Поток-на-запрос — это единственный нормальный метод. Всё остальное — удаление гландов через задницу.
Просто нужны легковесные потоки, как в Go или будущей Java Project Loom (когда их оракловские жопорукие программисты допилят таки).
M>Есть начальная команда, которая разрабатывает продукт. Это монолит, со внутренней модульюностью и более-менее успешной архитектурой. В течение 5 лет половина команды уходит на новые проекты. Другую половину эффективные менеджеры заменяют на более дешевых и управляемых сговорчивых разработчиков. Это поколение немножко забивает на границы между модулями и вводит ненужную связность. В коде образуется лишний coupling, но зато тикеты закрываются легко и весело. Приложение постепенно превращается в макаронного монстра (spaghetti monster). За следующие 5 лет половина разработчиков успешно фрустрирует и уходит. Другую половину эффективные менеджеры увольняют из-за снизившейся производительности (tech debt мешает, да) и нанимает еще более дешевых разработчиков. Это будет третье поколение. Новые разработчики дешевые, но существующий код читать не умеют. Про рефакторинги и приведение монолита в порядок даже и говорить не приходится. Зато они умеют писать новый код. Внешние костыли гордо называются микросервисами. Система может разиваться еще какое-то время. Еще через 5 лет организация получает уже распределенного макаронного монстра.
Уже за один лишь этот абзац ставлю "Спасибо".
Все остальное, впрочем, тоже верно.
S>Расскажите про ваш процесс. Лично я — очень впечатлён.
Я сначала было тоже, а потом сообразил, что до основной-то работы этот процесс еще не дошел.
Работа начинается в тот момент, когда поднятный сервис требуется использовать по назначению (production rollout). Вот там уже все может быть довольно долго, типа "выкатываем на внутренних юзеров и ждем жалоб неделю", "выкатываем на бета-юзеров", "выкатываем на % юзеров" и так далее.
Так-то поднять endpoint по готовому шаблону можно за пару часов. Какой-нибудь gigalixir или его аналоги где-нибудь в digitalocean так и вовсе за час.
Здравствуйте, Ziaw, Вы писали:
Z>1. Ничего, что сейчас сложно и нужно 20 человек там, где могут справиться 2, зато потом будет все легко и просто. Z>2. wtf???... неделя поиска распределенного бага, фуух, зато мы получили классный опыт Z>3. Добавить крупную фичу? Это легко и просто. Нужно два месяца проектирования, две недели совещаний с разработчиками нужных сервисов, месяц разработки, потом месяц регресса. А что вы хотели, это айти, здесь не бывает дешевых решений. Зато нам не страшно, что любой человек уволится, поддерживать его микросервис может любой другой, так как там три строки бизнес кода, остальное — инфраструктура по взаимодействию с остальными. Вон Вася легко сможет поддерживать еще один, все равно его микросервис с прошлого года не требовал изменений. А всего три месяца онбординга и новый программист поймет, как у нас здесь все работает и снимет допнагрузку с Васи.
Все круто, но при чем тут микросервисы? Вероятность таких проблем в монолитах точно такая же. Ты, случаем, не путаешь монолитную архитектуру и полное отсутствие масштабирования и HA?
Здравствуйте, Ziaw, Вы писали:
Z>А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так).
Включаешь трейсинг и смотришь в каком нибудь егере где мы утыкаемся. И 50 сервисов схлопываются до одного.
Z> В разных нагрузочных сценариях эти коэффициенты разные и задействованы разные микросервисы.
Значит снимаешь трейсинг для разных сценариев. Тебе продакты придут и скажут какой именно сценарий не удовлетворяет SLA. И микросервисы тут, опять же, совершенно не причем.
Здравствуйте, Ziaw, Вы писали:
Z>В микросервисной архитектуре сервис выполняет одну простую функцию и крайне рекомендуется не шарить одно хранилище между несколькими микросервисами. Нет какого-то главного микросервиса. Z>У монолита есть крупное основное приложение с основных хранилищем, возможно какие-то изолированные сервисы развернуты отдельно.
Микросервисы это, во главе угла, прежде всего про процессы разработки. А архитектура это уже следствие.
Основное ради чего весь этот сыр-бор — максимальная изоляция компетенций по единицам деплоймента. Т.е. каждая конкретная команда решает свою узкую задачу независимо. Максимально независимо. И изменения деплоятся тоже независимо. А вот чтобы это обеспечить как раз и придумана та туча микросервисных технологий.
Монолит же, это когда у нас есть одна большая суперкоманда (пусть и состоящая внутри из нескольких команд), которая и обладает всеми необходимыми компетенциями. Характерный признак монолита — большие релизы, когда несколько разных сервисов, пусть и написанных разными командами, в итоге где то собираются в единое целое, и это целое сперва тестируется именно как целое, а затем и деплоится целиком. А сколько там физических сервисов и как расшарена БД — совершенно пофигу.
Здравствуйте, Ziaw, Вы писали:
Z>Самой серьезной проблемой монолита я считаю возможность протащить туда фиговую архитектуру, рефакторинг которой станет фактически невозможным в реалиях скрама и всего такого.
Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич.
О да, это какой-то пинцет.
С другой стороны, микросервисы — тоже не всегда панацея. Там начинаются какие-то адские цепочки зависимостей, которые рано или поздно упираются в компонент с самым медленным релизным циклом.
Но это в любом случае не хуже, чем расписание релизов монолита.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>С другой стороны, микросервисы — тоже не всегда панацея.
Микросервисы это необходимое, но не достаточное условие.
S> Там начинаются какие-то адские цепочки зависимостей, которые рано или поздно упираются в компонент с самым медленным релизным циклом.
Наоборот же. Проблемы вызывают быстро меняющиеся с потерей обратной совместимости компоненты. Что при этом дают микросервисы?
1) Локальность. Т.е. ты вполне можешь проапгрейдить компонент только в одном сервисе, а в остальных оставить старый.
2) REST API на границах микросервисов значительно гибче и слабее, чем интерфейсы дотнета. Т.е. оно намного чаще и проще позволяет сохранять обратную совместимость.
Все это, разумеется, небесплатно, и проблемы тоже привносятся. Основные:
1) Сильно усложняется разработка, когда история требует согласованного изменения нескольких компонентов и сервисов. Вместо одного релиза приходится делать несколько, причем в строго определенном порядке. И каждый шаг несет ровно тот же риск, сколько и одиночный накат релиза монолита. Тестерам, разумеется, требуется прогонять полный цикл тестирования для каждого шага цепочки.
2) Сильно усложняется обеспечение совместимости в сквозной функциональности. Т.е. если у тебя, скажем, есть некий общий трейсинг, то тебе нужно при внесении изменений держать в голове возможность одновременной работы нескольких его версий. И если вдруг такое обеспечить нельзя — мы приходим к монолит-лайк релизу, с даунтаймов, осложненному существенно большим количеством независимых деплойментов.
Здравствуйте, Sinclair, Вы писали:
НС>>Это с точки зрения программиста. А с точки зрения продукта основная проблема — долгие большие релизы, и, как следствие, неконкурентный time to market новых фич. S>О да, это какой-то пинцет. S>С другой стороны, микросервисы — тоже не всегда панацея. Там начинаются какие-то адские цепочки зависимостей, которые рано или поздно упираются в компонент с самым медленным релизным циклом.
Тогда на практике в больших компаниях просто этот компонент переписывают, причём независимо от старой команды.
.
