Курс по системному анализу и архитектуре

Брокеры сообщений

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

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

Очереди сообщений

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

Опубликовать-подписаться

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

Kafka

RabbitMQ

Корпоративная служебная шина (ESB)

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

Intro

Архитектурный стиль Representational State Transfer (REST) — это не технология, которую вы можете приобрести, или библиотека, которую вы можете добавить в свой проект разработки программного обеспечения. Это прежде всего мировоззрение, которое возвышает информацию до первоклассного элемента архитектуры, которую мы строим.

Идеи и термины, которые мы используем для описания «RESTful» систем, были представлены и сопоставлены в диссертации доктора Роя Филдинга «Архитектурные стили и проектирование сетевых программных архитектур». Этот документ является академическим и использует формальный язык, но остается доступным и обеспечивает основу для практики.

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

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

Part 1

Что означает передача представительного состояния? Передача текстовых представлений данных, доступ к ним и управление ими без сохранения состояния. При правильном развертывании он обеспечивает единообразную совместимость между различными приложениями в Интернете. Термин «без гражданства» имеет решающее значение для этого, поскольку он позволяет приложениям взаимодействовать независимо друг от друга. Служба RESTful API предоставляется через унифицированный указатель ресурсов (URL). Это логическое имя отделяет идентификатор ресурса от того, что принимается или возвращается. Схема URL определена в RFC 1738, который можно найти здесь: ietf.org/rfc/rfc1738.txt.

Пример URL-адреса RESTful может быть чем-то вроде следующего поддельного API для библиотеки:

http://fakelibrary.org/library

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

Эта отправная точка будет где-то опубликована как способ начать взаимодействие с библиотеками REST сервисов. То, что возвращается, может быть XML, JSON или, что более уместно, форматом гипермедиа, таким как Atom, или пользовательский тип MIME. Общее руководство состоит в том, чтобы повторно использовать существующие форматы, где это возможно, но существует растущая терпимость к правильно разработанным типам носителей.

Чтобы запросить ресурс, клиент выдает запрос GET протокола передачи гипертекста (HTTP) для его получения. Вот что происходит, когда вы вводите URL-адрес в браузере и нажимаете клавишу возврата, выбираете закладку или щелкаете ссылку привязки.

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

$ curl http://fakelibrary.org/library

Это вернет представление по умолчанию в командной строке. Однако вам может не понадобиться информация в этой форме. К счастью, в HTTP есть механизм, с помощью которого вы можете запрашивать информацию в другой форме. Указав заголовок «Accept» в запросе, если сервер поддерживает это представление, он вернет его. Это известно как согласование содержимого и является одним из наименее используемых аспектов HTTP. Это можно сделать с помощью команды curl, аналогичной предыдущему примеру:

$ curl –H “Accept:application/json” http://fakelibrary.org/library

Эта возможность запрашивать информацию в разных формах возможна благодаря отделению имени ресурса от его формы. Хотя «R» в REST означает «представление», а не «ресурс», об этом следует помнить при создании систем, которые позволяют клиентам запрашивать информацию в той форме, в которой они хотят. Возможные URL-адреса для нашего примера библиотеки, которые мы могли бы включить:

• http://fakelibrary.org/library — общая информация о библиотеке и основа для обнаружения ссылок для поиска конкретных книг, DVD и т. д.
• http://fakelibrary.org/book — «информационное пространство» для книг. Концептуально это заполнитель для всех возможных книг. Понятно, что если бы это было решено, мы бы не хотели возвращать все возможные книги, но, возможно, это могло бы вернуть способ поиска книг по категориям, поиску по ключевым словам и т. д.
• http://fakelibrary.org/book/category/1234 — в информационном пространстве для книг мы можем представить себе их просмотр по определенным категориям (например, художественная литература для взрослых, детские книги, книги по садоводству и т. д.). Возможно, для этого имеет смысл использовать десятичную систему Дьюи, но мы также можем вообразить пользовательские группировки. Дело в том, что это «информационное пространство» потенциально бесконечно и зависит от того, какая информация действительно будет интересна людям.
• http://fakelibrary.org/book/isbn/978-0596801687 — ссылка на конкретную книгу. Его разрешение должно включать информацию о названии, авторе, издательстве, количестве копий в системе, количестве доступных копий и т. д.

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

Например, чтобы добавить новую книгу, мы могли бы представить себе отправку XML-представления в основное информационное пространство /book. В curl это может выглядеть так:

$ curl –u username:password -d @book.xml -H “Content-type: text/xml” http://fakelibrary.org/book

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

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

http://fakelibrary.org + /book/isbn/978-0596801687

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

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

Принципы

принципы REST API следующие:

1. Архитектура клиент-сервер: клиент и сервер являются отдельными объектами, каждый из которых имеет свои обязанности. Клиент отвечает за пользовательский интерфейс и взаимодействие с пользователем, а сервер занимается хранением, обработкой и безопасностью данных.
2. Statelessness: каждый запрос от клиента к серверу должен содержать всю информацию, необходимую серверу для понимания и обработки запроса. Сервер не сохраняет состояние клиента между запросами, что упрощает масштабирование системы и повышает производительность.
3. Единый интерфейс: REST API должны иметь единый и согласованный интерфейс для упрощения взаимодействия. Этот принцип далее разбивается на следующие подпринципы:

• На основе ресурсов: ресурсы идентифицируются по уникальным URL-адресам, и клиенты взаимодействуют с этими ресурсами, используя стандартные методы HTTP (GET, POST, PUT, DELETE).
• Управление ресурсами через представления: ресурсы представлены в определенном формате (например, JSON, XML), и ими можно манипулировать с помощью этих представлений. Клиент может получать, изменять или удалять представления ресурсов, используя стандартные методы HTTP.
• Самоописательные сообщения: Каждое сообщение, которым обмениваются клиент и сервер, должно содержать достаточно информации, чтобы описать, как обрабатывать сообщение. Для предоставления этой информации следует использовать метаданные и представления ресурсов.
• Гипермедиа как механизм состояния приложения (HATEOAS): API должен включать гипермедиа-ссылки в ответы, позволяя клиентам обнаруживать доступные действия и динамически перемещаться по API.

1. Многоуровневая система (Layered System): API-интерфейсы REST могут быть разработаны в многоуровневой архитектуре, где каждый уровень играет определенную роль и взаимодействует только со смежными уровнями. Это способствует модульности и разделению задач, делая систему более удобной в сопровождении и масштабируемой.
2. Код по запросу (необязательно): REST API могут дополнительно поддерживать отправку исполняемого кода с сервера клиенту. Это позволяет серверу динамически расширять функциональность клиента. Однако этот принцип обычно не используется в типичных REST API.

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

Statelessness

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

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

Многоуровневая система (Layered System)

Представьте, что у вас есть торт с разными слоями: слой вкусного бисквита, слой кремовой глазури и слой сладких фруктов сверху.

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

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

Примеры использования REST в комбинации с другими протокалами

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

1. Обмен сообщениями в реальном времени (WebSocket):

• Соединение WebSocket: клиенты устанавливают соединения WebSocket с сервером при входе в приложение чата.
• Общение в режиме реального времени: сообщения, отправленные одним пользователем, немедленно передаются другим подключенным пользователям через соединение WebSocket, что позволяет использовать чат в реальном времени.
• Источники событий WebSocket: сервер действует как источник событий WebSocket, отправляя такие события, как «получено сообщение», «пользователь присоединился» или «пользователь ушел» подключенным клиентам.

2.Аутентификация пользователя (принципы RESTful):

• RESTful API: Приложение чата использует RESTful API для аутентификации и управления пользователями.
• Конечная точка аутентификации: когда пользователь входит в систему или регистрируется, он отправляет запрос POST в конечную точку аутентификации (/api/login или /api/register) со своими учетными данными.
• Маркер аутентификации: после успешной аутентификации сервер отвечает маркером аутентификации, который клиент использует для установления соединения WebSocket и доступа к защищенным ресурсам.

3.Профиль пользователя и история чата (принципы RESTful):

• Конечные точки RESTful: для доступа к информации профиля пользователя или истории чата приложение чата использует конечные точки RESTful (/api/users/{userid} или /api/chats/{chatid}).
• Запросы HTTP GET: клиенты отправляют запросы HTTP GET на эти конечные точки, чтобы получить сведения о профиле пользователя или историю чата.
• Ответы JSON: сервер отвечает представлением запрошенных ресурсов в формате JSON.

4.Управление группой (принципы RESTful):

• Конечные точки RESTful: для управления группами чата приложение использует конечные точки RESTful (/api/groups или /api/groups/{group_id}).
• Запросы HTTP POST и PUT: клиенты отправляют запросы HTTP POST и PUT этим конечным точкам для создания новых групп или обновления информации о группе.
• Уведомления WebSocket: при создании новой группы или обновлении сведений о группе сервер может генерировать события WebSocket, чтобы уведомить подключенных клиентов об изменениях.

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