Микросервисы и API: в чем разница?

Обсуждая архитектуру программного обеспечения и интеграцию, вы, вероятно, слышали два причудливых термина: API и микросервисы.

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

В этом руководстве мы начнем с определения API и микросервисов по отдельности – что они делают, как работают и почему они важны. Далее мы увидим, как API и микросервисы сочетаются друг с другом в современной программной экосистеме.

Что такое API?

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

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

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

Для чего используются API?

Если вы используете программное обеспечение, вы используете API. Это потому, что API-интерфейсы обеспечивают интеграцию программного обеспечения – они позволяют отдельным программным объектам обмениваться информацией и работать вместе.

Представьте, что вы делаете покупки в Интернете и готовы оформить заказ. Вы видите, что в магазине, в котором вы находитесь, есть возможность платить через PayNow, платежную систему, и у вас уже есть учетная запись на PayNow.com с настроенными платежными данными. Как удобно!

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

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

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

REST API

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

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

Вы можете прочитать наше полное руководство по REST API для подробного объяснения этой структуры. Но, чтобы дать краткий обзор: REST описывает набор ограничений для создания API-интерфейсов, которые делают их эффективными и безопасными. REST API работают, отправляя HTTP-запросы и возвращая ответы в формате JSON (JavaScript Object Notation). HTTP (протокол передачи гипертекста) уже является стандартным протоколом для передачи данных через Интернет. Итак, с некоторыми знаниями HTTP разработчики могут легко узнать, как создавать REST API или взаимодействовать с ними.

Внешние и внутренние API

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

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

Что такое микросервис?

Микросервис – это стиль архитектуры программного обеспечения, который разделяет различные функции приложения на более мелкие компоненты, называемые «службами». Когда приложение построено таким образом, считается, что оно следует микросервисной архитектуре .

(Краткое примечание: разработчики часто сами называют эти более мелкие компоненты «микросервисами». Чтобы избежать путаницы, я буду придерживаться термина «службы» при описании этих компонентов и «микросервис» при ссылке на всю архитектуру системы.)

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

Каждая служба в более крупных микросервисах имеет только одну задачу, но объем этих задач зависит от разработчиков приложения. Базовое программное приложение может полагаться на несколько служб, как и PayNow. Или, в случае крупных компаний-разработчиков программного обеспечения, приложение может включать сотни детализированных сервисов с очень специфическими функциями.

Зачем использовать микросервисную архитектуру?

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

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

Хотя может иметь смысл начать разработку приложения таким образом, зачем создавать несколько программ, о которых нужно беспокоиться? – приверженцы монолита будут сталкиваться с проблемами по мере роста возможностей и сложности их приложения. Объединение всех аспектов приложения в одну программу затрудняет программирование и выпуск обновлений, отслеживание изменений, выявление проблем, делегирование задач разработчикам и общее понимание кода.

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

• Обновления: в приложении микросервиса обновление отдельных сервисов не требует модификации всей системы. Это экономит время, деньги и усилия по отладке. Это также позволяет обновлять непрерывно, в отличие от нечастых крупных обновлений.
• Простота: разработчику не нужно понимать всю архитектуру системы, чтобы понять один аспект программного обеспечения.
• Организация команды: микросервисы определяют границы между обязанностями разработчиков. Команды DevOps могут быть назначены на один или несколько микросервисов, а не на некую часть туманного монолита.
• Безопасность: если одна служба скомпрометирована, это (в идеале) не повлияет существенно на другие службы.
• Надежность: аналогично, если одна служба выходит из строя, другие службы не пострадают.
• Гибкость: если команда желает создать службу определенным образом (например, с другим языком или фреймворком), ей не нужно беспокоиться о том, как это может повлиять на другие компоненты.

Подводя итог: разделив обязанности, микросервисы ускоряют и упрощают процесс разработки программного обеспечения.

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

Микросервисы против API

Прежде чем сравнивать эти концепции, давайте быстро рассмотрим:

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

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

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

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

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

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

Будущее (и настоящее) архитектуры программного обеспечения

За последнее десятилетие ведущие софтверные компании – ваши Amazons, Netflixes и Spotifys – взяли на вооружение подход микросервисов. Конечно, их реализации немного сложнее, но основной принцип тот же: разделение задач приложения на программные подкомпоненты делает все проще и эффективнее, а API связывают все это вместе.

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

Источник записи: https://blog.hubspot.com