Comments 16
Отличная статья, сжато и по делу, респект автору!
P.S. CH и как TSDB хорош, не обязательно InfluxDB в инфраструктуру тащить.
Статья замечательная, хорошо и структруировано. От себя, со стороны ползателя, добавлю только одно замечание:
Совершенно упущен размер контента, отдаваемого сервером в браузер, из-за которого по современным сайтам ходить "из деревни" (с 56кбод) практически не реально. От 100 до 400мегабайт на запрос. Да, большая часть их кеширована на разных уровнях и НЕ нагружает сервера, но .. клиенту это этого ни разу не легче.
Помнится в 2000-х коллега жаловался, что у них уволили нескольких разрабов, после того как анализ проблем сайта выловил размер страницы под .. мегабайт (всего, Карл!) .. Вспоминаю те времена начала интрентета и .. приходит понимание "как был прав тот директор ИТ".
Супер. Сжато, четко, все по делу. Спасибо!
Единственное, что на мой взгляд стоит дополнить - это четвертый столп наблюдаемости: функциональный мониторинг.
Ваш сервис может отдавать пользователю HTTP 200 OK за миллисекунду, но при этом в payload не иметь запрошенной информации. Или, например, не выполнять запрошенное действие в реальности.
Пример: в онлайн-магазине есть смысл иметь "виртуального покупателя", который раз минуту (например) проходит по всему базовому клиентскому пути - листает каталог, собирает корзину, делает чекаут, проводит оплату, отменяет заказ.
Да, в аналитической системе вам нужно будет убирать его заказы из массива данных во избежание искажений статистики. Зато вы в каждый момент времени будете уверены в том,, что базово ваша система работает корректно (если будете "глазами" этого виртуального покупателя контролировать ответы вашей системы). А о проблемах узнаете раньше, чем большинство реальных лодей с ними столкнутся.
Бесплатная синергия тут еще и с релизом. Вам очень легко понять, в случае проблем, что данный релиз нужно немедленно откатить.
У меня для этой цели, например, есть несколько "манекенов пользователей" прямо с реальными номерами мобильных телефонов (для 3DS), с реальными email и разными user-agent. Прямо рекомендую всем.
Похоже на регрессионное автотестирование функционала. У нас тестировщики сьюты пишут и гоняют их пачками на отдельном стенде.
Как я понимаю тут речь про промышленный контур идёт. Интересный подход, но риски тоже есть. Навскидку, компрометация такого манекена.
Это называется Synthetic Testing - стандартная фича во многих системах мониторинга. Он обычно используется в дополнение к RUP (real user monitoring). Внедрение, в самом деле, требует креатива и адаптации системы по многим вопросам. Поэтому лучше начинать с самых простых read-only сценариев.
Да, обычно источником сценариев является даже не регресс, а смоук.
Насчет компрометации манекена - не уверен что понял мысль. Какова модель угрозы? Что значит "компрометация манекена", кому и зачем это может пригодиться? Можете развернуть тезис?
У нас на проекте есть шардирование базы (из-за специфики самого проекта) и да, какая же это боль, мне от одного упоминания плакать хочется
Браво аплодипую стоя. Читается как увлекательный роман.
Не подскажете где работайте? Прямо таки интересно где трудиться такие толковые архитекторы
Работа с фичефлагами требует определенной культуры разработки. Иначе можно утонуть в болоте фичефлагов.
мда... ну, для начала:
Canary Releasing (Канареечное развертывание).
Вы внимательно следите за метриками ошибок и производительности на этой «канареечной» группе. Ключ к успеху — автоматический мониторинг и откат. Система сама должна обнаружить всплеск ошибок и откатить релиз
ОК. канарейка убита, инженер не проснулся.
но птица накакала в Базу: запорото ~10К записей. что дальше?
Вопрос версионирования базы вообще не рассмотрен. А именно он вызовет самую большую боль, особенно если баз больше одной, либо микросервисы каждый со своей базой... Как это чистить, если что то пошло не так - видимо руками... Честно сказать, я вообще не понимаю, как сейчас это все решается, с учетом количества отдельных команд и микросервисов - единого ответственного за успешность миграции данных нету... Легко представить, что например, команда, которая пишет микросервис "склад" прошляпила баг в новой версии, которые проявляется в каком нибудь не частом сценарии и приводит к двойному списанию товара... Вопрос на засыпку: как восстановить правильные остатки, если "птица нагадила" ? Бэкап раскатать нельзя, он испортит и правильные тоже, т к не учитывает базу заказов из другого микросервиса... Остается только писать скрипт-заплату, который возьмет старую базу, все заказы (по логам или еще как то) и все пересчитает... По моему адова работенка (особенно с учетом того, что это надо сделать быстро...), ну его нафиг, не за зарплату обычного мидла уж точно. За полляма - ну может быть можно подумать 😁
Я не настоящий архитектор, но думаю решение этой проблемы бекап + события. Т.е. вы разворачиваете бэкап на момент релиза, а затем на него накатываете все события от релиза и до ролбэка. События должны привести базу (используя старую версию приложения) в правильное состояние - удалить неверные изменения и оставить верные.
Как это все сделать автоматически я слабо представляю, вот даже внимательно посмотрим на просто синезеленый релиз - в статье сказано это просто доп расходы на инфру во время релиза, но мне не понятно, а как синяя и зелёная среда синхронизируются пока идёт раскатка нового релиза, там по-любому будет тайм гэп и 0 даунтаймом это назвать нельзя, он может быть маленький, но не 0.
Дальше канарейка это типо тоже самое, но на пол шишечки и тут я вообще не понимаю как можно быть наполовину беременным. Конкретно этот новый релиз пишет данные куда? В отдельную/зеленую базу? Значит время синхронизации между синий и зелёной базой вообще потенциально несколько дней, т.е. нужно из синей базы постоянно реплики кидать в зелёную пока релиз не будет признан успешным. Нагрузка на инфру увеличивается на все время обкатки релиза. С другой стороны этот процес гарантирует наличие бэкапа с момента релиза - это ваша синия база. В теории если у вас приложение важные изменения в базе делает через очередь, то вот вам и эвент лог. Тогда автоматика отката примерно такая:
Выключаем для 5% зелёный релиз
Блокируем пользователей попавших в зелёный релиз
Берём лог/очередь из зелёного релиза и накатываем на синий
Возвращаем несчастных пользователей
В таких статьях деталей всегда мало, а они намного ценнее чем то что и любой гпт сегодня насоветует за пол часа.
В свое время, для склада с партионным учетом на ПХП + Мускуль убил месяц на то, чтобы остатки правильно считались "на лету" а не хранились в БД. Какало в БД много кого и регулярно. Находишь задвоенный, кривой документ перемещения и удаляешь. Остаток выправляется сам.
Статья отличная шпагралка по базовым рецептам решения проблем и приоритете их рассмотрения.
Два момента:
1. «Ручка API» — API handle, по-русски "обработчик API"
2.Разработка высоконагруженых сервисов, не API. API — это интерфейс, в статье больше про особенности реализации интерфейса, а не то как определять сам интерфейс.
Супер! Где же вы были раньше?) делаю свой первый веб сайт и столько вопросов и мало ответов. А тут, неожиданно такая статья и в которой, в общих словах, но понятно рассказано про важные моменты.
Особенно спасибо про информацию о TSDB, я уже подумывал начать писать логи в постгре или клик хаус 😅
Разработка высоконагруженных API: проблемы, решения, практические рекомендации