Интеграция через API. Кратко
API (Application Programming Interface) — это набор способов и правил, по которым можно выполнять определённые действия с системой (например, получить данные или выполнить с ними какое-либо действие). Такой набор правил называют контрактом. Система как бы говорит: «ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если систему рассматривать как чёрный ящик, то API — это набор «ручек», которые доступны пользователю данного ящика и которые он может вертеть и переключать.
Подходы к проектированию API
➖ Contract First означает, что сначала определяется контракт API, а потом пишется код, который его реализует. Преимуществом этого подхода является то, что контракт API является документацией для разработчиков и потребителей API, а также может быть использован для автоматической генерации кода, тестов и клиентских библиотек.
➖ Code First означает, что сначала пишется код, который реализует логику API, а потом из него извлекается контракт API. Преимуществом этого подхода является то, что код является единственным источником правды для API, а также может быть легко изменен и расширен.
Интеграцию через API стоит использовать в тех случаях, когда:
👉 Нужно обмениваться данными или выполнять действия с другой системой в реальном времени. API позволяет отправлять и получать запросы и ответы по сети с минимальной задержкой и максимальной актуальностью данных.
👉 Нужно иметь гибкий и независимый способ доступа к функциональности системы. API позволяет выбирать нужные данные и действия из всего набора возможностей системы, а также не зависит от внутренней реализации и технологии системы.
👉 Нужны безопасность и контроль доступа к системе. API позволяет использовать различные механизмы аутентификации и авторизации для защиты данных и доступа к системе от несанкционированного или злоупотребительского использования.
Однако интеграция через API также имеет некоторые недостатки:
🔻Сложность. API требует знания спецификации контракта и формата данных для каждой конечной точки. Также необходимо учитывать ошибки, исключения и ограничения при работе с API.
🔻Нестабильность. API может изменяться со временем, что может привести к несовместимости или поломке интеграции. Поэтому важно следить за версионированием и обратной совместимостью API.
🔻Зависимость. API может быть недоступен или работать медленно из-за сетевых проблем или перегрузки системы. Поэтому необходимо иметь стратегию обработки сбоев и отказов API.
Какие бывают API:
🌟 SOAP: часто используется в корпоративных системах. Например, он может быть встроен в старые версии CRM-систем или в банковских приложениях.
🌟 REST: очень популярен в современных веб-приложениях. Под этот тип API, например, работают большинство публичных API таких сервисов как Twitter, GitHub или Stripe.
🌟 GraphQL: используется, когда требуется гибкость в выборе данных для запроса и по одному эндпоину (URL) можно получить разные варианты ответов.
🌟 WebSocket: применяется, когда необходимо поддерживать постоянное соединение между клиентом и сервером. Так, он может быть использован в чатах или онлайн-играх.
🌟 gRPC: разработанный Google для высокопроизводительных приложений, он может быть встроен, например, в облачных решениях или микросервисах.
Другие способы интеграции описаны здесь. В следующих постах разберём REST.
📎 Материалы по теме
1. Что такое API? — статья от Amazon
2. Что такое API — статья от Doka
📖 Книги
1. Сергей Константинов. API
2. Арно Лоре. Проектирование веб-API
3. Web API Design: The Missing Link — небольшая книга от Google о проектировании API в REST стиле
▶️ Видео
1. Что такое API — Merion Academy
2. API для начинающих. Пример VK — Marlin
3. Как аналитику спроектировать свой REST API // Демо-занятие курса «Специализация «Системный аналитик»
4. API: под каким углом на них смотреть — доклад c конференции Analyst Days от Мелеховой Анны, Лаборатория Касперского
👍 Примеры открытых API
1. API ВКонтакте — можно потыкать ручками через веб-интерфейс
2. API DaData
3. Пример API Swagger
#api #интеграции
API (Application Programming Interface) — это набор способов и правил, по которым можно выполнять определённые действия с системой (например, получить данные или выполнить с ними какое-либо действие). Такой набор правил называют контрактом. Система как бы говорит: «ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если систему рассматривать как чёрный ящик, то API — это набор «ручек», которые доступны пользователю данного ящика и которые он может вертеть и переключать.
Подходы к проектированию API
➖ Contract First означает, что сначала определяется контракт API, а потом пишется код, который его реализует. Преимуществом этого подхода является то, что контракт API является документацией для разработчиков и потребителей API, а также может быть использован для автоматической генерации кода, тестов и клиентских библиотек.
➖ Code First означает, что сначала пишется код, который реализует логику API, а потом из него извлекается контракт API. Преимуществом этого подхода является то, что код является единственным источником правды для API, а также может быть легко изменен и расширен.
Интеграцию через API стоит использовать в тех случаях, когда:
👉 Нужно обмениваться данными или выполнять действия с другой системой в реальном времени. API позволяет отправлять и получать запросы и ответы по сети с минимальной задержкой и максимальной актуальностью данных.
👉 Нужно иметь гибкий и независимый способ доступа к функциональности системы. API позволяет выбирать нужные данные и действия из всего набора возможностей системы, а также не зависит от внутренней реализации и технологии системы.
👉 Нужны безопасность и контроль доступа к системе. API позволяет использовать различные механизмы аутентификации и авторизации для защиты данных и доступа к системе от несанкционированного или злоупотребительского использования.
Однако интеграция через API также имеет некоторые недостатки:
🔻Сложность. API требует знания спецификации контракта и формата данных для каждой конечной точки. Также необходимо учитывать ошибки, исключения и ограничения при работе с API.
🔻Нестабильность. API может изменяться со временем, что может привести к несовместимости или поломке интеграции. Поэтому важно следить за версионированием и обратной совместимостью API.
🔻Зависимость. API может быть недоступен или работать медленно из-за сетевых проблем или перегрузки системы. Поэтому необходимо иметь стратегию обработки сбоев и отказов API.
Какие бывают API:
🌟 SOAP: часто используется в корпоративных системах. Например, он может быть встроен в старые версии CRM-систем или в банковских приложениях.
🌟 REST: очень популярен в современных веб-приложениях. Под этот тип API, например, работают большинство публичных API таких сервисов как Twitter, GitHub или Stripe.
🌟 GraphQL: используется, когда требуется гибкость в выборе данных для запроса и по одному эндпоину (URL) можно получить разные варианты ответов.
🌟 WebSocket: применяется, когда необходимо поддерживать постоянное соединение между клиентом и сервером. Так, он может быть использован в чатах или онлайн-играх.
🌟 gRPC: разработанный Google для высокопроизводительных приложений, он может быть встроен, например, в облачных решениях или микросервисах.
Другие способы интеграции описаны здесь. В следующих постах разберём REST.
📎 Материалы по теме
1. Что такое API? — статья от Amazon
2. Что такое API — статья от Doka
📖 Книги
1. Сергей Константинов. API
2. Арно Лоре. Проектирование веб-API
3. Web API Design: The Missing Link — небольшая книга от Google о проектировании API в REST стиле
▶️ Видео
1. Что такое API — Merion Academy
2. API для начинающих. Пример VK — Marlin
3. Как аналитику спроектировать свой REST API // Демо-занятие курса «Специализация «Системный аналитик»
4. API: под каким углом на них смотреть — доклад c конференции Analyst Days от Мелеховой Анны, Лаборатория Касперского
👍 Примеры открытых API
1. API ВКонтакте — можно потыкать ручками через веб-интерфейс
2. API DaData
3. Пример API Swagger
#api #интеграции
🔥24❤5👍2
REST. Краткий обзор
REST (REpresentational State Transfer) – это архитектурный стиль, набор принципов проектирования, позволяющий добиться определённых свойств системы, таких как:
✹ Производительность
✹ Масштабируемость
✹ Гибкость к изменениям
✹ Отказоустойчивость
✹ Простота поддержки
🔹REST — это не протокол. Он не определяет правила о том, как мы должны передавать запросы, какая у них должна быть структура, что мы должны возвращать в ошибках. В качестве протокола использует REST HTTP.
🔹REST API (RESTful API) – это API, которые соответствует принципам REST.
🔹В архитектурном стиле REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, CSV, HTML и др.
🔹REST фокусируется на ресурсах, доступ к которым осуществляется через URL.
🔹Ресурс — это то, что доступно клиенту. Например, если мы пишем приложение для управления задачами, ресурсами могут быть Пользователь или Задача.
🔹Ресурс имеет свой адрес (URI), по которому его можно найти и запросить.
🔹HTTP-глаголы — это действия, которые можно выполнить над ресурсом. Например:
Принципы REST
1️⃣ Клиент-серверная архитектура – разделение зон ответственности между клиентом (кто использует API) и сервером (кто предоставляет API).
Преимущества:
+ Масштабируемость. Если растёт нагрузка на сервер, мы можем добавить ещё серверы
+ Простота поддержки и гибкость изменений. Если нам нужно внести изменения, мы можем сделать это на сервере, а клиент будет видеть изменения без каких-либо доработок на своей стороне.
Недостатки:
– Единая точка отказа в виде сервера.
– Увеличение нагрузки на сервер и сеть. Так как клиент будет совершать меньше каких-либо действий самостоятельно, вырастет количество запросов между клиентом и сервером.
2️⃣ Stateless – сервер не должен хранить у себя информацию о сессии с клиентом. Всю необходимую информацию для обработки клиент должен передавать в запросе. Сервер не может знать что-либо о предыдущих запросах от этого клиента.
Преимущества:
+ Масштабируемость. Когда запрос имеет всю нужную информацию для обработки, то можно сделать несколько одинаковых серверов-обработчиков: допустим, 10 вместо одного
+ Простота поддержки. Можно увидеть в логах, какое сообщение приходило от клиента и какой ответ он получил
+ Кэширование
Недостатки:
– Усложнение логики клиента. Именно на стороне клиента нам нужно хранить всю информацию о состоянии, о допустимых действиях, о недопустимых действиях и подобных вещах.
– Увеличение нагрузки на сеть. Каждый раз мы передаём всю информацию, весь контекст. Таким образом, больше информации гоняем по сети.
3️⃣ Кэширование
В оригинале это говорит о том, что каждый ответ сервера должен иметь пометку, можно ли его кэшировать. Кэширование снижает нагрузку на серверы и ускоряет получение ответа для клиента.
Однако это может быть достаточно сложно в реализации. Нужно учитывать, что если отдаём какие-то данные, которые сохранили раньше, то они могли устареть
4️⃣ Единообразие интерфейса. HATEOAS
Все запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от того, откуда поступает запрос.
Hypermedia as the Engine of Application State (HATEOAS) — одно из ограничений REST, согласно которому сервер возвращает не только ресурс, но и его связи с другими ресурсами и действия, которые можно с ним совершить. Например, если мы запрашиваем информацию о книге с помощью
5️⃣ Слоистая архитектура
Ни клиент, ни сервер не должны знать о том, как происходит цепочка вызовов дальше своих прямых соседей. Между клиентом и сервером могут находится балансировщики, прокси, кэши.
6️⃣ Код по требованию
Передача исполняемого кода от сервера клиенту. Это позволяет клиенту стать гибче
📎 Материалы
1. REST, что же ты такое? — статья и вебинар от Systems Education
2. Что такое REST API? — IBM
3. Бесплатный курс по документированию REST API
4. Серия видео Всё о REST API
#api #интеграции
REST (REpresentational State Transfer) – это архитектурный стиль, набор принципов проектирования, позволяющий добиться определённых свойств системы, таких как:
✹ Производительность
✹ Масштабируемость
✹ Гибкость к изменениям
✹ Отказоустойчивость
✹ Простота поддержки
🔹REST — это не протокол. Он не определяет правила о том, как мы должны передавать запросы, какая у них должна быть структура, что мы должны возвращать в ошибках. В качестве протокола использует REST HTTP.
🔹REST API (RESTful API) – это API, которые соответствует принципам REST.
🔹В архитектурном стиле REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, CSV, HTML и др.
🔹REST фокусируется на ресурсах, доступ к которым осуществляется через URL.
🔹Ресурс — это то, что доступно клиенту. Например, если мы пишем приложение для управления задачами, ресурсами могут быть Пользователь или Задача.
🔹Ресурс имеет свой адрес (URI), по которому его можно найти и запросить.
🔹HTTP-глаголы — это действия, которые можно выполнить над ресурсом. Например:
GET /schedule/speech/id413 — получить информацию об объекте с идентификатором 413Принципы REST
1️⃣ Клиент-серверная архитектура – разделение зон ответственности между клиентом (кто использует API) и сервером (кто предоставляет API).
Преимущества:
+ Масштабируемость. Если растёт нагрузка на сервер, мы можем добавить ещё серверы
+ Простота поддержки и гибкость изменений. Если нам нужно внести изменения, мы можем сделать это на сервере, а клиент будет видеть изменения без каких-либо доработок на своей стороне.
Недостатки:
– Единая точка отказа в виде сервера.
– Увеличение нагрузки на сервер и сеть. Так как клиент будет совершать меньше каких-либо действий самостоятельно, вырастет количество запросов между клиентом и сервером.
2️⃣ Stateless – сервер не должен хранить у себя информацию о сессии с клиентом. Всю необходимую информацию для обработки клиент должен передавать в запросе. Сервер не может знать что-либо о предыдущих запросах от этого клиента.
Преимущества:
+ Масштабируемость. Когда запрос имеет всю нужную информацию для обработки, то можно сделать несколько одинаковых серверов-обработчиков: допустим, 10 вместо одного
+ Простота поддержки. Можно увидеть в логах, какое сообщение приходило от клиента и какой ответ он получил
+ Кэширование
Недостатки:
– Усложнение логики клиента. Именно на стороне клиента нам нужно хранить всю информацию о состоянии, о допустимых действиях, о недопустимых действиях и подобных вещах.
– Увеличение нагрузки на сеть. Каждый раз мы передаём всю информацию, весь контекст. Таким образом, больше информации гоняем по сети.
3️⃣ Кэширование
В оригинале это говорит о том, что каждый ответ сервера должен иметь пометку, можно ли его кэшировать. Кэширование снижает нагрузку на серверы и ускоряет получение ответа для клиента.
Однако это может быть достаточно сложно в реализации. Нужно учитывать, что если отдаём какие-то данные, которые сохранили раньше, то они могли устареть
4️⃣ Единообразие интерфейса. HATEOAS
Все запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от того, откуда поступает запрос.
Hypermedia as the Engine of Application State (HATEOAS) — одно из ограничений REST, согласно которому сервер возвращает не только ресурс, но и его связи с другими ресурсами и действия, которые можно с ним совершить. Например, если мы запрашиваем информацию о книге с помощью
GET /books/1, то сервер может вернуть действия, которые можно сделать с книгой, например, добавить в корзину.5️⃣ Слоистая архитектура
Ни клиент, ни сервер не должны знать о том, как происходит цепочка вызовов дальше своих прямых соседей. Между клиентом и сервером могут находится балансировщики, прокси, кэши.
6️⃣ Код по требованию
Передача исполняемого кода от сервера клиенту. Это позволяет клиенту стать гибче
📎 Материалы
1. REST, что же ты такое? — статья и вебинар от Systems Education
2. Что такое REST API? — IBM
3. Бесплатный курс по документированию REST API
4. Серия видео Всё о REST API
#api #интеграции
❤17👍8
Ликбез по понятиям: REST, API, HTTP
В чём разница между REST и API?
API – это набор ручек (методов), с помощью которых мы можем делать определённые действия с внешней системой. Система для нас чёрный ящик, мы знаем только, какие методы мы можем вызвать, по каким форматам передавать запросы и какие мы получим в результате. То есть, грубо говоря, API отвечает на вопрос “что”.
REST – это архитектурный стиль, который всего лишь определяет набор принципов и ограничений. REST отвечает на вопрос как спроектировать API. Не все API – это REST, но всегда REST имеет дело с API.
В чём разница между HTTP и REST?
HTTP – это протокол, который описывает, как происходит обмен данными по сети. HTTP определяет структуру запросов и ответов, набор допустимых методов, форматов сообщений, заголовков и так далее.
REST — это архитектурный стиль, но не протокол. Он не определяет правила о том, как мы должны передавать запросы, какая у них должна быть структура, что мы должны возвращать в ошибках.
Может ли REST не использовать HTTP?
Да, может, но зачем? С одной стороны, REST не говорит, что нужно обязательно использовать HTTP. С другой стороны, HTTP специально спроектирован под REST. Более того, создатель REST и HTTP – это один и тот же человек, Рэй Филдинг.
Можно ли использовать HTTP без REST?
Можно, но зачем? Допустим, у нас есть CMS-система, которая предоставляет API для управления статьями. Если мы хотим удалить определённый объект, мы можем вызвать, например, такой метод:
Во-первых, он нарушает принцип единообразного интерфейса, так как не идентифицирует ресурс по его URI, а передает его идентификатор в теле запроса.
Во-вторых, он нарушает принцип манипуляции ресурсами через представления, так как не использует подходящий HTTP-метод для удаления ресурса
В парадигме REST мы должны были сделать примерно так:
REST предполагает только JSON?
В архитектурном стиле REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, RSS, CSV, HTML и другие.
Какие бывают API помимо REST?
🔹 SOAP – протокол, который работает на XML и имеет стандарт. В отличие от REST, SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. А ещё SOAP не может использовать другой формат представления данных, кроме XML. Применяется в системах, где нужна жёсткая стандартизация, а также в legacy.
🔹 gRPC – это фреймворк для удалённого вызова процедур (RPC). Формат сообщений: бинарным Protocol Buffers, а протокол HTTP/2. Это позволяет преодолеть повысить производительность по сравнению с тяжеловесным SOAP и избыточной нагрузкой на сеть в REST. gRPC используется в высоконагруженных системах, где нужна высокая пропускная способность и производительность при низких требованиях к сети
🔹 GraphQL – это язык запросов для API, который позволяет клиентам получать только те данные, которые им нужны. Вместо вызова нескольких ресурсов в REST, в GraphQL мы можем отправить только один запрос к одной конечной точке, указав какие данные и в какой структуре нам нужны. Он уменьшает избыточность запросов и нагрузку на сеть. В качестве транспортного протокола использует HTTP.
🔹 WebSocket — это протокол, который позволяет клиенту установить двухстороннюю («дуплексную») связь с сервером. Это означает, что он может одновременно и получать, и передавать информацию. Веб-сокет делает это множество раз в одном открытом соединении. В этом и заключается его основное преимущество по сравнению с традиционным HTTP, который является однонаправленным.
💬 Вы можете писать свои вопросы в комментариях, мы дополним пост.
📎 Материалы по теме
1. HTTP. Что нужно знать аналитику
2. Как выбрать тип межсистемной интеграции
3. WebSocket: что это, когда следует использовать и какие преимущества дает
#api #интеграции
В чём разница между REST и API?
API – это набор ручек (методов), с помощью которых мы можем делать определённые действия с внешней системой. Система для нас чёрный ящик, мы знаем только, какие методы мы можем вызвать, по каким форматам передавать запросы и какие мы получим в результате. То есть, грубо говоря, API отвечает на вопрос “что”.
REST – это архитектурный стиль, который всего лишь определяет набор принципов и ограничений. REST отвечает на вопрос как спроектировать API. Не все API – это REST, но всегда REST имеет дело с API.
В чём разница между HTTP и REST?
HTTP – это протокол, который описывает, как происходит обмен данными по сети. HTTP определяет структуру запросов и ответов, набор допустимых методов, форматов сообщений, заголовков и так далее.
REST — это архитектурный стиль, но не протокол. Он не определяет правила о том, как мы должны передавать запросы, какая у них должна быть структура, что мы должны возвращать в ошибках.
Может ли REST не использовать HTTP?
Да, может, но зачем? С одной стороны, REST не говорит, что нужно обязательно использовать HTTP. С другой стороны, HTTP специально спроектирован под REST. Более того, создатель REST и HTTP – это один и тот же человек, Рэй Филдинг.
Можно ли использовать HTTP без REST?
Можно, но зачем? Допустим, у нас есть CMS-система, которая предоставляет API для управления статьями. Если мы хотим удалить определённый объект, мы можем вызвать, например, такой метод:
POST /delete_article, а в теле запроса передать id=1. Мы вызвали HTTP-метод POST, однако такой API не соответствует парадигме REST, то есть не является RESTful API. И вот почему.Во-первых, он нарушает принцип единообразного интерфейса, так как не идентифицирует ресурс по его URI, а передает его идентификатор в теле запроса.
Во-вторых, он нарушает принцип манипуляции ресурсами через представления, так как не использует подходящий HTTP-метод для удаления ресурса
В парадигме REST мы должны были сделать примерно так:
DELETE /articles/1/.REST предполагает только JSON?
В архитектурном стиле REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, RSS, CSV, HTML и другие.
Какие бывают API помимо REST?
🔹 SOAP – протокол, который работает на XML и имеет стандарт. В отличие от REST, SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. А ещё SOAP не может использовать другой формат представления данных, кроме XML. Применяется в системах, где нужна жёсткая стандартизация, а также в legacy.
🔹 gRPC – это фреймворк для удалённого вызова процедур (RPC). Формат сообщений: бинарным Protocol Buffers, а протокол HTTP/2. Это позволяет преодолеть повысить производительность по сравнению с тяжеловесным SOAP и избыточной нагрузкой на сеть в REST. gRPC используется в высоконагруженных системах, где нужна высокая пропускная способность и производительность при низких требованиях к сети
🔹 GraphQL – это язык запросов для API, который позволяет клиентам получать только те данные, которые им нужны. Вместо вызова нескольких ресурсов в REST, в GraphQL мы можем отправить только один запрос к одной конечной точке, указав какие данные и в какой структуре нам нужны. Он уменьшает избыточность запросов и нагрузку на сеть. В качестве транспортного протокола использует HTTP.
🔹 WebSocket — это протокол, который позволяет клиенту установить двухстороннюю («дуплексную») связь с сервером. Это означает, что он может одновременно и получать, и передавать информацию. Веб-сокет делает это множество раз в одном открытом соединении. В этом и заключается его основное преимущество по сравнению с традиционным HTTP, который является однонаправленным.
💬 Вы можете писать свои вопросы в комментариях, мы дополним пост.
📎 Материалы по теме
1. HTTP. Что нужно знать аналитику
2. Как выбрать тип межсистемной интеграции
3. WebSocket: что это, когда следует использовать и какие преимущества дает
#api #интеграции
🔥13👍12❤3
Виртуализация, контейнеризация и оркестрация
🔹 Виртуализация – это технология создания виртуальных машин на одном физическом сервере. Такие виртуальные машины (ВМ) полностью изолированы друг от друга: на них можно ставить разные операционные системы.
Виртуализация работает так:
1. На физический сервер ставится ОС и гипервизор – специальное ПО для распределения вычислительных ресурсов между ВМ
2. Создаются виртуальные машины, при этом на каждую ВМ устанавливается ОС
🔸 Контейнеризация — метод, с помощью которого код упаковывается в единый исполняемый файл вместе с библиотеками и зависимостями. Такой файл называют контейнером. Контейнер не зависит от настроек основной операционной системы и может работать на любой платформе или в облаке. Чаще всего для контейнеризации используется Docker.
Контейнеризация работает так:
1. На физический сервер ставится ОС
2. Формируется образ контейнера – представление, в которое упаковывается код со всеми зависимостями
3. Контейнер распаковывается на сервере и использует ядро ОС сервера. Поэтому он не требует установки отдельной ОС.
Назначение контейнеризации
1️⃣ Решается проблема с зависимостями в разных окружениях. Отлаженное на одном компьютере приложение можно легко развернуть на другом, ведь контейнер содержит все необходимые зависимости.
2️⃣ Использование в микросервисной архитектуре. Контейнеры хорошо подходят для приложений на основе микросервисов: можно проверить работоспособность каждого контейнера, ограничить каждую службу определенными ресурсами, запускать и останавливать их независимо друг от друга.
3️⃣ Контроль ресурсов и снижение нагрузки на систему благодаря тому, что каждый контейнер не содержит образ ОС.
4️⃣ Изоляция ошибок. Выход из строя одного контейнера не влияет на дальнейшую работу других контейнеров.
Виртуальные машины vs контейнеры
🔹 Виртуальная машина (ВМ) — операционная система (ОС), которая развернута внутри другой операционной системы. ВМ имеет свое ядро и некоторые обособленные ресурсы.
🔸 Контейнеры — это модули, в каждом из которых запускается одно приложение. Они занимают меньше памяти, использую небольшое количество ресурсов и почти не зависят от операционной системы физического сервера.
🔹 Виртуальная машина фактически представляет полноценную ОС с ядром, что требует больше аппаратных ресурсов (объемы оперативной памяти и хранилища, процессорные мощности).
🔸 Контейнер содержит сжатую версию ОС и использует общее ядро физического сервера, поэтому требует меньше аппаратных ресурсов
🔹 Виртуальные машины могут запускать любое ядро операционной системы независимо от основной операционной системы. Допустим, если на сервере Linux, то виртуальная машина может быть Windows.
🔸 Контейнер должен быть совместим с ядром ОС сервера. Допустим, если на сервере Linux, то и контейнер должен использовать Linux.
Оркестрация
Оркестрация – автоматизация управления контейнерами. Например, если контейнер выходит из строя, оркестратор запустит другой контейнер.
Технология возникла потому, что контейнерные приложения могут быть сложными и при их производстве может потребоваться несколько сотен отдельных контейнеров, которыми трудно управлять. Чаще всего для оркестрации используется Kubernetes.
Функции оркестратора
1️⃣ Управление контейнерами на нескольких физических серверах одновременно
2️⃣ Оптимизация ресурсов используемого оборудования
3️⃣ Автоматическое развертывание и обновления приложений
4️⃣ Подключение и добавление хранилищ для запуска приложений с отслеживанием состояния
5️⃣ Масштабирование контейнеров на лету
📎 Материалы по теме
1. Документация Docker
2. Документация Kubernetes
3. Контейнеризация приложений: что это такое и когда стоит использовать
4. Виртуализация и контейнеризация: обзор технологий и в чем разница
5. Что такое контейнеризация — Yandex Cloud
6. Контейнеризация понятным языком — Интервью с System Engineers (текст)
7. Docker и Kubernetes — чем отличаются технологии контейнеризации
#инфраструктура #оркестрация #контейнеризация #виртуализация
🔹 Виртуализация – это технология создания виртуальных машин на одном физическом сервере. Такие виртуальные машины (ВМ) полностью изолированы друг от друга: на них можно ставить разные операционные системы.
Виртуализация работает так:
1. На физический сервер ставится ОС и гипервизор – специальное ПО для распределения вычислительных ресурсов между ВМ
2. Создаются виртуальные машины, при этом на каждую ВМ устанавливается ОС
🔸 Контейнеризация — метод, с помощью которого код упаковывается в единый исполняемый файл вместе с библиотеками и зависимостями. Такой файл называют контейнером. Контейнер не зависит от настроек основной операционной системы и может работать на любой платформе или в облаке. Чаще всего для контейнеризации используется Docker.
Контейнеризация работает так:
1. На физический сервер ставится ОС
2. Формируется образ контейнера – представление, в которое упаковывается код со всеми зависимостями
3. Контейнер распаковывается на сервере и использует ядро ОС сервера. Поэтому он не требует установки отдельной ОС.
Назначение контейнеризации
1️⃣ Решается проблема с зависимостями в разных окружениях. Отлаженное на одном компьютере приложение можно легко развернуть на другом, ведь контейнер содержит все необходимые зависимости.
2️⃣ Использование в микросервисной архитектуре. Контейнеры хорошо подходят для приложений на основе микросервисов: можно проверить работоспособность каждого контейнера, ограничить каждую службу определенными ресурсами, запускать и останавливать их независимо друг от друга.
3️⃣ Контроль ресурсов и снижение нагрузки на систему благодаря тому, что каждый контейнер не содержит образ ОС.
4️⃣ Изоляция ошибок. Выход из строя одного контейнера не влияет на дальнейшую работу других контейнеров.
Виртуальные машины vs контейнеры
🔹 Виртуальная машина (ВМ) — операционная система (ОС), которая развернута внутри другой операционной системы. ВМ имеет свое ядро и некоторые обособленные ресурсы.
🔸 Контейнеры — это модули, в каждом из которых запускается одно приложение. Они занимают меньше памяти, использую небольшое количество ресурсов и почти не зависят от операционной системы физического сервера.
🔹 Виртуальная машина фактически представляет полноценную ОС с ядром, что требует больше аппаратных ресурсов (объемы оперативной памяти и хранилища, процессорные мощности).
🔸 Контейнер содержит сжатую версию ОС и использует общее ядро физического сервера, поэтому требует меньше аппаратных ресурсов
🔹 Виртуальные машины могут запускать любое ядро операционной системы независимо от основной операционной системы. Допустим, если на сервере Linux, то виртуальная машина может быть Windows.
🔸 Контейнер должен быть совместим с ядром ОС сервера. Допустим, если на сервере Linux, то и контейнер должен использовать Linux.
Оркестрация
Оркестрация – автоматизация управления контейнерами. Например, если контейнер выходит из строя, оркестратор запустит другой контейнер.
Технология возникла потому, что контейнерные приложения могут быть сложными и при их производстве может потребоваться несколько сотен отдельных контейнеров, которыми трудно управлять. Чаще всего для оркестрации используется Kubernetes.
Функции оркестратора
1️⃣ Управление контейнерами на нескольких физических серверах одновременно
2️⃣ Оптимизация ресурсов используемого оборудования
3️⃣ Автоматическое развертывание и обновления приложений
4️⃣ Подключение и добавление хранилищ для запуска приложений с отслеживанием состояния
5️⃣ Масштабирование контейнеров на лету
📎 Материалы по теме
1. Документация Docker
2. Документация Kubernetes
3. Контейнеризация приложений: что это такое и когда стоит использовать
4. Виртуализация и контейнеризация: обзор технологий и в чем разница
5. Что такое контейнеризация — Yandex Cloud
6. Контейнеризация понятным языком — Интервью с System Engineers (текст)
7. Docker и Kubernetes — чем отличаются технологии контейнеризации
#инфраструктура #оркестрация #контейнеризация #виртуализация
🔥13👍5❤3
Forwarded from Библиотека Системного Аналитика
REST-in-Practice.pdf
12.3 MB
REST in Practice: Hypermedia and Systems Architecture (2010)
Авторы: Ian Robinson, Jim Webber, Savas Parastatidis
Язык: английский.
Целевая аудитория: начинающие разработчики.
REST - это популярный архитектурный стиль взаимодействия компонентов распределённого приложения в сети. В настоящем руководстве авторы познакомят вас с основами построения и работы REST архитектуры, с основными HTTP методами, статус-кодами и популярными шаблонами проектирования бизнес-приложений.
В книге рассматриваются следующие темы:
✔️ основы REST;
✔️ CRUD операции;
✔️ популярные паттерны;
✔️ безопасность в сети и многое другое.
Преимущества:
➕ многочисленные примеры;
➕ подробные объяснения;
➕ примеры на C# и Java.
Недостатки:
➖ местами устарелый материал;
➖ раскрыты не все особенности REST.
#api #интеграции
Авторы: Ian Robinson, Jim Webber, Savas Parastatidis
Язык: английский.
Целевая аудитория: начинающие разработчики.
REST - это популярный архитектурный стиль взаимодействия компонентов распределённого приложения в сети. В настоящем руководстве авторы познакомят вас с основами построения и работы REST архитектуры, с основными HTTP методами, статус-кодами и популярными шаблонами проектирования бизнес-приложений.
В книге рассматриваются следующие темы:
✔️ основы REST;
✔️ CRUD операции;
✔️ популярные паттерны;
✔️ безопасность в сети и многое другое.
Преимущества:
➕ многочисленные примеры;
➕ подробные объяснения;
➕ примеры на C# и Java.
Недостатки:
➖ местами устарелый материал;
➖ раскрыты не все особенности REST.
#api #интеграции
👍4
📎 Подборка материалов по изучению REST
📄 Статьи
1. REST, что же ты такое? — статья и вебинар от Systems Education
2. Что такое REST API? — IBM
3. Базовые понятия REST API
4. Разработка web API — краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя
5. Лучшие практики разработки REST API: 20 советов
6. Как тестировать методы REST API
7. REST в реальном мире и практика гипермедиа
▶️ Видео и вебинары
1. REST, что же ты такое?! Понятное введение в технологию. Андрей Бураков
2. Андрей Бураков. REST, почему ты такой? Скрытые смыслы популярной парадигмы.
3. Серия коротких видео Всё о REST API
4. Как аналитику спроектировать свой REST API // Демо-занятие курса «Специализация «Системный аналитик»
5. Документация REST API / Артём Кузвесов (Ideco)
🎓 Курсы
1. Бесплатный курс по документированию REST API
📖 Книги
1. Арно Лоре. Проектирование веб-API
2. Сергей Константинов. API
3. REST in Practice: Hypermedia and Systems Architecture
➕ Другое
1. Шаблон документации REST API
2. Шаблон документации микросервисов от МТС
#api #интеграции #подборка
📄 Статьи
1. REST, что же ты такое? — статья и вебинар от Systems Education
2. Что такое REST API? — IBM
3. Базовые понятия REST API
4. Разработка web API — краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя
5. Лучшие практики разработки REST API: 20 советов
6. Как тестировать методы REST API
7. REST в реальном мире и практика гипермедиа
▶️ Видео и вебинары
1. REST, что же ты такое?! Понятное введение в технологию. Андрей Бураков
2. Андрей Бураков. REST, почему ты такой? Скрытые смыслы популярной парадигмы.
3. Серия коротких видео Всё о REST API
4. Как аналитику спроектировать свой REST API // Демо-занятие курса «Специализация «Системный аналитик»
5. Документация REST API / Артём Кузвесов (Ideco)
🎓 Курсы
1. Бесплатный курс по документированию REST API
📖 Книги
1. Арно Лоре. Проектирование веб-API
2. Сергей Константинов. API
3. REST in Practice: Hypermedia and Systems Architecture
➕ Другое
1. Шаблон документации REST API
2. Шаблон документации микросервисов от МТС
#api #интеграции #подборка
❤12🔥9👍1
⚙️ Что нужно знать про асинхронные интеграции
Асинхронная интеграция – это такая интеграция, когда одна система отправляет сообщение другой и не ждет подтверждения или ответа, а продолжает работу. Наиболее частый способ реализации асинхронной интеграции – это очереди (брокеры) сообщений, такие как Kafka или RabbitMQ. Очереди сообщений позволяют передавать сообщения между компонентами распределенных приложений. Передавать сообщения в очереди можно с помощью API.
Зачем нужна асинхронная интеграция:
✅ Слабая связанность сервисов. Наиболее часто применяется паттерн "издатель-подписчик". Сервис-издатель публикует сообщения в очереди и далее судьбой сообщений не интересуется. Т.е количество подписчиков и алгоритм использования сообщений сервис-издатель никак не задевают. В любой момент времени сообщения может читать один подписчик, тысяча, миллион или даже вообще никто не читать.
✅ Легкость масштабирования. Архитектура "издатель-подписчик" позволяет нам в любой момент поменять архитектуру приложения, изменить количество микросервисов, но при этом не менять код сервиса(ов)-публикатора(ов). Сервисы-потребители, при этом никак не влияют на работу друг друга. Наоборот, это также работает: можно увеличить количество публикаторов и их логику, подписчики, при этом, разницы не почувствуют.
✅ Повышение надежности. Выход из строя одного из компонентов не сказывается на работе всей системы: при восстановлении он обработает сообщение, находящееся в очереди. Ваш веб-сайт по-прежнему может работать, даже если задерживается часть обработки заказа, например, из-за проблем с сервером БД или системой электронной почты. Правда, при этом очередь сама приобретает статус SPoF (Single Point Of Failure), поэтому необходимо заранее предусмотреть действия на случай ее аварийного отключения.
Когда асинхронное взаимодействие лучше не использовать:
⛔️ У вашего приложения простая архитектура и функции, и вы не ожидаете его роста. Важно понимать, что очереди сообщений — это дополнительная сложность. Эту систему также необходимо настраивать, поддерживать, осуществлять мониторинг ее работы и так далее. Да, можно использовать Managed-решение, но вряд ли это будет оправдано для небольших приложений. Добавление очередей должно упрощать архитектуру, а не усложнять ее.
⛔️ Вы используете монолит, в котором разбиение на независимые компоненты невозможно. Если вы не планируете разбивать монолит на микросервисы, но вам требуется асинхронность — для ее реализации обычно достаточно стандартной многопоточной модели
❗️ Также стоит учесть:
1. Очередь – это ещё одна система, которую необходимо поддерживать и на которую нужны мощности.
2. Если брокер выйдет из строя, это может остановить работу многих систем, взаимодействующих с ним. Как минимум необходимо позаботиться о резервном копировании данных.
3. Усложняется отладка. Нужна позаботиться о системе трассировки, чтобы для обнаружения причины ошибок
Как понять, следует ли выбрать асинхронную интеграцию?
Правильный выбор подхода зависит от следующих факторов:
▪️Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным. Асинхронное взаимодействие подходит, когда не требуется немедленный ответ или подтверждение от получателя.
▪️Надежность. Если надежность и отказоустойчивость критичны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
▪️Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.
📎 Полезные материалы
1. Асинхронная интеграция. Что это такое и как её дружить
2. Зачем нужны очереди сообщений в микросервисной архитектуре
3. Что такое очереди сообщений и почему они широко используются в распределенных системах?
4. Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры
5. Брокеры сообщений
Совсем скоро выложим подборку полезных материалов по асинхронной интеграции 😉
#интеграции #async
Асинхронная интеграция – это такая интеграция, когда одна система отправляет сообщение другой и не ждет подтверждения или ответа, а продолжает работу. Наиболее частый способ реализации асинхронной интеграции – это очереди (брокеры) сообщений, такие как Kafka или RabbitMQ. Очереди сообщений позволяют передавать сообщения между компонентами распределенных приложений. Передавать сообщения в очереди можно с помощью API.
Зачем нужна асинхронная интеграция:
✅ Слабая связанность сервисов. Наиболее часто применяется паттерн "издатель-подписчик". Сервис-издатель публикует сообщения в очереди и далее судьбой сообщений не интересуется. Т.е количество подписчиков и алгоритм использования сообщений сервис-издатель никак не задевают. В любой момент времени сообщения может читать один подписчик, тысяча, миллион или даже вообще никто не читать.
✅ Легкость масштабирования. Архитектура "издатель-подписчик" позволяет нам в любой момент поменять архитектуру приложения, изменить количество микросервисов, но при этом не менять код сервиса(ов)-публикатора(ов). Сервисы-потребители, при этом никак не влияют на работу друг друга. Наоборот, это также работает: можно увеличить количество публикаторов и их логику, подписчики, при этом, разницы не почувствуют.
✅ Повышение надежности. Выход из строя одного из компонентов не сказывается на работе всей системы: при восстановлении он обработает сообщение, находящееся в очереди. Ваш веб-сайт по-прежнему может работать, даже если задерживается часть обработки заказа, например, из-за проблем с сервером БД или системой электронной почты. Правда, при этом очередь сама приобретает статус SPoF (Single Point Of Failure), поэтому необходимо заранее предусмотреть действия на случай ее аварийного отключения.
Когда асинхронное взаимодействие лучше не использовать:
⛔️ У вашего приложения простая архитектура и функции, и вы не ожидаете его роста. Важно понимать, что очереди сообщений — это дополнительная сложность. Эту систему также необходимо настраивать, поддерживать, осуществлять мониторинг ее работы и так далее. Да, можно использовать Managed-решение, но вряд ли это будет оправдано для небольших приложений. Добавление очередей должно упрощать архитектуру, а не усложнять ее.
⛔️ Вы используете монолит, в котором разбиение на независимые компоненты невозможно. Если вы не планируете разбивать монолит на микросервисы, но вам требуется асинхронность — для ее реализации обычно достаточно стандартной многопоточной модели
❗️ Также стоит учесть:
1. Очередь – это ещё одна система, которую необходимо поддерживать и на которую нужны мощности.
2. Если брокер выйдет из строя, это может остановить работу многих систем, взаимодействующих с ним. Как минимум необходимо позаботиться о резервном копировании данных.
3. Усложняется отладка. Нужна позаботиться о системе трассировки, чтобы для обнаружения причины ошибок
Как понять, следует ли выбрать асинхронную интеграцию?
Правильный выбор подхода зависит от следующих факторов:
▪️Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным. Асинхронное взаимодействие подходит, когда не требуется немедленный ответ или подтверждение от получателя.
▪️Надежность. Если надежность и отказоустойчивость критичны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
▪️Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.
📎 Полезные материалы
1. Асинхронная интеграция. Что это такое и как её дружить
2. Зачем нужны очереди сообщений в микросервисной архитектуре
3. Что такое очереди сообщений и почему они широко используются в распределенных системах?
4. Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры
5. Брокеры сообщений
Совсем скоро выложим подборку полезных материалов по асинхронной интеграции 😉
#интеграции #async
❤16👍8🔥2
Очереди сообщений. Основные понятия
Очереди сообщений помогают справится с высокой нагрузкой, сокращают время ответа за счёт асинхронной обработки и предотвращает потерю информации при сбоях.
Очереди предоставляют буфер для временного хранения сообщений и конечные точки, которые позволяют подключаться к очереди для отправки и получения сообщений в асинхронном режиме.
🔹 Сообщения могут содержать любые данные, необходимые для выполнения какой-либо операции.
🔹 Компонент, который добавляет сообщение в очередь, называется производителем (Producer).
🔹 Компонент, который извлекает сообщение из очереди и обрабатывает его, называется потребителем (Consumer).
Очередь может использоваться несколькими производителями и потребителями одновременно.
Два подхода к обмену сообщениями
➡️ Метод Pull: потребитель периодически опрашивает очередь на наличие новых сообщений и извлекает их по одному или нескольким за раз.
⬅️ Метод Push: очередь уведомляет потребителя о поступлении нового сообщения и отправляет его ему. Этот метод реализует модель “Издатель/Подписчик” (Publisher/Subscriber), когда потребитель подписывается на определенный тип или тему сообщений и получает только те сообщения, которые ему нужны.
Типы гарантии доставки сообщений
1️⃣ At least once: производитель отправляет сообщение в очередь и ждет подтверждения от брокера. Потребитель извлекает сообщение из очереди и отправляет подтверждение о его обработке. Если производитель не получает подтверждения от брокера, он повторно отправляет сообщение. Сообщение будет обработано хотя бы один раз, но при этом возможны ситуации, когда одно и то же сообщение будет обработано несколько раз. Например, когда соединение прервется в момент отправки или получения подтверждения. Для предотвращения последствий дублирования сообщений необходимо, чтобы компоненты были идемпотентными, то есть повторная обработка одного и того же сообщения не приводила бы к изменению состояния системы или ее данных. Также можно использовать уникальные id для сообщений и хранить список уже обработанных сообщений.
2️⃣ At most once: производитель отправляет сообщение в очередь и не ждёт подтверждения от брокера. Потребитель извлекает сообщение из очереди и не отправляет подтверждение о его обработке. Исключается возможность дублирования сообщений, но при этом сообщение может быть потеряно. Например, когда брокер не сможет сохранить сообщение в очереди или потребитель упадет во время обработки сообщения. Этот тип доставки подходит для тех случаев, когда двойная обработка сообщения может привести к серьезным проблемам, а потеря сообщения не является критичной.
3️⃣ Exactly once. Брокер гарантирует, что каждое сообщение будет доставлено и обработано ровно один раз, без потерь или дублирования. Этот тип доставки является самым желательным, но также самым сложным в реализации. Производитель отправляет сообщение в очередь и ждет подтверждения от брокера о его приеме. Потребитель извлекает сообщение из очереди и отправляет подтверждение об обработке.
В реальности полностью исключить вероятность потери или дублирования сообщений невозможно, поэтому этот тип доставки часто реализуется с некоторыми оговорками или допущениями.
Протоколы
🌐 AMQP — бинарный протокол, который проектировался для взаимодействия между различными вендорами. Основными особенностями AMQP является надежность и совместимость.
🌐 STOMP — простой текстовый протокол обмена сообщениями, который очень похож на HTTP и работает поверх TCP.
🌐 MQTT — очень простой и легковесный протокол, который разрабатывался для минимального использования трафика и работы в нестабильной сети. Все эти качества идеально подошли для использования протокола для общения между устройствами.
📎 Ссылки
1. Асинхронное взаимодействие. Брокеры сообщений
2. Очереди сообщений
3. Apache Kafka: основы технологии
4. Очереди сообщений в бэкенд-архитектуре: как построить надежную систему
5. Стратегии доставки и дедупликации сообщений
#интеграции #async
Очереди сообщений помогают справится с высокой нагрузкой, сокращают время ответа за счёт асинхронной обработки и предотвращает потерю информации при сбоях.
Очереди предоставляют буфер для временного хранения сообщений и конечные точки, которые позволяют подключаться к очереди для отправки и получения сообщений в асинхронном режиме.
🔹 Сообщения могут содержать любые данные, необходимые для выполнения какой-либо операции.
🔹 Компонент, который добавляет сообщение в очередь, называется производителем (Producer).
🔹 Компонент, который извлекает сообщение из очереди и обрабатывает его, называется потребителем (Consumer).
Очередь может использоваться несколькими производителями и потребителями одновременно.
Два подхода к обмену сообщениями
➡️ Метод Pull: потребитель периодически опрашивает очередь на наличие новых сообщений и извлекает их по одному или нескольким за раз.
⬅️ Метод Push: очередь уведомляет потребителя о поступлении нового сообщения и отправляет его ему. Этот метод реализует модель “Издатель/Подписчик” (Publisher/Subscriber), когда потребитель подписывается на определенный тип или тему сообщений и получает только те сообщения, которые ему нужны.
Типы гарантии доставки сообщений
1️⃣ At least once: производитель отправляет сообщение в очередь и ждет подтверждения от брокера. Потребитель извлекает сообщение из очереди и отправляет подтверждение о его обработке. Если производитель не получает подтверждения от брокера, он повторно отправляет сообщение. Сообщение будет обработано хотя бы один раз, но при этом возможны ситуации, когда одно и то же сообщение будет обработано несколько раз. Например, когда соединение прервется в момент отправки или получения подтверждения. Для предотвращения последствий дублирования сообщений необходимо, чтобы компоненты были идемпотентными, то есть повторная обработка одного и того же сообщения не приводила бы к изменению состояния системы или ее данных. Также можно использовать уникальные id для сообщений и хранить список уже обработанных сообщений.
2️⃣ At most once: производитель отправляет сообщение в очередь и не ждёт подтверждения от брокера. Потребитель извлекает сообщение из очереди и не отправляет подтверждение о его обработке. Исключается возможность дублирования сообщений, но при этом сообщение может быть потеряно. Например, когда брокер не сможет сохранить сообщение в очереди или потребитель упадет во время обработки сообщения. Этот тип доставки подходит для тех случаев, когда двойная обработка сообщения может привести к серьезным проблемам, а потеря сообщения не является критичной.
3️⃣ Exactly once. Брокер гарантирует, что каждое сообщение будет доставлено и обработано ровно один раз, без потерь или дублирования. Этот тип доставки является самым желательным, но также самым сложным в реализации. Производитель отправляет сообщение в очередь и ждет подтверждения от брокера о его приеме. Потребитель извлекает сообщение из очереди и отправляет подтверждение об обработке.
В реальности полностью исключить вероятность потери или дублирования сообщений невозможно, поэтому этот тип доставки часто реализуется с некоторыми оговорками или допущениями.
Протоколы
🌐 AMQP — бинарный протокол, который проектировался для взаимодействия между различными вендорами. Основными особенностями AMQP является надежность и совместимость.
🌐 STOMP — простой текстовый протокол обмена сообщениями, который очень похож на HTTP и работает поверх TCP.
🌐 MQTT — очень простой и легковесный протокол, который разрабатывался для минимального использования трафика и работы в нестабильной сети. Все эти качества идеально подошли для использования протокола для общения между устройствами.
📎 Ссылки
1. Асинхронное взаимодействие. Брокеры сообщений
2. Очереди сообщений
3. Apache Kafka: основы технологии
4. Очереди сообщений в бэкенд-архитектуре: как построить надежную систему
5. Стратегии доставки и дедупликации сообщений
#интеграции #async
🔥18👍8❤4
🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений
📄 Статьи
1. Зачем нужны очереди сообщений в микросервисной архитектуре — основы от VK Cloud
2. Асинхронная интеграция. Что это такое и как её дружить — обзорная статья на Хабре
3. Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры — статья на Хабре от Сбера
4. Брокеры сообщений — статья от Timeweb Cloud по основам брокеров сообщений
5. Стратегии доставки и дедупликации сообщений — статья на Хабре от OTUS
6. Асинхронное взаимодействие. Брокеры сообщений — чуть глубже по брокерам сообщений и немного про Кафку
7. Apache Kafka: основы технологии — от Слёрм
8. RabbitMQ для аналитика: практический ликбез — BABOK School
9. AMQP на примере RabbitMQ: как же «готовить кролика»? — простым языком о RabbitMQ
10. Соседняя очередь всегда движется быстрее — углубленная статья на Хабре про то, как устроены очереди и какие есть решения
11. Угнать за 5 миллисекунд: как мы наладили быструю доставку данных в сложной биржевой системе с помощью Tarantool — практический кейс проекта для Московской биржи
12. Как построить систему, способную выдерживать нагрузку в 5 млн rps — практический пример от Ozon. Тут будет про gRPC-прокси перед Кафкой
▶️ Видео и вебинары
1. Принципы и приёмы обработки очередей / Константин Осипов (то же, только статья)
2. Интеграция распределенных систем через обмен сообщениями — базовый вебинар
3. Реализация геораспределенной персистентной очереди сообщений / Василий Богонатов (Яндекс)
4. Микросервисы: Коммуникации через очередь сообщений
5. Очереди сообщений с RabbitMQ: что такое, когда нужно, какие проблемы решает
6. Как правильно выбирать очередь / Владимир Перепелица (Mail.Ru Group)
7. Битва брокеров сообщений: Kafka, RabbitMQ, SQS — Яндекс.Практикум
📖 Книги
1. Гайвин Рой. RabbitMQ для профессионалов — онлайн книга на русском
2. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
3. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — на русском
4. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka
Если у кого есть, чем поделиться - пишите в комментариях!
#интеграции #подборка #async
📄 Статьи
1. Зачем нужны очереди сообщений в микросервисной архитектуре — основы от VK Cloud
2. Асинхронная интеграция. Что это такое и как её дружить — обзорная статья на Хабре
3. Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры — статья на Хабре от Сбера
4. Брокеры сообщений — статья от Timeweb Cloud по основам брокеров сообщений
5. Стратегии доставки и дедупликации сообщений — статья на Хабре от OTUS
6. Асинхронное взаимодействие. Брокеры сообщений — чуть глубже по брокерам сообщений и немного про Кафку
7. Apache Kafka: основы технологии — от Слёрм
8. RabbitMQ для аналитика: практический ликбез — BABOK School
9. AMQP на примере RabbitMQ: как же «готовить кролика»? — простым языком о RabbitMQ
10. Соседняя очередь всегда движется быстрее — углубленная статья на Хабре про то, как устроены очереди и какие есть решения
11. Угнать за 5 миллисекунд: как мы наладили быструю доставку данных в сложной биржевой системе с помощью Tarantool — практический кейс проекта для Московской биржи
12. Как построить систему, способную выдерживать нагрузку в 5 млн rps — практический пример от Ozon. Тут будет про gRPC-прокси перед Кафкой
▶️ Видео и вебинары
1. Принципы и приёмы обработки очередей / Константин Осипов (то же, только статья)
2. Интеграция распределенных систем через обмен сообщениями — базовый вебинар
3. Реализация геораспределенной персистентной очереди сообщений / Василий Богонатов (Яндекс)
4. Микросервисы: Коммуникации через очередь сообщений
5. Очереди сообщений с RabbitMQ: что такое, когда нужно, какие проблемы решает
6. Как правильно выбирать очередь / Владимир Перепелица (Mail.Ru Group)
7. Битва брокеров сообщений: Kafka, RabbitMQ, SQS — Яндекс.Практикум
📖 Книги
1. Гайвин Рой. RabbitMQ для профессионалов — онлайн книга на русском
2. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
3. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — на русском
4. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka
Если у кого есть, чем поделиться - пишите в комментариях!
#интеграции #подборка #async
🔥22👍5🎉1
Contract First vs Code First: что выбрать
Существует два подхода к проектированию API.
🔹 Code first — сначала пишем код, потом по нему генерируем контракт
🔹 Contract first — сначала создаем контракт, потом по нему пишем или генерируем код
Контракт — это соглашение между поставщиком и потребителем об услуге. Чтобы правильно использовать услугу, потребитель сервиса должен полностью понимать договор.
Контракт включает в себя детали многих аспектов обслуживания, таких как:
1. Как вызвать сервис
2. Какой транспорт используется
3. Каковы структуры запроса и ответа
Преимущества Code First
1. Контракты с минимальными усилиями. Это всего лишь побочный продукт разработки сервиса, так как он может быть автоматически сгенерирован из кода.
2. Синхронизация кода и контракта: поскольку контракт генерируется из кода, они всегда синхронизируются друг с другом.
Недостатки Code First
1. Нет параллельной разработки. Производитель услуг и потребители услуг не могут разрабатывать параллельно. Сначала необходимо разработать сервис, затем сгенерировать контракт, и только после этого можно написать код потребителя, который будет придерживаться контракта. Без понимания контракта потребитель не может быть разработан.
2. Нет цели для команд. Поскольку договор не может быть известен до того, как сервис будет разработан, не существует цели для различных заинтересованных сторон в разработке. Следовательно, есть все шансы, что направления будут отклоняться, и будут внесены ненужные изменения, что приведет к напрасной трате усилий.
3. Нет кроссплатформенной совместимости.
На некоторых старых платформах не так просто сгенерировать контракт из кода. В результате этого для сгенерированных контрактов довольно часто возникает несовместимость между платформами.
Преимущества подхода Contract First
1. Команды могут разрабатывать параллельно. Поскольку кодирование происходит на основе контракта, поставщики услуг и группы потребителей услуг четко понимают подход и детали коммуникации. Следовательно, разработка может происходить одновременно.
2. Команды знают, что ожидать. Поскольку кодирование происходит на основе контракта, команды производителей и потребителей имеют представление об ожиданиях друг друга. В результате, если межгрупповое тестирование невозможно из-за разных темпов разработки, программное обеспечение-заглушка может использоваться для моделирования над поведения другой стороны на основе контракта.
3. Кроссплатформенная совместимость. Поскольку параметры сервиса зависят только от контракта, фактическая структура программного обеспечения, используемая для разработки сервиса, не имеет большого значения. Поставщик услуг и потребитель услуг могут использовать разные технологии.
Недостатки подхода Contract First
1. Требуется дополнительные начальные затраты. Большая часть этих затрат будет сосредоточена вокруг соглашения об обслуживании. Вы должны убедиться, что договор четко определен и не меняется очень часто.
2. Это может ограничить гибкость разработчиков, поскольку они вынуждены придерживаться условий контракта, а не экспериментировать с различными решениями.
Какой подход использовать в разработке – зависит от условий. Если критически важна скорость – лучше использовать Code First. Если есть время подумать о качестве – Contract First более эффективен.
📎 Статьи по теме
1. Contract first / Code first — в общих чертах про подходы
2. API-First и микросервисы — обзорная статья от ex-Accenture с практическими примерами
3. Design API First как паттерн проектирования контрактов межсервисного взаимодействия — цикл статей от SimbirSoft про опыт применения Code First
#проектирование #api
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше статей по этой теме в базе знаний по системному анализу
Существует два подхода к проектированию API.
🔹 Code first — сначала пишем код, потом по нему генерируем контракт
🔹 Contract first — сначала создаем контракт, потом по нему пишем или генерируем код
Контракт — это соглашение между поставщиком и потребителем об услуге. Чтобы правильно использовать услугу, потребитель сервиса должен полностью понимать договор.
Контракт включает в себя детали многих аспектов обслуживания, таких как:
1. Как вызвать сервис
2. Какой транспорт используется
3. Каковы структуры запроса и ответа
Преимущества Code First
1. Контракты с минимальными усилиями. Это всего лишь побочный продукт разработки сервиса, так как он может быть автоматически сгенерирован из кода.
2. Синхронизация кода и контракта: поскольку контракт генерируется из кода, они всегда синхронизируются друг с другом.
Недостатки Code First
1. Нет параллельной разработки. Производитель услуг и потребители услуг не могут разрабатывать параллельно. Сначала необходимо разработать сервис, затем сгенерировать контракт, и только после этого можно написать код потребителя, который будет придерживаться контракта. Без понимания контракта потребитель не может быть разработан.
2. Нет цели для команд. Поскольку договор не может быть известен до того, как сервис будет разработан, не существует цели для различных заинтересованных сторон в разработке. Следовательно, есть все шансы, что направления будут отклоняться, и будут внесены ненужные изменения, что приведет к напрасной трате усилий.
3. Нет кроссплатформенной совместимости.
На некоторых старых платформах не так просто сгенерировать контракт из кода. В результате этого для сгенерированных контрактов довольно часто возникает несовместимость между платформами.
Преимущества подхода Contract First
1. Команды могут разрабатывать параллельно. Поскольку кодирование происходит на основе контракта, поставщики услуг и группы потребителей услуг четко понимают подход и детали коммуникации. Следовательно, разработка может происходить одновременно.
2. Команды знают, что ожидать. Поскольку кодирование происходит на основе контракта, команды производителей и потребителей имеют представление об ожиданиях друг друга. В результате, если межгрупповое тестирование невозможно из-за разных темпов разработки, программное обеспечение-заглушка может использоваться для моделирования над поведения другой стороны на основе контракта.
3. Кроссплатформенная совместимость. Поскольку параметры сервиса зависят только от контракта, фактическая структура программного обеспечения, используемая для разработки сервиса, не имеет большого значения. Поставщик услуг и потребитель услуг могут использовать разные технологии.
Недостатки подхода Contract First
1. Требуется дополнительные начальные затраты. Большая часть этих затрат будет сосредоточена вокруг соглашения об обслуживании. Вы должны убедиться, что договор четко определен и не меняется очень часто.
2. Это может ограничить гибкость разработчиков, поскольку они вынуждены придерживаться условий контракта, а не экспериментировать с различными решениями.
Какой подход использовать в разработке – зависит от условий. Если критически важна скорость – лучше использовать Code First. Если есть время подумать о качестве – Contract First более эффективен.
📎 Статьи по теме
1. Contract first / Code first — в общих чертах про подходы
2. API-First и микросервисы — обзорная статья от ex-Accenture с практическими примерами
3. Design API First как паттерн проектирования контрактов межсервисного взаимодействия — цикл статей от SimbirSoft про опыт применения Code First
#проектирование #api
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16❤4
🔒 HTTPS и его отличие от HTTP
HTTPS – это защищённая версия протокола HTTP, которая шифрует передаваемые данные между клиентом и сервером. HTTPS не является отдельным протоколом. Это обычный HTTP, который работает через шифрованный протокол TLS. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.
Протокол TLS (Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. TLS расположен на уровень ниже протокола HTTP в модели OSI. Это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением. TLS пришёл на смену устаревшего протокола SSL.
Зачем нужно шифрование
В HTTP данные передаются в незашифрованном виде. Злоумышленник может просто перехватить пакет. HTTPS призван защитить соединение, чтобы данные никто не мог перехватить.
Принцип работы TLS
Чтобы защитить данные, TLS создаёт во время передачи специальный канал, где их нельзя прочитать или изменить без секретного ключа. Ключ — это подсказка, как именно читать сообщение.
В зависимости от количества ключей в TLS используется один из двух классов шифрования: симметричное и асимметричное.
Симметричное шифрование — это когда используется один и тот же ключ для шифрования и дешифрования данных. Оно работает эффективно и быстро, но требует предварительного обмена ключом между клиентом и сервером, в ходе которого ключ могут перехватить.
Асимметричное шифрование использует два ключа: публичный для шифрования и приватный для дешифровки. Публичный ключ можно свободно распространять, а приватный должен быть хорошо защищён. Асимметричное шифрование безопаснее, но требует больше вычислительных ресурсов и работает медленнее, чем симметричное.
В протоколе TLS симметричное шифрование используют для шифрования непосредственно сообщений, а асимметричное шифрование — во время рукопожатия, то есть в начале сессии для обмена ключами и аутентификации.
А ещё в TLS используется хеширование. В отличие от шифрования, хеширование предполагает одностороннее кодирование: данные пропускаются через хеш-функцию и получается код. Сам код обратно раскодировать уже нельзя, но зато другой участник может легко убедиться в целостности данных, в том, что их никто не подменил. Для этого нужно снова вызвать хеш-функцию и сравнить значение полученного хеша с переданным.
Таким образом, нужно использовать HTTPS, если нужно обеспечить безопасность данных, передаваемых между клиентом и сервером. Например, если вы обрабатываете личные данные, пароли, данные кредитных карт или другую чувствительную информацию.
В противном случае, если нет требований по защите данных и проверки их целостности, то лучше использовать обычный HTTP, так как он работает проще и быстрые.
📎 Материалы по теме
1. В чем разница протоколов HTTP и HTTPS — обзорная статья от Selectel
2. Как HTTPS обеспечивает безопасность соединения — статья на Хабре про принцип работы HTTPS
3. Протокол TLS: что это, зачем нужен и как работает — обзорная статья по TLS от Skillbox
4. Что такое TLS — подробнее о TLS | Хабр
5. Введение в протоколы HTTP и HTTPS — глава из руководства от Microsoft
6. Полное руководство по переходу с HTTP на HTTPS — про использование HTTPS на практике
7. Введение в криптографию и шифрование, часть первая — теория криптографии от Яндекса
#интеграции #безопасность
HTTPS – это защищённая версия протокола HTTP, которая шифрует передаваемые данные между клиентом и сервером. HTTPS не является отдельным протоколом. Это обычный HTTP, который работает через шифрованный протокол TLS. В отличие от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443.
Протокол TLS (Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. TLS расположен на уровень ниже протокола HTTP в модели OSI. Это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением. TLS пришёл на смену устаревшего протокола SSL.
Зачем нужно шифрование
В HTTP данные передаются в незашифрованном виде. Злоумышленник может просто перехватить пакет. HTTPS призван защитить соединение, чтобы данные никто не мог перехватить.
Принцип работы TLS
Чтобы защитить данные, TLS создаёт во время передачи специальный канал, где их нельзя прочитать или изменить без секретного ключа. Ключ — это подсказка, как именно читать сообщение.
В зависимости от количества ключей в TLS используется один из двух классов шифрования: симметричное и асимметричное.
Симметричное шифрование — это когда используется один и тот же ключ для шифрования и дешифрования данных. Оно работает эффективно и быстро, но требует предварительного обмена ключом между клиентом и сервером, в ходе которого ключ могут перехватить.
Асимметричное шифрование использует два ключа: публичный для шифрования и приватный для дешифровки. Публичный ключ можно свободно распространять, а приватный должен быть хорошо защищён. Асимметричное шифрование безопаснее, но требует больше вычислительных ресурсов и работает медленнее, чем симметричное.
В протоколе TLS симметричное шифрование используют для шифрования непосредственно сообщений, а асимметричное шифрование — во время рукопожатия, то есть в начале сессии для обмена ключами и аутентификации.
А ещё в TLS используется хеширование. В отличие от шифрования, хеширование предполагает одностороннее кодирование: данные пропускаются через хеш-функцию и получается код. Сам код обратно раскодировать уже нельзя, но зато другой участник может легко убедиться в целостности данных, в том, что их никто не подменил. Для этого нужно снова вызвать хеш-функцию и сравнить значение полученного хеша с переданным.
Таким образом, нужно использовать HTTPS, если нужно обеспечить безопасность данных, передаваемых между клиентом и сервером. Например, если вы обрабатываете личные данные, пароли, данные кредитных карт или другую чувствительную информацию.
В противном случае, если нет требований по защите данных и проверки их целостности, то лучше использовать обычный HTTP, так как он работает проще и быстрые.
📎 Материалы по теме
1. В чем разница протоколов HTTP и HTTPS — обзорная статья от Selectel
2. Как HTTPS обеспечивает безопасность соединения — статья на Хабре про принцип работы HTTPS
3. Протокол TLS: что это, зачем нужен и как работает — обзорная статья по TLS от Skillbox
4. Что такое TLS — подробнее о TLS | Хабр
5. Введение в протоколы HTTP и HTTPS — глава из руководства от Microsoft
6. Полное руководство по переходу с HTTP на HTTPS — про использование HTTPS на практике
7. Введение в криптографию и шифрование, часть первая — теория криптографии от Яндекса
#интеграции #безопасность
👍19❤3
🧼 SOAP. Краткий обзор
SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт. В отличие от REST, SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. А ещё SOAP не может использовать другой формат представления данных, кроме XML. Применяется в системах, где нужна жёсткая стандартизация, а также в legacy.
Протокол SOAP обычно использует HTTP в качестве транспорта (SOAP over HTTP). Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP. Сообщения передаются POST-запросами.
Структура XML-сообщения
>
>
>
>
Все данные в SOAP-сообщении размечаются <тегами>. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают <открывающие> (перед данными) и </закрывающие>.
Как понять, какие теги использовать? А это как раз описывается отдельно – в файле WSDL.
WSDL (Web Services Denoscription Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML. В SOAP для описания своего сервиса нужно использовать строгие правила в виде файла WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как составить запрос, на какой эндпоинт его отправлять, как прочитать ответ.
Для каждого веб-сервиса SOAP есть только одна конечная точка (endpoint). Эта конечная точка может иметь несколько функций. Какие у сервиса есть функции и по каким правилам их использовать также описывается в WSDL-файле.
✅ Преимущества SOAP
1. Наличие официального стандарта
2. Наличие встроенного механизма обработки ошибок
❌ Недостатки SOAP
1. Сложность использования ввиду необходимости придерживаться строгого стандарта и правил
2. Низкая скорость обработки из-за избыточного объёма передаваемых сообщений
Применение SOAP
В настоящее время SOAP применяется в системах, где требуется жёсткая стандартизация и соблюдение строгих правил безопасности. Например, госструктуры, банкинг, финансы, здравоохранение.
В остальном SOAP теряет популярность и применяется в legacy-системах.
📎Материалы по теме
1. Применение SOAP при интеграции систем: статья и вебинар
2. Официальный учебник по SOAP на русском от w3.org
3. Пример API: Взаимодействие с API Яндекс Директа по протоколу SOAP
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API
5. SOAP API — обзорная мини-статья
6. Вебинар: Что такое SOAP, WSDL, XSD / Урок 28 / Тестировщик с нуля
#интеграции #api
SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт. В отличие от REST, SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. А ещё SOAP не может использовать другой формат представления данных, кроме XML. Применяется в системах, где нужна жёсткая стандартизация, а также в legacy.
Протокол SOAP обычно использует HTTP в качестве транспорта (SOAP over HTTP). Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP. Сообщения передаются POST-запросами.
Структура XML-сообщения
>
Envelope — корневой элемент, который определяет сообщение и пространство имен, использованное в документе.>
Header — содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации.>
Body — содержит сообщение, которым обмениваются приложения.>
Fault — необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.Все данные в SOAP-сообщении размечаются <тегами>. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают <открывающие> (перед данными) и </закрывающие>.
Как понять, какие теги использовать? А это как раз описывается отдельно – в файле WSDL.
WSDL (Web Services Denoscription Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML. В SOAP для описания своего сервиса нужно использовать строгие правила в виде файла WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как составить запрос, на какой эндпоинт его отправлять, как прочитать ответ.
Для каждого веб-сервиса SOAP есть только одна конечная точка (endpoint). Эта конечная точка может иметь несколько функций. Какие у сервиса есть функции и по каким правилам их использовать также описывается в WSDL-файле.
✅ Преимущества SOAP
1. Наличие официального стандарта
2. Наличие встроенного механизма обработки ошибок
❌ Недостатки SOAP
1. Сложность использования ввиду необходимости придерживаться строгого стандарта и правил
2. Низкая скорость обработки из-за избыточного объёма передаваемых сообщений
Применение SOAP
В настоящее время SOAP применяется в системах, где требуется жёсткая стандартизация и соблюдение строгих правил безопасности. Например, госструктуры, банкинг, финансы, здравоохранение.
В остальном SOAP теряет популярность и применяется в legacy-системах.
📎Материалы по теме
1. Применение SOAP при интеграции систем: статья и вебинар
2. Официальный учебник по SOAP на русском от w3.org
3. Пример API: Взаимодействие с API Яндекс Директа по протоколу SOAP
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API
5. SOAP API — обзорная мини-статья
6. Вебинар: Что такое SOAP, WSDL, XSD / Урок 28 / Тестировщик с нуля
#интеграции #api
❤11👍4🔥4
🆚 REST vs SOAP. Главное
Определение
🔹 SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт.
🔸 REST – это архитектурный стиль, а не протокол. REST лишь определяет набор принципов и ограничений.
Протокол
🔹 SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. Но в большинстве случаев SOAP использует HTTP в качестве транспорта (SOAP over HTTP).
🔸 REST, как правило, хотя и не обязательно, использует HTTP. С одной стороны, REST не говорит, что нужно обязательно использовать HTTP. С другой стороны, HTTP специально спроектирован под REST. Более того, создатель REST Рэй Филдинг также является соавтором HTTP.
Формат сообщений
🔹 SOAP работает только с XML
🔸 В REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, RSS, CSV, HTML и другие
Подход к API
🔹 SOAP основан на подходе удалённого вызова процедур (RPC). Это вызов функции в коде, только по сети. Например, чтобы получить информацию о заказе, нужно вызвать SOAP-метод
🔸 REST фокусируется на ресурсах, доступ к которым осуществляется через URL. Это значит, например, что наш интернет-заказ имеет URI —
Производительность
🔹 SOAP работает медленнее из-за избыточного объёма передаваемых сообщений
🔸 REST быстрее благодаря кэшированию (принцип №3) и меньшему размеру сообщений
Гибкость
🔹 SOAP сложнее масштабировать и вносить изменения. Сервер приложений также должен сохранять состояние каждого клиента. Это означает, что при обработке нового запроса он должен помнить все предыдущие, что усложняет масштабирование
🔸 REST проще масштабировать, так как сервер не сохраняет состояние клиента, поэтому REST API обрабатывает каждый новый запрос независимо от предыдущих.
Простота
🔹 SOAP сложнее, требует глубокого понимания всех задействованных протоколов и их строгих правил. Реализация SOAP API требует описания WSDL для каждого сервиса, обрабатывать и анализировать XML сложнее.
🔸 REST проще в реализации и более “человекопонятен”. Он не привязан к XML и чаще всего использует JSON.
Обработка ошибок
🔹 В протокол SOAP встроена логика обработки ошибок. SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
🔸 REST использует протокол HTTP, который может возвращать коды состояний
Раскрытие API
🔹 SOAP-сервис всегда должен иметь WSDL. Плюс этого в том, что WSDL даёт чёткие правила, как отправлять и по какой структуре отправлять запросы и принимать ответы
🔸 REST не имеет языка описания веб-сервисов. Однако на помощь приходит Swagger (OpenAPI)
Безопасность
🔹 SOAP имеет встроенное расширение безопасности – WS Security, которое регулирует процедуры конфиденциальности и аутентификации для обмена сообщениями
🔸 REST не предусматривает никаких специальных мер безопасности. Безопасность REST может быть обеспечена только за счет HTTPS
Использование
🔹 SOAP применяется в системах, где нужна жёсткая стандартизация, а также в legacy
🔸 REST используется повсеместно
📌 Выводы
SOAP и REST – не конкуренты. Они представляют разные весовые категории и вряд ли найдется задача, для которой будет сложно сказать, какой подход рациональнее использовать – SOAP или REST. Каждая задача сама диктует наиболее разумный подход к интеграции.
📎 Полезные материалы
1. О REST на нашем канале
2. Про SOAP
3. Статья про разницу SOAP и REST от Amazon (на русском)
4. SOAP и REST API: Ключевые различия, объясненные для новичков
5. REST vs SOAP на Medium (через VPN)
6. Что происходит, когда мы отправляем SOAP или REST запрос — 3,5 минуты видео
#api #интеграции #сравнение
Определение
🔹 SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт.
🔸 REST – это архитектурный стиль, а не протокол. REST лишь определяет набор принципов и ограничений.
Протокол
🔹 SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. Но в большинстве случаев SOAP использует HTTP в качестве транспорта (SOAP over HTTP).
🔸 REST, как правило, хотя и не обязательно, использует HTTP. С одной стороны, REST не говорит, что нужно обязательно использовать HTTP. С другой стороны, HTTP специально спроектирован под REST. Более того, создатель REST Рэй Филдинг также является соавтором HTTP.
Формат сообщений
🔹 SOAP работает только с XML
🔸 В REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, RSS, CSV, HTML и другие
Подход к API
🔹 SOAP основан на подходе удалённого вызова процедур (RPC). Это вызов функции в коде, только по сети. Например, чтобы получить информацию о заказе, нужно вызвать SOAP-метод
getOrder, чтобы оформить заказ – makeOrder и т.д.🔸 REST фокусируется на ресурсах, доступ к которым осуществляется через URL. Это значит, например, что наш интернет-заказ имеет URI —
/api/v1/order. Если мы хотим получить информацию о заказе, нужно вызвать HTTP метод GET /api/v1/order, чтобы оформить заказ, вызовем POST /api/v1/order. В обоих случаях ресурс один и тот же, а методы работы с ним разные.Производительность
🔹 SOAP работает медленнее из-за избыточного объёма передаваемых сообщений
🔸 REST быстрее благодаря кэшированию (принцип №3) и меньшему размеру сообщений
Гибкость
🔹 SOAP сложнее масштабировать и вносить изменения. Сервер приложений также должен сохранять состояние каждого клиента. Это означает, что при обработке нового запроса он должен помнить все предыдущие, что усложняет масштабирование
🔸 REST проще масштабировать, так как сервер не сохраняет состояние клиента, поэтому REST API обрабатывает каждый новый запрос независимо от предыдущих.
Простота
🔹 SOAP сложнее, требует глубокого понимания всех задействованных протоколов и их строгих правил. Реализация SOAP API требует описания WSDL для каждого сервиса, обрабатывать и анализировать XML сложнее.
🔸 REST проще в реализации и более “человекопонятен”. Он не привязан к XML и чаще всего использует JSON.
Обработка ошибок
🔹 В протокол SOAP встроена логика обработки ошибок. SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и ее объяснением.
🔸 REST использует протокол HTTP, который может возвращать коды состояний
Раскрытие API
🔹 SOAP-сервис всегда должен иметь WSDL. Плюс этого в том, что WSDL даёт чёткие правила, как отправлять и по какой структуре отправлять запросы и принимать ответы
🔸 REST не имеет языка описания веб-сервисов. Однако на помощь приходит Swagger (OpenAPI)
Безопасность
🔹 SOAP имеет встроенное расширение безопасности – WS Security, которое регулирует процедуры конфиденциальности и аутентификации для обмена сообщениями
🔸 REST не предусматривает никаких специальных мер безопасности. Безопасность REST может быть обеспечена только за счет HTTPS
Использование
🔹 SOAP применяется в системах, где нужна жёсткая стандартизация, а также в legacy
🔸 REST используется повсеместно
📌 Выводы
SOAP и REST – не конкуренты. Они представляют разные весовые категории и вряд ли найдется задача, для которой будет сложно сказать, какой подход рациональнее использовать – SOAP или REST. Каждая задача сама диктует наиболее разумный подход к интеграции.
📎 Полезные материалы
1. О REST на нашем канале
2. Про SOAP
3. Статья про разницу SOAP и REST от Amazon (на русском)
4. SOAP и REST API: Ключевые различия, объясненные для новичков
5. REST vs SOAP на Medium (через VPN)
6. Что происходит, когда мы отправляем SOAP или REST запрос — 3,5 минуты видео
#api #интеграции #сравнение
🔥15❤4👍4
🏭 PlantUML: полезные материалы
Небольшая подборка для тех, кто давно хотел начать применять PlantUML, но никак не доходили руки. К счастью, это не займёт много времени.
PlantUML — это крайне полезный инструмент для аналитика, который превращает псевдокод в UML-диаграммы. Это значительно быстрее и удобнее, чем вечно тыкаться со стрелочками и ручным выравниванием в draw.io или в Visio. Жирный плюс — есть плагин для Confluence.
Синтаксис очень простой, пугаться кода не нужно. По примерам становится всё понятно.
Для начала выберете место, где вам будет удобнее писать диаграмму: это может быть:
1. planttext.com — онлайн редактор
2. расширение для Notepad++
3. расширение для IDE (лучший вариант, ссылки кликабельны): IDEA, PyCharm, Visual Studio
После того как определитесь, где будете работать, можете начать изучение по статьям или видео.
Документация
1. Официальная документация (почти всё на русском)
2. Гайд на русском в pdf
Статьи
1. Диаграммы без боли и страданий: PlantUML — хороший гайд с примерами
2. Пишу диаграммы последовательностей текстом (кодом). Вы тоже можете — тут только про sequence
Видео
1. PlantUML с нуля до гуру: учимся «кодить» sequence-диаграммы — доклад Никиты Харичкина с Flow 2022 (скачать презентацию)
2. PlantUML на всю катушку: Автоматизация и лайфхаки для диаграмм последовательности — доклад всё того же Никиты, но с Analyst Days #14 (скачать презентацию)
#инструменты #подборка
Небольшая подборка для тех, кто давно хотел начать применять PlantUML, но никак не доходили руки. К счастью, это не займёт много времени.
PlantUML — это крайне полезный инструмент для аналитика, который превращает псевдокод в UML-диаграммы. Это значительно быстрее и удобнее, чем вечно тыкаться со стрелочками и ручным выравниванием в draw.io или в Visio. Жирный плюс — есть плагин для Confluence.
Синтаксис очень простой, пугаться кода не нужно. По примерам становится всё понятно.
Для начала выберете место, где вам будет удобнее писать диаграмму: это может быть:
1. planttext.com — онлайн редактор
2. расширение для Notepad++
3. расширение для IDE (лучший вариант, ссылки кликабельны): IDEA, PyCharm, Visual Studio
После того как определитесь, где будете работать, можете начать изучение по статьям или видео.
Документация
1. Официальная документация (почти всё на русском)
2. Гайд на русском в pdf
Статьи
1. Диаграммы без боли и страданий: PlantUML — хороший гайд с примерами
2. Пишу диаграммы последовательностей текстом (кодом). Вы тоже можете — тут только про sequence
Видео
1. PlantUML с нуля до гуру: учимся «кодить» sequence-диаграммы — доклад Никиты Харичкина с Flow 2022 (скачать презентацию)
2. PlantUML на всю катушку: Автоматизация и лайфхаки для диаграмм последовательности — доклад всё того же Никиты, но с Analyst Days #14 (скачать презентацию)
#инструменты #подборка
🔥34👍9❤3👏1
Основы Kafka – что нужно знать аналитику
Неделей ранее мы рассматривали основные понятия очередей сообщений. Пришло время копнуть чуть глубже и познакомиться с Кафкой.
Apache Kafka – популярный брокер сообщений с открытым исходным кодом. Применяется в высоконагруженных системах для асинхронной интеграции, где требуется гарантированная доставка сообщений.
Подход к обмену сообщениями
Те, кто отправляют сообщения в Kafka, называются продюсерами, а те, кто читает, косьюмерами. В Kafka используется подход pull, когда консьюмеры сами отправляют запросы в брокер раз в n миллисекунд для получения новой порции сообщений. Такой подход позволяет группировать сообщения в пакеты, достигая лучшей пропускной способности. К минусам модели можно отнести потенциальную разбалансированность нагрузки между разными консьюмерами и более высокую задержку обработки данных.
После прочтения косньюмерами сообщения в Kafka не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.
Архитектура Kafka
Kafka является распределенной системой. Все серверы объединяются в кластеры. Хранение и пересылка сообщений идёт параллельно на разных серверах, это даёт большую надежность и отказоустойчивость. Такая архитектура упрощает горизонтальное масштабирование: достаточно добавить дополнительные серверы.
Хранение сообщений в Kafka
Каждое сообщение (event или message) в Kafka состоит из ключа, значения, таймстампа и опционального набора метаданных (headers). Сообщения хранятся в топиках, которые делятся на партиции (partitions). Партиции распределены между брокерами в кластере и могут быть реплицированы для надёжности. Сообщения с одинаковыми ключами попадают в одну партицию, что обеспечивает порядок записи и чтения.
Чтение сообщений в Kafka
Как не читать одно сообщение дважды? Консьюмеры в Kafka отмечают обработанные сообщения с помощью оффсетов. Оффсет – это номер сообщения в партиции. Консьюмер отправляет брокеру запрос offset-commit с офсетом, который нужно сохранить. Брокер хранит эти офсеты в специальном топике. Консьюмеры могут получить последний закоммиченный оффсет у брокера и продолжить чтение сообщений с него.
Процесс обмена сообщениями в Kafka
0️⃣ Создается именованный топик, который является точкой интеграции между продюсером и консьюмером. Топик делится на несколько партиций, которые распределяются между брокерами в кластере
1️⃣ Продюсер отправляет сообщение в топик брокера. Сообщение содержит ключ, значение, таймстамп и опциональные хедеры. Ключ определяет, в какую партицию попадет сообщение.
2️⃣ Консьюмер пытается забрать сообщение и его уникальный идентификатор (оффсет), присвоенный брокером (как правило, порядковый номер).
3️⃣ Брокер хранит сообщение до запланированной очистки журнала. Kafka не отслеживает, какие сообщения были обработаны консьюмерами.
4️⃣ Консьюмер обрабатывает сообщение, исходя из своей бизнес-логики и отправляет запрос обратно на сервер, используя его уникальный офсет и сообщает брокеру либо об успешной обработке (offset-commit), либо об ошибке (offset-reset).
5️⃣ В случае успеха офсет помечается как закоммиченный и сохраняется в специальном топике. В случае ошибки оффсет сбрасывается на предыдущее значение или на дефолтное. Сообщение не удаляется из партиции и доступно для повторного чтения консьюмерами.
Где используется Kafka
Kafka используется для обработки больших объёмов данных, сотен тысяч сообщений в секунду, которые читаются тысячами подписчиков. Kafka — это легко масштабируемая система, обладающая повышенной отказоустойчивостью, что очень важно в крупных проектах, например, банкинг, телеком социальные сети, IoT.
Материалы по Kafka выйдут в следующем посте завтра, а на следующей неделе рассмотрим RabbitMQ и сравним его с Kafka.
#интеграции #очереди #async
Неделей ранее мы рассматривали основные понятия очередей сообщений. Пришло время копнуть чуть глубже и познакомиться с Кафкой.
Apache Kafka – популярный брокер сообщений с открытым исходным кодом. Применяется в высоконагруженных системах для асинхронной интеграции, где требуется гарантированная доставка сообщений.
Подход к обмену сообщениями
Те, кто отправляют сообщения в Kafka, называются продюсерами, а те, кто читает, косьюмерами. В Kafka используется подход pull, когда консьюмеры сами отправляют запросы в брокер раз в n миллисекунд для получения новой порции сообщений. Такой подход позволяет группировать сообщения в пакеты, достигая лучшей пропускной способности. К минусам модели можно отнести потенциальную разбалансированность нагрузки между разными консьюмерами и более высокую задержку обработки данных.
После прочтения косньюмерами сообщения в Kafka не удаляются и могут храниться неограниченное время. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах.
Архитектура Kafka
Kafka является распределенной системой. Все серверы объединяются в кластеры. Хранение и пересылка сообщений идёт параллельно на разных серверах, это даёт большую надежность и отказоустойчивость. Такая архитектура упрощает горизонтальное масштабирование: достаточно добавить дополнительные серверы.
Хранение сообщений в Kafka
Каждое сообщение (event или message) в Kafka состоит из ключа, значения, таймстампа и опционального набора метаданных (headers). Сообщения хранятся в топиках, которые делятся на партиции (partitions). Партиции распределены между брокерами в кластере и могут быть реплицированы для надёжности. Сообщения с одинаковыми ключами попадают в одну партицию, что обеспечивает порядок записи и чтения.
Чтение сообщений в Kafka
Как не читать одно сообщение дважды? Консьюмеры в Kafka отмечают обработанные сообщения с помощью оффсетов. Оффсет – это номер сообщения в партиции. Консьюмер отправляет брокеру запрос offset-commit с офсетом, который нужно сохранить. Брокер хранит эти офсеты в специальном топике. Консьюмеры могут получить последний закоммиченный оффсет у брокера и продолжить чтение сообщений с него.
Процесс обмена сообщениями в Kafka
0️⃣ Создается именованный топик, который является точкой интеграции между продюсером и консьюмером. Топик делится на несколько партиций, которые распределяются между брокерами в кластере
1️⃣ Продюсер отправляет сообщение в топик брокера. Сообщение содержит ключ, значение, таймстамп и опциональные хедеры. Ключ определяет, в какую партицию попадет сообщение.
2️⃣ Консьюмер пытается забрать сообщение и его уникальный идентификатор (оффсет), присвоенный брокером (как правило, порядковый номер).
3️⃣ Брокер хранит сообщение до запланированной очистки журнала. Kafka не отслеживает, какие сообщения были обработаны консьюмерами.
4️⃣ Консьюмер обрабатывает сообщение, исходя из своей бизнес-логики и отправляет запрос обратно на сервер, используя его уникальный офсет и сообщает брокеру либо об успешной обработке (offset-commit), либо об ошибке (offset-reset).
5️⃣ В случае успеха офсет помечается как закоммиченный и сохраняется в специальном топике. В случае ошибки оффсет сбрасывается на предыдущее значение или на дефолтное. Сообщение не удаляется из партиции и доступно для повторного чтения консьюмерами.
Где используется Kafka
Kafka используется для обработки больших объёмов данных, сотен тысяч сообщений в секунду, которые читаются тысячами подписчиков. Kafka — это легко масштабируемая система, обладающая повышенной отказоустойчивостью, что очень важно в крупных проектах, например, банкинг, телеком социальные сети, IoT.
Материалы по Kafka выйдут в следующем посте завтра, а на следующей неделе рассмотрим RabbitMQ и сравним его с Kafka.
#интеграции #очереди #async
🔥22👍8❤6
Подборка бесплатных материалов по Kafka
Делитесь с коллегами 📢
📑 Статьи (теория)
1. Apache Kafka: основы технологии от Слёрм
2. Короткая статья на Яндекс.Практикум
3. Apache Kafka для аналитика: ТОП-7 требований к интеграционной шине
4. Kafka за 20 минут от СберМаркета
5. Перевод на русский главы "Kafka" из книги «Understanding Message Brokers»
6. Микросервисы, Apache Kafka и Domain-Driven Design
📝 Статьи (практика)
1. Как построить систему, способную выдерживать нагрузку в 5 млн rps
2. Разбираемся в технологии и собираем простое приложение на базе managed-решения
3. Как мы автоматизировали работу с Kafka
⏯ Вебинары
1. Apache Kafka, открытый базовый курс — 3 видеоурока от Слёрм
2. Про Kafka (основы) — Владимир Богдановский
3. Основы работы с Kafka с Павлом Вейником — видеолекция с примерами от разработчика
📚 Книги
1. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
2. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — книга про Kafka на русском
3. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka
Если у кого есть ещё чем поделиться, пишите в комментариях 👇
#подборка #интеграции #очереди #async
Делитесь с коллегами 📢
📑 Статьи (теория)
1. Apache Kafka: основы технологии от Слёрм
2. Короткая статья на Яндекс.Практикум
3. Apache Kafka для аналитика: ТОП-7 требований к интеграционной шине
4. Kafka за 20 минут от СберМаркета
5. Перевод на русский главы "Kafka" из книги «Understanding Message Brokers»
6. Микросервисы, Apache Kafka и Domain-Driven Design
📝 Статьи (практика)
1. Как построить систему, способную выдерживать нагрузку в 5 млн rps
2. Разбираемся в технологии и собираем простое приложение на базе managed-решения
3. Как мы автоматизировали работу с Kafka
⏯ Вебинары
1. Apache Kafka, открытый базовый курс — 3 видеоурока от Слёрм
2. Про Kafka (основы) — Владимир Богдановский
3. Основы работы с Kafka с Павлом Вейником — видеолекция с примерами от разработчика
📚 Книги
1. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке
2. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — книга про Kafka на русском
3. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka
Если у кого есть ещё чем поделиться, пишите в комментариях 👇
#подборка #интеграции #очереди #async
🔥20❤8👍5