Разработка Parallels Access потребовала создания геораспределенного сервиса, позволяющего безопасно устанавливать связь между компьютерами и мобильными клиентами пользователей в различных точках земного шара. Команда, которая над ним трудится, хочет поделиться полученным опытом в форме цитат, чтобы облегчить участь тем, кто только планирует создание своего клиент/серверного продукта, и погрузить в ностальгию профессионалов, имеющих за спиной дюжину успешных проектов:- Для каждого публичного адреса, который потенциально может быть прикрыт CDN, заводите второй — для прямого использования сервисами. Иначе после включения «рубильника в CDN» узнаете о себе много нового, как о явлении.
- Включайте опцию log slow queries на СУБД. Всегда найдется инженер, который «зарядит» запрос мимо индексов. Или администратор, неправильно настроивший резервное копирование.
- Виртуальные машины в облаках — расходный материал. Максимально автоматизируйте разворачивание серверов. Разрабатывайте сервис так, чтобы потеря одного сервера была безболезненна.
- Виртуализация как студенческое общежитие: вечеринка у одного (повышенная CPU или IO активность) может аукнуться всему этажу.
- Используйте проверенные технологии. Любая прикольная штука содержит массу подводных камней, которые зачастую обнаруживаются уже в продакшн.
- NoSql может из кареты превратиться в тыкву при первой потребности произвести join.
- Backend API должен быть не только простым в разработке авторами, но и удобным в использовании клиентами, которые отличаются своим многообразием (web/mobile/desktop) и имеют привычку от версии к версии показывать разные данные на одних и тех же экранах.
- Инженер, помни: задача выполнена, когда твой код принес пользу пользователю и прибыль заказчику. Коммит — всего лишь первый шаг на этом пути.
- Работа сервисов из-под root'a — дыра в безопасности. В крайнем случае, стартуй из-под root'a, переключайся с помощью setuid().
- Избыточное логгирование может отрицательно сказаться на производительности. Научитесь менять log level'a на лету, что позволит исследовать проблемы в момент их появления.
- SSL можно использовать не только для шифрования. Переход от ключей к сертификатам позволит организовать авторизацию и аутентификацию компонент в инфраструктуре.
- Linux-сисадмины скажут спасибо, если конфиги будут в /etc/myapp, логи в /var/log/myapp и т.д. Другими словами, храните файлы в общепринятых для OS директориях.
- Любой лог-файл потенциально может бесконтрольно вырасти. На стадии проектирования планируйте жизненный цикл лог-файлов и данных, которые они содержат.
- Настройте мониторинг всех компонентов, используя удобный сервис. Далее приготовьтесь его улучшать, чтобы не просыпаться по ночам от незначительных срабатываний.
- Создайте календарь с датами истечения срока использования сертификатов, подписок, ключей. Иначе «что-то перестанет работать» совершенно неожиданно.
- Перед тем, как улучшать производительность, изучите, как правильно выбрать метрики и что такое throughput и latency.
- Сервис должен выбирать тот объем данных, который он сможет корректно обработать. Иначе запрос,
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
- Клиентские приложения должны корректно отрабатывать ситуацию, когда сервис перегружен или недоступен. Каждую последующую попытку соединиться выбирайте с увеличивающимся интервалом с элементами случайности. Иначе взлет после обновления/падения будет тяжелым.
- Серверу приложений история миграций ни к чему, лучше уметь надежно и быстро накатить его с чистого листа.
- Точно указывайте версии сторонних библиотек. Смена минорной версии может сломать все. Не используйте библиотеки из публичных репозиториев автоматически.
- Если не знаете, где искать ошибку, поищите ее сначала в сериализаторах, потом в десериализаторах.
- Пока для хранения и обработки дат можно использовать unix timestamp, лучше использовать unix timestamp.
- Скорость работы — это свойство продукта, которое может дорого стоить, но при этом быть не нужным.
- Распределенные системы хранения либо неконсистентны, либо тормозят, либо и то, и другое.
- Любая очередь — это инструмент мониторинга. Количество элементов в очереди, скорость их поступления и обработки могут прояснить происходящее в системе.
- Преждевременное избавление кода от копипасты — это преждевременная оптимизация.
- Если ты делаешь лишнюю операцию, то неважно, насколько быстро ты ее делаешь.
В комментариях готовы ответить на более конкретные вопросы. Кроме того, всю эту неделю я буду вести Твиттер бэкенд-разработчиков @backendsecret — http://bit.ly/20mJ9GP — где тоже буду рассказывать о полезном и отвечать на вопросы.