Вещи, которые сегодня активно используются в веб-приложениях.

Определенные подходы или шаблоны широко используются во многих веб-приложениях. Вот их обзор:

Оптимистичная и пессимистичная модели параллелизма

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

Пессимистическая модель параллелизма не допускает конфликтов. Он действует как монопольный замок. Например, пока один пользователь редактирует страницу, другие пользователи даже не смогут ее открыть. Пользователь, который редактирует страницу, должен сохранить свои изменения и покинуть страницу, чтобы позволить войти следующему пользователю.

Оптимистичная модель параллелизма модель позволяет пользователям одновременно открывать одну и ту же страницу и изменять одни и те же данные. Однако механизм обнаружения конфликтов проверит наличие конфликтов до того, как пользователи сохранят изменения в базе данных. При обнаружении конфликтов пользователям может быть предложено сообщение типа "Данные, которые вы пытались изменить, были изменены другим пользователем после того, как вы получили исходное значение..."и разрешить конфликты вручную.

Кэширование на уровне приложений и шаблон Cache-Aside

Кэширование — это распространенный метод повышения производительности веб-приложений путем передачи данных из базы данных в память веб-службы или на удаленные кэширующие серверы. В свою очередь, шаблон кэширования является распространенным шаблоном для реализации кэширования (существуют также шаблоны сквозного чтения/записи и отложенной записи, которые следует учитывать при выборе шаблона кэширования для вашего приложения).

Cache-Aside работает следующим образом: веб-сервис проверяет, есть ли уже запрошенные данные в кеше. Если это так, верните данные клиенту. Если нет, то запросите базу данных, сохраните данные в кеше и верните их клиенту.

Cache-aside на первый взгляд может показаться простым. Тем не менее, есть много вещей, которые нужно учитывать, прежде чем внедрять его, например:

  • Как и когда аннулировать кеш, чтобы избежать устаревших данных?
  • Как долго данные должны оставаться в кеше до истечения срока их действия?
  • Как предотвратить проблему давки кэша?
  • Какую политику вытеснения кэша выбрать?
  • Должен ли веб-сервис хранить данные в локальной памяти или на удаленном кэш-сервере?

Другие уровни кэширования

В дополнение к кэшу уровня приложения часто используются другие уровни кэширования. Вот краткий обзор:

Логика внешнего интерфейса может кэшировать данные в локальном хранилище или хранилище сеансов, возвращаемые с конечных точек GET, чтобы уменьшить количество запросов к серверу. Фактически это будет реализация паттерна cache-aside на фронтенде.

Интерфейс может кэшировать данные в течение определенного периода времени. Однако есть риск, что данные могут измениться на сервере, поэтому фронтенд будет использовать устаревшие данные до истечения срока их действия. Чтобы аннулировать интерфейсный кеш, как только данные на сервере изменятся, механизм кеширования можно расширить с помощью E-Tag заголовка.

Рассмотренные ранее подходы к кэшированию обычно используются для кэширования пользовательских данных. Однако в веб-приложениях часто возникает необходимость кэширования статических данных, таких как файлы JavaScript или CSS, изображения или видео. Для этого разработчик может использовать кеш браузера или сети доставки контента (CDN). Выбор зависит от размера содержимого, требуемой степени контроля над кэшированным содержимым, частоты доступа и других факторов.

Государственное управление

Некоторым веб-приложениям необходимо сохранять состояние в течение некоторого времени. Известным примером является функциональность корзины покупок, однако список случаев, когда необходимо сохранять состояние, намного длиннее. В зависимости от размера состояния, продолжительности его сохранения, технических ограничений и других факторов разработчик должен рассмотреть как минимум следующие хранилища на стороне сервера:

  • Кэш веб-службы в памяти
  • Удаленный кеш-сервер (например, Redis)
  • Таблица базы данных SQL
  • База данных NoSQL

Кроме того, состояние можно сохранить на клиентской стороне с помощью следующих параметров:

  • Печенье
  • Локальное или сеансовое хранилище
  • Веб-токен JSON
  • Строка запроса
  • Скрытое поле

Интеграция веб-сервисов

Часто веб-сервисам необходимо общаться друг с другом для различных целей: запрашивать какие-то данные у другого сервиса или передавать ему данные, уведомлять о том, что что-то произошло и так далее. В зависимости от конкретного сценария интеграции, требований к производительности и других факторов разработчик может рассмотреть следующие паттерны интеграции:

  • Синхронная интеграция HTTP или gRPC или прямая связь между службами, используемая, когда одной службе требуется немедленный ответ от другой службы для продолжения ее выполнения. Кроме того, этот подход обеспечивает наименьшую задержку, однако создает тесную связь между службами.
  • Интеграция асинхронного обмена сообщениями позволяет разработчику использовать несвязанные сервисы. Это решение масштабируется намного лучше, чем прямое решение между службами, и обеспечивает более высокую отказоустойчивость. Однако обмен сообщениями подходит не для всех случаев. Кроме того, сервис-брокеры могут стать единственной точкой отказа в системе.

Разнообразный

Другие темы:

  • Модель асинхронного программирования (асинхронные вызовы каждой блокирующей операции, например вызов базы данных) является обязательным условием для веб-приложений, поскольку позволяет экономить ресурсы веб-службы и обслуживать больше веб-запросов.
  • Предотвращение критических изменений. В веб-приложении интерфейсное приложение взаимодействует с серверной службой через определенный контакт (то же самое относится к межсервисной связи между серверными службами). Изменение контракта может привести к поломке потребителей, поэтому используются техники версионирования, принцип аддитивных изменений и т.д.

Спасибо за прочтение. Если вам понравилось то, что вы прочитали, ознакомьтесь с этой историей ниже:



Сколько репозиториев вам нужно для проекта микросервисов?
Поиск компромисса между мультирепозиторием и монорепозиторием.levelup.gitconnected.com



Подпишитесь на мой канал в Telegram Software Development Daily, чтобы получать от меня больше контента.

Также подумайте о том, чтобы стать участником Medium.