Чему мы научились, разрабатывая backend

сегодня в 10:28

imageРазработка Parallels Access потребовала создания геораспределенного сервиса, позволяющего безопасно устанавливать связь между компьютерами и мобильными клиентами пользователей в различных точках земного шара. Команда, которая над ним трудится, хочет поделиться полученным опытом в форме цитат, чтобы облегчить участь тем, кто только планирует создание своего клиент/серверного продукта, и погрузить в ностальгию профессионалов, имеющих за спиной дюжину успешных проектов:
  1. Для каждого публичного адреса, который потенциально может быть прикрыт CDN, заводите второй — для прямого использования сервисами. Иначе после включения «рубильника в CDN» узнаете о себе много нового, как о явлении.
  2. Включайте опцию log slow queries на СУБД. Всегда найдется инженер, который «зарядит» запрос мимо индексов. Или администратор, неправильно настроивший резервное копирование.
  3. Виртуальные машины в облаках — расходный материал. Максимально автоматизируйте разворачивание серверов. Разрабатывайте сервис так, чтобы потеря одного сервера была безболезненна.
  4. Виртуализация как студенческое общежитие: вечеринка у одного (повышенная CPU или IO активность) может аукнуться всему этажу.
  5. Используйте проверенные технологии. Любая прикольная штука содержит массу подводных камней, которые зачастую обнаруживаются уже в продакшн.
  6. NoSql может из кареты превратиться в тыкву при первой потребности произвести join.
  7. Backend API должен быть не только простым в разработке авторами, но и удобным в использовании клиентами, которые отличаются своим многообразием (web/mobile/desktop) и имеют привычку от версии к версии показывать разные данные на одних и тех же экранах.
  8. Инженер, помни: задача выполнена, когда твой код принес пользу пользователю и прибыль заказчику. Коммит — всего лишь первый шаг на этом пути.
  9. Работа сервисов из-под root'a — дыра в безопасности. В крайнем случае, стартуй из-под root'a, переключайся с помощью setuid().
  10. Избыточное логгирование может отрицательно сказаться на производительности. Научитесь менять log level'a на лету, что позволит исследовать проблемы в момент их появления.
  11. SSL можно использовать не только для шифрования. Переход от ключей к сертификатам позволит организовать авторизацию и аутентификацию компонент в инфраструктуре.
  12. Linux-сисадмины скажут спасибо, если конфиги будут в /etc/myapp, логи в /var/log/myapp и т.д. Другими словами, храните файлы в общепринятых для OS директориях.
  13. Любой лог-файл потенциально может бесконтрольно вырасти. На стадии проектирования планируйте жизненный цикл лог-файлов и данных, которые они содержат.
  14. Настройте мониторинг всех компонентов, используя удобный сервис. Далее приготовьтесь его улучшать, чтобы не просыпаться по ночам от незначительных срабатываний.
  15. Создайте календарь с датами истечения срока использования сертификатов, подписок, ключей. Иначе «что-то перестанет работать» совершенно неожиданно.
  16. Перед тем, как улучшать производительность, изучите, как правильно выбрать метрики и что такое throughput и latency.
  17. Сервис должен выбирать тот объем данных, который он сможет корректно обработать. Иначе запрос,

    update users set halyava_end_date='2016-01-01'
    Rows matched: 300000 Changed: 300000 Warnings: 0

    выполненный в начале декабря, может обернуться сюрпризом:

    2016-01-01 00:00:00 Mail service is trying to send 300 000 email…
    2016-01-01 00:00:01 Out of memory error

  18. Клиентские приложения должны корректно отрабатывать ситуацию, когда сервис перегружен или недоступен. Каждую последующую попытку соединиться выбирайте с увеличивающимся интервалом с элементами случайности. Иначе взлет после обновления/падения будет тяжелым.
  19. Серверу приложений история миграций ни к чему, лучше уметь надежно и быстро накатить его с чистого листа.
  20. Точно указывайте версии сторонних библиотек. Смена минорной версии может сломать все. Не используйте библиотеки из публичных репозиториев автоматически.
  21. Если не знаете, где искать ошибку, поищите ее сначала в сериализаторах, потом в десериализаторах.
  22. Пока для хранения и обработки дат можно использовать unix timestamp, лучше использовать unix timestamp.
  23. Скорость работы — это свойство продукта, которое может дорого стоить, но при этом быть не нужным.
  24. Распределенные системы хранения либо неконсистентны, либо тормозят, либо и то, и другое.
  25. Любая очередь — это инструмент мониторинга. Количество элементов в очереди, скорость их поступления и обработки могут прояснить происходящее в системе.
  26. Преждевременное избавление кода от копипасты — это преждевременная оптимизация.
  27. Если ты делаешь лишнюю операцию, то неважно, насколько быстро ты ее делаешь.

В комментариях готовы ответить на более конкретные вопросы. Кроме того, всю эту неделю я буду вести Твиттер бэкенд-разработчиков @backendsecret — http://bit.ly/20mJ9GP — где тоже буду рассказывать о полезном и отвечать на вопросы.

Автор: @yamschik
d70b4ee46581754ad01e625ff53dcf87.png

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

© Habrahabr.ru