Масштабируемость означает способность системы обрабатывать увеличенную рабочую нагрузку при сохранении той же задержки.
Например, если вашей системе требуется X секунд, чтобы ответить на запрос пользователя. Для ответа на каждый из миллиона одновременных запросов пользователей должно потребоваться одинаковое количество времени.
Scalable Application(Img Source)
Для веб-приложения существует 7 распространенных ошибок, которые могут стать узким местом и ухудшить масштабируемость.
Плохое качество кода
Неэффективный, неструктурированный код может замедлить работу всей службы в производственной среде. Конкретно:
Написание тесно связанного кода (также известного как спагетти)
Использование ненужных циклов или вложенных циклов
Использование неэффективного алгоритма с более высокой сложностью Big-O
Выбор неправильного типа БД
Выбор неправильной БД может быть смертельным. Нам нужно четко понимать плюсы и минусы различных типов технологий БД.
Для (реляционных) БД на базе SQL мы оптимизируем:
Транзакционный
Сильная консистенция
Для БД без SQL:
Нет строгих требований к согласованности
Горизонтальная масштабируемость
Кроме того, нам также необходимо обеспечить масштабируемость самой БД. Выбранная нами БД должна иметь возможность быстро выполнять разбиение, сегментирование и развертывание на нескольких серверах БД.
Встраивание бизнес-логики в БД
БД не является местом для добавления бизнес-логики в большинстве случаев, например для расчета или проверки на месте.
Добавление этой логики значительно затруднит обновление БД или приложения по отдельности. Кроме того, он добавляет рабочую нагрузку в БД, для которой не оптимизирован.
Наличие этой сильно связанной системы может превратить рефакторинг БД или миграцию в кошмар.
Недостаточное кеширование
В общем, кеш должен перехватывать большую часть запросов к БД.
При правильной логике вытеснения развертывание кеша на всех необходимых уровнях приложения значительно увеличит время отклика.
Конфигурация балансировщика нагрузки
В зависимости от объема трафика и количества серверов нам необходимо настроить количество LB в качестве масштаба системы.
LB работает как шлюз к нашему приложению. Правильное количество LB имеет решающее значение для задержки системы.
Неверный API
Эффективность API также определяет задержку при увеличении трафика. Вот плюсы и минусы основных API для веб-приложений:
# 1 REST API:
Легко реализовать и открыть
Короткий ответ
# 2 GraphQL:
Гибкий запрос
Дополнительное время настройки на клиенте и сервере
# 3 RPC (gRPC) с буфером протокола:
Лучшая производительность с закодированными и сжатыми двоичными данными
Требуются и клиенты, и сервер для поддержки схемы данных.
Синхронизация против асинхронной
По мере масштабирования системы обработка задач синхронизации и асинхронных задач с разными конвейерами может снизить сложность системы и время задержки.
Например, для обработки таких задач, как «обработка данных журнала пользователя» или «отправка уведомлений», которые должны выполняться асинхронно, мы могли бы использовать фреймворк на основе асинхронного обмена сообщениями (например, Kafka). Его модель подписчиков / слушателей идеально подходит для выполнения этого типа работы.
Резюме
Диагностировать узкое место в системе может быть непросто. Вооружитесь надлежащими инструментами, и знание типичных ошибок может сделать этот процесс более управляемым.
Перевод статьи https://blog.devgenius.io/
Например, если вашей системе требуется X секунд, чтобы ответить на запрос пользователя. Для ответа на каждый из миллиона одновременных запросов пользователей должно потребоваться одинаковое количество времени.
Scalable Application(Img Source)
Для веб-приложения существует 7 распространенных ошибок, которые могут стать узким местом и ухудшить масштабируемость.
Плохое качество кода
Неэффективный, неструктурированный код может замедлить работу всей службы в производственной среде. Конкретно:
Написание тесно связанного кода (также известного как спагетти)
Использование ненужных циклов или вложенных циклов
Использование неэффективного алгоритма с более высокой сложностью Big-O
Выбор неправильного типа БД
Выбор неправильной БД может быть смертельным. Нам нужно четко понимать плюсы и минусы различных типов технологий БД.
Для (реляционных) БД на базе SQL мы оптимизируем:
Транзакционный
Сильная консистенция
Для БД без SQL:
Нет строгих требований к согласованности
Горизонтальная масштабируемость
Кроме того, нам также необходимо обеспечить масштабируемость самой БД. Выбранная нами БД должна иметь возможность быстро выполнять разбиение, сегментирование и развертывание на нескольких серверах БД.
Встраивание бизнес-логики в БД
БД не является местом для добавления бизнес-логики в большинстве случаев, например для расчета или проверки на месте.
Добавление этой логики значительно затруднит обновление БД или приложения по отдельности. Кроме того, он добавляет рабочую нагрузку в БД, для которой не оптимизирован.
Наличие этой сильно связанной системы может превратить рефакторинг БД или миграцию в кошмар.
Недостаточное кеширование
В общем, кеш должен перехватывать большую часть запросов к БД.
При правильной логике вытеснения развертывание кеша на всех необходимых уровнях приложения значительно увеличит время отклика.
Конфигурация балансировщика нагрузки
В зависимости от объема трафика и количества серверов нам необходимо настроить количество LB в качестве масштаба системы.
LB работает как шлюз к нашему приложению. Правильное количество LB имеет решающее значение для задержки системы.
Неверный API
Эффективность API также определяет задержку при увеличении трафика. Вот плюсы и минусы основных API для веб-приложений:
# 1 REST API:
Легко реализовать и открыть
Короткий ответ
# 2 GraphQL:
Гибкий запрос
Дополнительное время настройки на клиенте и сервере
# 3 RPC (gRPC) с буфером протокола:
Лучшая производительность с закодированными и сжатыми двоичными данными
Требуются и клиенты, и сервер для поддержки схемы данных.
Синхронизация против асинхронной
По мере масштабирования системы обработка задач синхронизации и асинхронных задач с разными конвейерами может снизить сложность системы и время задержки.
Например, для обработки таких задач, как «обработка данных журнала пользователя» или «отправка уведомлений», которые должны выполняться асинхронно, мы могли бы использовать фреймворк на основе асинхронного обмена сообщениями (например, Kafka). Его модель подписчиков / слушателей идеально подходит для выполнения этого типа работы.
Резюме
Диагностировать узкое место в системе может быть непросто. Вооружитесь надлежащими инструментами, и знание типичных ошибок может сделать этот процесс более управляемым.
Перевод статьи https://blog.devgenius.io/