Reliability¶
Требования к Устойчивости сервисов safeblock.com
Соглашения¶
Глагол "должен", наречия "необходимо" или "недопустимо" означают формулировку обязательного для соблюдения требования.
Глагол "может", наречие "желательно" означают рекомендательное, но не обязательное для соблюдения, правило.
Мотивация¶
При разработке приложений с использованием сервисной и микро-сервисной архитектуры, компоненты приложения взаимодействуют друг с другом по сети. Развертывание компонентов приложения в виде отдельных, независимых единиц, приводит к тому, что компоненты не обладают следующей информацией:
- о способности принимать запросы другими компонентами
- о доступности других компонент по сети
- о текущей нагрузке на другие компоненты
Таким образом повышается вероятность недоступности того или иного сервиса и, как следствие, вероятность отказа продукта в целом. Ошибки в коммуникации и отказы отдельных компонентов неизбежны, но используя определенные приемы, можно минимизировать влияние таких ошибок на продукт в целом. Целью выполнения требований к устойчивости сервисов является:
- обеспечение стабильной работы продукта, как набора сервисов
- минимизация затрат на сопровождение продуктов
Техники повышения устойчивости¶
SFS-001 JOB продолжает свою работу с того места с которого начал и возвращает 0 только когда закончил
SFS-002 Управляемый connection pool для внешних запросов
SFS-003 Поддержка репликации
SFS-015 Управляемые таймауты
SFS-010 Liveness Probes
SFS-014 Graceful Shutdown
SFS-016 "Приложение должно самостоятельно управлять структурами в базе данных и осуществлять их версионирование
SFS-013 Приложение управляет своей памятью (работает в рамках того количества что дано)
SFS-017 Таймауты в каскадных вызовах (deadline propagation)
SFS-020 Использовать retryier
SFS-021 Для сдерживания избыточного роста трафика использовать rate/burst limiter
SFS-018 "Приложение должно поддерживать обратную совместимость в своей базе данных глубиной минимум в одну версию
SFS-022 Fallback для запросов