Комментарии 12
Неплохая подборка. Я бы ещё circuit breaker добавил
Да, про логгирование есть, но я бы добавил прям отдельным пунктом:
Все без исключения запросы к внешним системам должны быть залоггированы (включая request/responce body на уровне DEBUG) и замониторены (rps, p75,p95,p99, error rate).
Это еще на этапе разработки сохранит десятки часов дебага и традиционного упражнения "покажите наши логи".
И еще бы наверное стоило добавить пункт:
Мое приложение пишет логи в json(или ином сериализованном формате) и их(логи) не приходится парсить регулярками чтобы нормально проанализировать.
Спасибо за дополнения. А подскажите, куда сохраняете request/response?
В elasticsearch на пару дней. Обычно этого достаточно чтобы понять проблему.
У нас есть Interceptor через который централизованно проходят все запросы. Он в свою очередь пишет все это просто в лог. На самом деле даже разбивать на отдельные поля в ELK не приходится. Хватает того что body запроса просто есть в поле message.
Из важных нюансов еще, важно разбивать любой запрос на 2 сообщения. Одно про request, второе про response, потому что response по итогу может и вовсе не случиться, зато будет request с которым можно будет ходить к коллегам и спрашивать, что же в нем не так и почему оно вызывает ошибку.
На проде мы такого не гоняем, а на деве нет такой нагрузки чтобы весь этот механизм хоть сколько нибудь сильно влиял на производительность.
Спасибо! Отличная статья.
Спасибо!)
Спасибо за статью, очень толково написано.
Спасибо! Отличный гайд, добавил в закладки
После нынешнего довольно небольшого проекта, читая, оглядываюсь назад и вспоминаю многие решения принятые на одном из прошлых хайлоад проектов. В части кода в особенности, заморочки с избыточностью, сериализацией, бинарными данными и ORM.
Побуду адвокатом дьявола. Некоторые пункты nice to have - ваш высоконагруженный проект вполне может без них обойтись. Рассмотрим, к примеру, GitHub. Это один монолит на ruby: никаких микросервисов + использование ORM. И ничего, живёт, развивается и даже не сильно тормозит.
В моей практике highload всегда приходил внезапно: вслед за анонсом новой фичи, удачным твитом и т.п. И конечно же никакого партицирования или шардирования не было. Если закладывать их на начальном этапе, то поддерживать разработку будет дороже. Так что я б сказал что этот список хорош для демонстрации что ещё можно улучшить и настроить чтобы было легче жить.
Дельный комментарий, спасибо
Но я тоже немного парирую: во многих чек-пунктах у меня структура такая: "[ ] я сделал {то-то то-то} или {я знаю, почему могу без этого}". Самое главное тут не выполнить пункт, а знать, что есть определенная идея/техника и что в моем конкретном случае она поможет или будет лишней.
На счет монолита на ruby: вообще не буду связываться - я бы с таким умер от инфаркта, но у некоторых получается, и я снимаю перед ними шляпу.
За двумя зайцами погонишься — чеклист для HighLoad системы гуглить будешь