Здравствуйте, Qulac, Вы писали:
Q>Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена.
Норматив — один рабочий день. Т.е. если в один день я на стендапе слышу "я начал минимальный сервис", на следующем я должен услышать "он был задеплоен, работаю над следующей задачей". Сколько там потратил программист — не важно. Если вдруг сервиса не будет — я уже буду разбираться, что и где пошло не так. Там не так много работы, но для нового сервиса есть некоторая специфика. Процесс примерно следующий: Взять скелет приложения. Отрезать лишнее, проверить базовые настройки, проверить настройки (пакеты в коде, имя приложения для деплоймента и мониторинга, требуемые ресурсы, autoscaling и прочие радости). Приложение "без базы" на данном этапе потребует чуть больше работы, чем с базой. У нас база в скелете . Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час.
Залить в source control, сделать MR.
Попинать CI, чтобы оно быстрее проект заметило (это я плохо пинаю ответственных за CI, чтобы сделать процесс чуть быстрее).
Дождаться аппрува на MR
Смержить
Найти ответственных за promotion (они вообще от времени года зависят!). Получить подтверждение, задеплоить. И так для каждой среды в цепочке.
Сделать операционную документацию. Вроде "сервис ничего не использует. Падать не должен. Если упадет — удивиться и перезапустить". По моим наблюдениям ее никто не читает. Но заполнять надо — традиция бюрократия. Полчаса примерно.
Сделать дашборды для метрик. Они как раз используются, когда операторы, не читавшие документацию из предыдущего пункта, пытаются сказать, что сервис не работает. А мы можем на метрики посмотреть и сказать, что все работает по плану. 15-30 минут.
Проверить, что логи видны.
Подумать про alerts. Сделать их или решить, что не нужно.
Вот это то, что у нас считается production приложением. И все из этого входит в норматив.
Сложности здесь скорее в переключениях типов работы. В промежутках разработчик может еще на какой-нибудь корпоративный митинг сходить (пока другие смотрят MR), выкурить чаю, откомментировать другие MR и т.п. В режиме буста (когда все рядом и готовы давать approval) часа за 2 можно все сделать. Часть — бюрократия вне нашего контроля. Еще часть не оптимизирована под новые приложения — новые сервисы не так часто делаются, чтобы инвестиции времени окупились.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Qulac, Вы писали:
Q>>Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена.
M>Норматив — один рабочий день. Т.е. если в один день я на стендапе слышу "я начал минимальный сервис", на следующем я должен услышать "он был задеплоен, работаю над следующей задачей". Сколько там потратил программист — не важно. Если вдруг сервиса не будет — я уже буду разбираться, что и где пошло не так. Там не так много работы, но для нового сервиса есть некоторая специфика. Процесс примерно следующий: M> M> Взять скелет приложения. Отрезать лишнее, проверить базовые настройки, проверить настройки (пакеты в коде, имя приложения для деплоймента и мониторинга, требуемые ресурсы, autoscaling и прочие радости). Приложение "без базы" на данном этапе потребует чуть больше работы, чем с базой. У нас база в скелете . Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час. M> Залить в source control, сделать MR. M> Попинать CI, чтобы оно быстрее проект заметило (это я плохо пинаю ответственных за CI, чтобы сделать процесс чуть быстрее). M> Дождаться аппрува на MR M> Смержить M> Найти ответственных за promotion (они вообще от времени года зависят!). Получить подтверждение, задеплоить. И так для каждой среды в цепочке. M> Сделать операционную документацию. Вроде "сервис ничего не использует. Падать не должен. Если упадет — удивиться и перезапустить". По моим наблюдениям ее никто не читает. Но заполнять надо — традиция бюрократия. Полчаса примерно. M> Сделать дашборды для метрик. Они как раз используются, когда операторы, не читавшие документацию из предыдущего пункта, пытаются сказать, что сервис не работает. А мы можем на метрики посмотреть и сказать, что все работает по плану. 15-30 минут. M> Проверить, что логи видны. M> Подумать про alerts. Сделать их или решить, что не нужно. M>
M>Вот это то, что у нас считается production приложением. И все из этого входит в норматив.
M>Сложности здесь скорее в переключениях типов работы. В промежутках разработчик может еще на какой-нибудь корпоративный митинг сходить (пока другие смотрят MR), выкурить чаю, откомментировать другие MR и т.п. В режиме буста (когда все рядом и готовы давать approval) часа за 2 можно все сделать. Часть — бюрократия вне нашего контроля. Еще часть не оптимизирована под новые приложения — новые сервисы не так часто делаются, чтобы инвестиции времени окупились.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Спасибо. Но по моему это очень долго. S>Расскажите про ваш процесс. Лично я — очень впечатлён.
"Любая организация, которая строит системы... неизбежно произведет дизайн, структура которого является копией коммуникационной структуры организации". (с) Мелвин Конвей.
Конечно вместо статей на хабре я бы рекомендовал прочитать книгу от Сэма Ньюмена: "От монолита к микросервисам". Если еще не читали. Есть перевод на русском языке.
Там на эту тему идет более предметный разговор. С аргументами и доводами за и против.
Во-первых никто и не призывает везде лепить микросервисы. Монолиты живы и будут жить во многих проектах. С другой стороны и монолиты клепать везде где не попадя — каменный век.
Сделать микросервисы сложнее. Причем сделать правильно. И тут вопрос даже не в технических способностях. Посмотрите на цитату, с которой я начал этот пост. Вопрос, ни много ни мало, в организации разработки.
Это ничуть ни меньше про менеджмент разработки, чем про архитектуру. И это все более ни менее понимают. Поэтому так престижно говорить на конференции "А у нас микросервисы ...", остальные менеджеры/управленцы "Вау... да вы круты... Смогли организовать процесс!" Конечно, внутрь компании никто лезть не будет. Никто не будет выяснять есть ли там Entity Service в качестве антипаттерна.
Просто пойдет слух, что вот есть организация РосароконсалтТаргетинг у которой микросервисы и они передовые в плане выстраивания процессов.
Отсюда и беруться через пару лет все эти разочарования.
Но в самих микросервисах идея крайне простая и давным давно известная. Нужно сложную систему разбить на части и получить несколько слабо связанных между собой систем. У каждой системы своя команда. Свой деплой. Это известно уже тысячу лет... просто появился buzzword ну и некоторая систематизация практик и паттернов для этого.
И один из главных паттернов — если система не разбивается, то не разбивайте ее. Гемора получите больше выгод. Разве что где-то на конференции скажите "А у нас микросервисы..."
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Qulac, Вы писали:
Q>>Главный вопрос: Сколько времени у Вас потребуется программисту для добавления нового модуля(сервиса) в систему и довести его до продакшена.
M>Норматив — один рабочий день. Т.е. если в один день я на стендапе слышу "я начал минимальный сервис", на следующем я должен услышать "он был задеплоен, работаю над следующей задачей". Сколько там потратил программист — не важно. Если вдруг сервиса не будет — я уже буду разбираться, что и где пошло не так. Там не так много работы, но для нового сервиса есть некоторая специфика. Процесс примерно следующий: M> M> Взять скелет приложения. Отрезать лишнее, проверить базовые настройки, проверить настройки (пакеты в коде, имя приложения для деплоймента и мониторинга, требуемые ресурсы, autoscaling и прочие радости). Приложение "без базы" на данном этапе потребует чуть больше работы, чем с базой. У нас база в скелете . Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час. M> Залить в source control, сделать MR. M> Попинать CI, чтобы оно быстрее проект заметило (это я плохо пинаю ответственных за CI, чтобы сделать процесс чуть быстрее). M> Дождаться аппрува на MR M> Смержить M> Найти ответственных за promotion (они вообще от времени года зависят!). Получить подтверждение, задеплоить. И так для каждой среды в цепочке. M> Сделать операционную документацию. Вроде "сервис ничего не использует. Падать не должен. Если упадет — удивиться и перезапустить". По моим наблюдениям ее никто не читает. Но заполнять надо — традиция бюрократия. Полчаса примерно. M> Сделать дашборды для метрик. Они как раз используются, когда операторы, не читавшие документацию из предыдущего пункта, пытаются сказать, что сервис не работает. А мы можем на метрики посмотреть и сказать, что все работает по плану. 15-30 минут. M> Проверить, что логи видны. M> Подумать про alerts. Сделать их или решить, что не нужно. M>M>Вот это то, что у нас считается production приложением. И все из этого входит в норматив. M>Сложности здесь скорее в переключениях типов работы. В промежутках разработчик может еще на какой-нибудь корпоративный митинг сходить (пока другие смотрят MR), выкурить чаю, откомментировать другие MR и т.п. В режиме буста (когда все рядом и готовы давать approval) часа за 2 можно все сделать. Часть — бюрократия вне нашего контроля. Еще часть не оптимизирована под новые приложения — новые сервисы не так часто делаются, чтобы инвестиции времени окупились.
А какая предментая область, если не секрет? И кто придумал этот пайплайн -- скопипастили у кого-то или продиктовано бизнес
потребностями?
Здравствуйте, Sharov, Вы писали:
S>А какая предментая область, если не секрет?
B2B2C. Если совсем упрощенно, мы делаем некоторые сервисы для интернет-магазинов. Т.е. наши клиенты — интернет-магазины. Но наши (условно) плагины видны посетителям интернет-магазинов. Моя команада отвечает за платежи и все, что с ними связано.
S>И кто придумал этот пайплайн -- скопипастили у кого-то или продиктовано бизнес потребностями?
Скорее так исторически сложилось на основе организационной структуры. Когда-то давно, может, и скопировали. Но с тех пор практически все уже поменялось. Например, изначально CI разрабатывался вообще отдельной командой без какой-либо связи с продуктовыми командами. Разработчикам спускались инструкции "пишите так и только так" (в виде огромного boilerplate для каждого проекта). Сейчас ситуация меняется, появляется обратная связь и больше свободы. Promotion approval — по большей части исторические. Зависят от уровня паранойи у руководства. При этом считаюстся по худшей команде. Т.е. косячит одна команда, а репрессии устраивают всем. Тоже есть подвижки в сторону упрощения. Хотя конкретно у нас какая-то часть будет идти строго из-за специфики платежей. Мы вообще PCI-certified, для этого нужно немного бюрократии. Логи/алерты — смесь "глобальных технических инициатив" и конкретно нашей команды.
Многие части процесса или особенности наши (определяются внутри команды). Они нам подходят и какого-то особого недовольства не доставляют.
Boilerplate/skeleton — это заготовка с основными аспектами (каркас web-обработчиков, логи, мониторинг, деплоймент, база), принадлежит нашей команде. Вообще у нас в команде достаточно радикальная политика по отношению к фреймворкам и библиотекам: "Если библиотека/фреймворк не устраивает — можно (и даже рекомендуется) велосипедить так, чтобы было удобно". Я не хочу, чтобы мы тратили время только потому, что когда-то приняли формальное решение. Это повышает требования к качеству библиотек. И особенно — к их модульности. Так что, с одной стороны, мы на конкретном проекте можем изменить конкретный выбор. Например, не нравится веб-уровень — можно сделать другой (бюрократии нет, но причины нужно где-нибудь записать). Или решить отдавать метрики в другом формате. Или, например, использовать какой-то специфический слой для базы. Но это же значит, что мы не можем просто "включить фреймворк" в котором есть все (потому что в нем со временем может оказаться куча ненужного). Так и появляесят полуфабрикат — все вроде есть, но можно открутить (сейчас или потом) что угодно. Стандартный набор велосипедов и деталей у нас удачный. Так что "взять базу и выпилить лишнее" работает хорошо и в краткосрочной, и в долгой перспективах.
Merge request — это правила хорошего тона уже практически везде. Плюс по нашим процессам я почти во всех outages участвую в группе поддержки. Поэтому мне лично интересно, чтобы если что-то падало, то падало в одном месте и заметно. А не отдавалось фантомными болями где-то далеко-далеко. И у меня обычно есть возможность быстро переключиться с текущей задачи и сделать ревью. CI у нас делает pre-merge. Проходит оно быстро (меньше 10 минут обычно), типичное ревью занимает больше времени. Так что merge check нас не замедляет. Иногда он даже падает (иначе бы упало после мержа), так что некоторая польза есть. А еще у нас члены команды имеют разные интересы (кому-то интереснее технические детали, кому-то — бизнес) и ревью дает разносторонние отзывы.
Так как мы платежи, тестироваться интеграционно с реальными системами нам сложно. А тестирование в pre-merge еще и не ложится в environments. Здесь нам очень помогают различные эмуляторы. Заодно мы можем эмулировать "особенности" наших поставщиков услуг. Заодно упрощается и локальная разработка. Честные "интеграционные" тесты мы тоже делаем вручную, но это долго, сложно и не автоматизируется.
Promotion я уже сказал. Частично — исторически-бюрократические, частично — для PCI и прочего legal.
Метрики — фишка нашей команды. Я лично считаю, что найти что-то в логах на хоть какой-то интересной нагрузке (допустим, мизерные 100 запросов в минуту) становится практически не реально. Если добавить несколько экземпляров сервиса и несколько других систем, все становится очень печально. В метриках можно делать почти все то же, что в логах (вместе с записью исключения можно и счетчик увеличить). Потом мы можем сначала посмотреть на дашборды а потом прогнать какие-нибудь ручные запросы по метрикам. Т.е. тормозит "все" или конкретные типы запросов? Привязано это к отдельной машине или медленно везде? Что у нас с вызовами persistence и внешних сервисов? И все это в динамике (сейчас, час назад, "обычно").
Логи в нашей организации — отдельная грустная история. Чтобы логи были полезны, они должны содержать достаточно информации. Поэтму они становятся "большими". Бизнес жалуется, что все дорого и просит логи почикать. А почиканные логи становятся бесполезными. В рамках "дорого" мы еще и несколько миграций logging system сделали. Поэтому "проверить, что логи видны" — суровая необходимость. Мало-ли что отвалится. А конкретные exception traces все же бывают полезны. Обычно уже после того, как что-то нашли в метриках. Или для новой функциональности, когда у нас все работает с тестовой средой вендора, а в production все ну совсем по-другому. Поэтому полностью отказаться от логов мы тоже не можем.
Alerts — это еще сверху к логам и метрикам. Мы 24/7 работаем и вроде как в надежности хотим минимум 99.9% доступности. Поэтому нужны alerts. Желательно — до того, как наши клиенты начали жаловаться (это добавляет необходимость успокаивать нашу команду поддержки). Обычно все сводится к "вендор упал — звоните им и спрашивайте", но иногда бывает и интереснее.
Лично мне процесс в целом нравится. Команде — тоже. Некоторые вещи можно сделать лучше, но не все зависит от нас. Alerts происходят напрямую из бизнес-требований. Часть — была задолго до меня (и вообще до нашей команды). Почти половину мы сделали сами в команде для себя. Если переводить на язык бизнеса — уменьшает время на разработку (boilerplate — локально и "сейчас", принципы — для того, чтобы в будущем не застопориться на каких-нибудь несовершенствах). Еще мы повышаем надежность в ревью/тестировании (вклад в количество девяток). Также имеем хороший observability (т.е. меньше времени требуется на обнаружение и исправление проблем, тоже в девятки идет).
Здравствуйте, BlackEric, Вы писали:
BE>Где наконец-то говорится
Наконец-то? Типа ты раньше об этом никогда не слышал?
BE>Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
Я совсем не сторонник микросервисов, но расшаривание бд тоже несет много проблем, не меньше чем микросервисы.
BE>Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему.
Ну и? Чем это не микросервисно?
BE>А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.
Это тоже вполне себе microservices way.
BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных
Здравствуйте, Nikita Lyapin, Вы писали:
NL>"Любая организация, которая строит системы... неизбежно произведет дизайн, структура которого является копией коммуникационной структуры организации". (с) Мелвин Конвей.
Хрень полная.
NL>Во-первых никто и не призывает везде лепить микросервисы.
Вот прям уж так и никто?
NL>Сделать микросервисы сложнее. Причем сделать правильно.
Если совместить это утверждение с заявленными целями микросервисов, то выходит что микросервисы не выполняют свою задачу.
NL>Но в самих микросервисах идея крайне простая и давным давно известная. Нужно сложную систему разбить на части
Вот только микросервисы предлагают не просто разбивать на части, а разбивать на части очень жестким образом, оставляя между частями только крайне слабую связь в виде REST API. А без этого важного уточнения, опять же, вся идея микросервисов теряет смысл.
NL>И один из главных паттернов — если система не разбивается, то не разбивайте ее.
Ага, мыши, станьте ежиками. При должном уровне старания разбить можно все. И на вопрос нужно ли разбивать твое банальное утверждение никак не отвечает.
Здравствуйте, vaa, Вы писали:
vaa>там он предлагает уходит от "программирования на месте" к иммутабельному ФП аргументируя это тем что уже 5-10 лет железо не проблема. хватит мол экономить на байтах.
Ну да, в 2012 для некоторых может оно так и было. А в 2021 каждый сэкономленный байт выливается во вполне конкретные деньги, не потраченные на лишнюю ВМ.
Здравствуйте, Умака Кумакаки, Вы писали:
УК>Микросервисы и команды это перпендикулярные понятия.
Это прямо противоречит определению микросервисов.
A microservice architecture – a variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of loosely-coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The goal is that teams can bring their services to life independent of others.
Если кто то делает микросервисы, но при этом они перпендикулярны командам — это карго культ в чистом виде.
Здравствуйте, gyraboo, Вы писали:
G>Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита.
Здесь нет никакой связи с монолитной архитектурой. Либо приложение проектируется под один инстанс (что нынче редкость, потому что, помимо масштабируемости естиь еще и high availability), либо под несколько. А попытка притянуть сюда микросервисы похоже на необходимость придумать хоть что то, что оправдывает лишние телодвижения в разработке.
Здравствуйте, gyraboo, Вы писали:
G>А разве не возможность делать изи горизонтальное масштабирование?
Масштабирование становится совсем не изи, одна попытка определить, какие микросервисы в системе из нескольких десятков нужно масштабировать и по каким метрикам — отдельная работа тянущая минимум на десятки часов.
Представь, что у тебя система из 30 сервисов, у каждого своя база/монга/редис/memcached все они связаны кафкой/кроликом и дергают друг-друга внутри. Здесь хотя бы начальные ресурсы на все расчитать, не говоря уже о том, что их потом надо научиться масштабировать от нагрузки.
Здравствуйте, Ziaw, Вы писали:
G>>А разве не возможность делать изи горизонтальное масштабирование?
Z>Масштабирование становится совсем не изи, одна попытка определить, какие микросервисы в системе из нескольких десятков нужно масштабировать и по каким метрикам — отдельная работа тянущая минимум на десятки часов.
Z>Представь, что у тебя система из 30 сервисов, у каждого своя база/монга/редис/memcached все они связаны кафкой/кроликом и дергают друг-друга внутри. Здесь хотя бы начальные ресурсы на все расчитать, не говоря уже о том, что их потом надо научиться масштабировать от нагрузки.
Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.
А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.
Здравствуйте, gyraboo, Вы писали:
G>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы. G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.
Так изи или нужен немалый труд нескольких команд специалистов? Про зрелость технологии дискутировать не буду, а вот то, что простые и дешевые решения на ней становятся дорогими и сложными это факт. Ну и цена ошибки просто зашкаливает, аналитики выдали что-то типа — сервис должен выдерживать работу 20к посетителей в час, а потом выясняется, что эти посетители приходят на событие в час в одно и то же время и логин 20к в течении минуты кладет все. Да и без этих ошибок, вывод состоит в том, что мы провели НТ и система не выдержала, надо увеличивать мощности или оптимизировть код. Потом начинается работа по апроксимации этого вывода в дорогие и неоднозначные решения, посколько сказать заранее сколько потребуется мощности в пике нагрузки или насколько мы сможем что-то оптимизировать можно с очень небольшой точностью, так как стоимость железа в RPS превращается очень опосредовано, а уж время программистов на оптимизацию и эффект от нее часто оценивается либо интуитивно, либо программисты говорят что-то типа "да, мы знаем, что здесь O(N!) и это превращается в O(log N) парой строк, но тогда не стали заморачиваться premature optimization".
У меня лично складывается такое впечатление от МС архитектуры
1. Ничего, что сейчас сложно и нужно 20 человек там, где могут справиться 2, зато потом будет все легко и просто.
2. wtf???... неделя поиска распределенного бага, фуух, зато мы получили классный опыт
3. Добавить крупную фичу? Это легко и просто. Нужно два месяца проектирования, две недели совещаний с разработчиками нужных сервисов, месяц разработки, потом месяц регресса. А что вы хотели, это айти, здесь не бывает дешевых решений. Зато нам не страшно, что любой человек уволится, поддерживать его микросервис может любой другой, так как там три строки бизнес кода, остальное — инфраструктура по взаимодействию с остальными. Вон Вася легко сможет поддерживать еще один, все равно его микросервис с прошлого года не требовал изменений. А всего три месяца онбординга и новый программист поймет, как у нас здесь все работает и снимет допнагрузку с Васи.
Здравствуйте, gyraboo, Вы писали:
G>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.
Система мониторинга и сбора метрик разворачивается в любом проекте, к микросервисам это отношения не имеет. У микросервисов здесь только недостаток — метрик в разы больше и их корелляции могут быть супер неожиданны. Более того, кроме метрик обязательно еще и трейсинги, без которых вполне можно обойтись на монолите.
G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.
А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так). В разных нагрузочных сценариях эти коэффициенты разные и задействованы разные микросервисы. Бизнес месяц провел в совещаниях по планируемой нагрузке и пришел с конкретными цифрами: говорит, что система должна выдерживать миллион пользователей в день, что бы они не захотели делать на платформе.
На одном сценарии вебморда стейджа у нас ложится по таймаутам на 5к RPS, на втором на 3К, не третьем не держит и 500RPS. Какие решения нам предложит достаточно зрелая технология, как считаешь? Как найти узкие места и что именно улучшать?
Это я еще не учел всякие сюрпризы типа cache hit ratio и зависимости от конкретных данных.
Здравствуйте, Ziaw, Вы писали:
G>>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.
Z>Система мониторинга и сбора метрик разворачивается в любом проекте, к микросервисам это отношения не имеет. У микросервисов здесь только недостаток — метрик в разы больше и их корелляции могут быть супер неожиданны. Более того, кроме метрик обязательно еще и трейсинги, без которых вполне можно обойтись на монолите.
Ну так трейсинг же из коробки делается, библиотеками типа sleuth, zipkin, там тебе даже фронт готовый есть для анализа трейсов. Просто юзай трейсы и наслаждайся. Как и многие другие вещи, в экосистеме Spring Cloud, скажем обнаружение сервисов или их конфигурирование (я про проект Spring Cloud Config Server), для всего в спринге есть решения, пусть не всегда идеальные, но они идут в единой связке.
G>>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA G>>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.
Z>А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так). В разных нагрузочных сценариях эти коэффициенты разные и задействованы разные микросервисы. Бизнес месяц провел в совещаниях по планируемой нагрузке и пришел с конкретными цифрами: говорит, что система должна выдерживать миллион пользователей в день, что бы они не захотели делать на платформе.
>А где же про эти решения можно почитать? — например в книгах и статьях про Spring Cloud, про реактивный подход или про современные паттерны отказоустойчивости. Также есть статьи и блоги про стек нетфликса, нетфликс как раз одна из компаний, которая многие такие вещи придумала и внедрила, т.к. столкнулась с большой нагрузкой на микросервисы.
Z>На одном сценарии вебморда стейджа у нас ложится по таймаутам на 5к RPS, на втором на 3К, не третьем не держит и 500RPS. Какие решения нам предложит достаточно зрелая технология, как считаешь? Как найти узкие места и что именно улучшать?
Какая технология? Ну так реактивщину придумал и для этих задач (повышение перформанса) + паттерны отказоустойчивости (например, из библиотеки resilience). В частности, если у вас кто-то ложится по таймаутам, реализуйте паттерны Circuit Breaker и Bulkhead (https://sysout.ru/otkazoustojchivost-mikroservisov-shablon-circuit-breaker/). Это позволит проблемному микросервису обслуживать больший спектр запросов, а не ложиться от нагрузки на однотипных запросах. Спектр можно распределить по разным параметрам, например по конкретным эндпоинтам.
Как найти узкие места — анализ метрик, прогон микросервиса с профайлером. Тут уже всё упирается к компетенции разрабов. С монолитом точно так же приходится анализировать перформанс, только вот в монолите бывает тяжело провести оптимизацию, если она упирается в монолитную природу. Не раз с этим сталкивался, т.е. проводим анализ перформанса профалингом, находим узкие места в монолите, но понимаем, что проще вынести точки нагрузки в отдельные микросервисы на физические узлы, чем заниматься миллионом микро-оптимизаций монолита, которые все равно не гарантируют что узкое место будет устранено. А при выносе точки нагрузки в микросервис можно просто написать код без этих оптимизационных заморочек, что выйдет дешевле и быстрее.
Z>Это я еще не учел всякие сюрпризы типа cache hit ratio и зависимости от конкретных данных.
Я не спорю, что задачи при разработке микросервисов непростые. Но моё мнение, что с монолитом эти задачи решать намного тяжелее.
Здравствуйте, Ziaw, Вы писали:
G>>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы. G>>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA G>>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.
Z>Так изи или нужен немалый труд нескольких команд специалистов? Про зрелость технологии дискутировать не буду, а вот то, что простые и дешевые решения на ней становятся дорогими и сложными это факт. Ну и цена ошибки просто зашкаливает, аналитики выдали что-то типа — сервис должен выдерживать работу 20к посетителей в час, а потом выясняется, что эти посетители приходят на событие в час в одно и то же время и логин 20к в течении минуты кладет все. Да и без этих ошибок, вывод состоит в том, что мы провели НТ и система не выдержала, надо увеличивать мощности или оптимизировть код. Потом начинается работа по апроксимации этого вывода в дорогие и неоднозначные решения, посколько сказать заранее сколько потребуется мощности в пике нагрузки или насколько мы сможем что-то оптимизировать можно с очень небольшой точностью, так как стоимость железа в RPS превращается очень опосредовано, а уж время программистов на оптимизацию и эффект от нее часто оценивается либо интуитивно, либо программисты говорят что-то типа "да, мы знаем, что здесь O(N!) и это превращается в O(log N) парой строк, но тогда не стали заморачиваться premature optimization".
Z>У меня лично складывается такое впечатление от МС архитектуры Z>1. Ничего, что сейчас сложно и нужно 20 человек там, где могут справиться 2, зато потом будет все легко и просто. Z>2. wtf???... неделя поиска распределенного бага, фуух, зато мы получили классный опыт Z>3. Добавить крупную фичу? Это легко и просто. Нужно два месяца проектирования, две недели совещаний с разработчиками нужных сервисов, месяц разработки, потом месяц регресса. А что вы хотели, это айти, здесь не бывает дешевых решений. Зато нам не страшно, что любой человек уволится, поддерживать его микросервис может любой другой, так как там три строки бизнес кода, остальное — инфраструктура по взаимодействию с остальными. Вон Вася легко сможет поддерживать еще один, все равно его микросервис с прошлого года не требовал изменений. А всего три месяца онбординга и новый программист поймет, как у нас здесь все работает и снимет допнагрузку с Васи.
Мне кажется, ты смешал в одну кучу бюрократические корпоративные проблемы процесса разработки и технологии МС. В крупных компаниях или банках и раньше, по монолитам, были миллион совещаний и утверждений, и целая толпа непонятных людей — возможно потому, что цена ошибки в крупной компании слишком высока, на каждое изменение в коде нужно найти ответственного, разделить все обязанности и т.д. и т.п.. А в мелких конторах микросервисы пиляться быстро и споро, особенно если используется экосистема типа Spring Cloud. Выкатили баг на прод — ниче страшного, ща исправим, "компания у нас мелкая, никто из клиентов сильно не пострадает, зато быстро всё выкатываем".
Здравствуйте, gyraboo, Вы писали:
G>Ну так трейсинг же из коробки делается, библиотеками типа sleuth, zipkin, там тебе даже фронт готовый есть для анализа трейсов. Просто юзай трейсы и наслаждайся. Как и многие другие вещи, в экосистеме Spring Cloud, скажем обнаружение сервисов или их конфигурирование (я про проект Spring Cloud Config Server), для всего в спринге есть решения, пусть не всегда идеальные, но они идут в единой связке.
Ты прав, не только трейсинг, еще и обнаружение сервисов.
G>Какая технология?
Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.
Какие стандартные отработанные решения в зрелой технологии позволяют прогнозировать SLA? Вот я привел тебе гипотетический пример SLA и результатов НТ. Как тебе может помочь здесь микросервисная технология?
G>Я не спорю, что задачи при разработке микросервисов непростые. Но моё мнение, что с монолитом эти задачи решать намного тяжелее.
Я как раз хочу понять, что они такого предлагают, что вдруг стало легче? Куда делать объективная сложность, если ее помножили на сложность взаимодействия множества микросервисов? Пока получаю ответы в стиле — теперь легко делать трейсинг и сервис локаторы. Такой себе профит, по сравнению с отсутствием необходимости их делать.
Ты говоришь, что запущенный код монолита в одном месте оптимизировать сложно. Это далеко не во всех стеках так. В идеале монолит содержит минимум общих архитектурных решений, которые могут мешать оптимизировать какую-то его часть. Впрочем я проектировал и жесткие монолиты с кучей слоев, каждый из которых был прибит гвоздями и диктовал много чего, могу представить проблемы о которых ты говоришь. Но это не обязательно, понятие монолит диктует лишь общую кодовую базу. В которой легко отслеживать консистетность разных модулей, легко реюзать алгоритмы, легко джойнить данные, обмениваться ими и трансформировать. А делать так, чтобы что-то мешало оптимизировать один вызов совсем не обязательно.
Самой серьезной проблемой монолита я считаю возможность протащить туда фиговую архитектуру, рефакторинг которой станет фактически невозможным в реалиях скрама и всего такого.
Здравствуйте, gyraboo, Вы писали:
G>Какая технология? Ну так реактивщину придумал и для этих задач (повышение перформанса) + паттерны отказоустойчивости (например, из библиотеки resilience). В частности, если у вас кто-то ложится по таймаутам, реализуйте паттерны Circuit Breaker и Bulkhead (https://sysout.ru/otkazoustojchivost-mikroservisov-shablon-circuit-breaker/).
Почитал.
Ведь известно, что на каждый запрос выделяется отдельный тред. Запрос /animals/any заставляет тред веб-сервера Zoo висеть в ожидании ответа от Random Animal — то есть не дает треду быстро освободиться. А пул тредов на веб-сервере ограничен и един: он обслуживает и запросы /animals/any, и запросы /ticket и любые другие.
Уах-хах-хаа!
Просто не делайте так, детишки. Не надо выделять по треду на запрос, и хипстерские паттерны станут не нужны
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Сделать обработчик. Прогнать тест локально. На это уйдет полчаса-час.
