Что такое промежуточное ПО? Определение и примеры использования

Промежуточное ПО - это широко используемый термин в веб-разработке. Это может означать много вещей в зависимости от контекста, что немного сбивает с толку.

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

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

Определение промежуточного программного обеспечения

Промежуточное ПО - это программное обеспечение, которое действует как посредник между двумя приложениями или службами для облегчения их взаимодействия.

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

Распространенные варианты использования промежуточного программного обеспечения

1) Переводчик

Существует множество форматов обмена данными, например JSON, XML и Protobuf. Несмотря на то, что в настоящее время мы в основном используем JSON, у каждого из них есть свои варианты использования.

Например, известно, что протобуфер более производительный, чем JSON, но не читается человеком. Таким образом, вы можете использовать протобуфер для внутренних служб и использовать JSON, когда потребитель API является браузером.

Вы также можете прочитать мою статью о протобуферах, если вам интересно узнать о них больше.

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

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

2) Накопление-дублирование данных

Архитектура микросервисов - это популярный архитектурный шаблон, который обычно применяется в современных приложениях.

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

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

Теперь предположим, что мы хотим реализовать наш поиск таким образом, чтобы он искал как пользователей, так и продукты.

Если бы это было монолитное приложение, мы могли бы просто написать запрос для поиска в каждой таблице и объединения результатов. Но теперь наши базы данных работают на разных серверах.

У этой проблемы есть несколько решений, и мы рассмотрим два из них.

Накопление данных

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

Затем мы можем собрать результаты с обоих серверов и вернуть их клиенту. Обратите внимание, что количество запросов увеличивается линейно по мере увеличения количества серверов (и нам также необходимо объединить эти данные).

Дублирование данных

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

Если нам нужны таблицы Product и User, мы также можем создать эти таблицы на нашем поисковом сервере. Затем, когда мы сохраняем нового пользователя в нашей базе данных, мы также сохраним одну копию на поисковом сервере.

У нас есть несколько вариантов: во-первых, мы можем вызвать методы сохранения сервера поиска из методов сохранения серверов пользователей и продуктов, чтобы дублировать данные. Или мы можем создать промежуточное ПО для сохранения, которое будет делать следующее:

  • Всякий раз, когда поступает запрос на сохранение, вызывайте сервер сохранения продукта / пользователя и сервер поиска.
  • Если первое сохранение не удалось, не вызывайте сохранение для другого (это поддерживает согласованность баз данных).

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

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

Вот такое же решение с промежуточным программным обеспечением:

В этом сценарии клиентская сторона просто вызывает промежуточное ПО для сохранения продукта или пользователя, а остальное обрабатывает он.

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

3) Безопасность API

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

Мы говорили о пользовательском сервере, который заботится о входе в систему и регистрации. Если наш внешний код напрямую отправляет запросы на этот сервер, открывается адрес нашего сервера аутентификации. Узнав IP-адрес нашего бэкэнда, злоумышленники могут использовать инструменты для поиска наших конечных точек и сканирования нашего сервера на наличие уязвимостей.

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

Этот подход также позволяет нам блокировать все запросы к нашему серверу аутентификации, кроме запросов от URL нашего промежуточного программного обеспечения. Это делает наш сервер аутентификации намного более безопасным.

Раньше это было невозможно, потому что наш интерфейс взаимодействовал с сервером аутентификации. Поскольку внешний интерфейс означает компьютер клиента, мы не могли применить фильтр IP.

4) Открытие публичных API

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

Теперь давайте посмотрим на другую сторону уравнения: что, если мы хотим предоставить ограниченный доступ к нашему API? Может быть, мы программист в банке, и банк планирует хакатон. Нам нужно будет предоставить доступ к нашему API, верно?

Но поскольку мы банк, мы, конечно, не можем предоставить доступ ко всему API и разрешить каждую операцию. Это означает, что нам нужно найти способ предоставить ограниченный доступ.

Для этой цели мы можем реализовать промежуточное программное обеспечение, которое предоставляет только некоторые конечные точки и перенаправляет запросы на наш фактический API. Затем мы предоставляем этот API разработчикам на хакатоне.

Вывод

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

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

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