Чому ми навчилися, розробляючи backend

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. Якщо ти робиш зайву операцію, то неважливо, наскільки швидко ти її робиш.


В коментарях готові відповісти на більш конкретні питання. Крім того, весь цей тиждень я буду вести Твітер бекенд-розробників @backendsecrethttp://bit.ly/20mJ9GP — де теж буду розповідати про корисне і відповідати на запитання.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.