Какова реальная разница между API и в микрослужб?

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

7
api microservices

5 ответов

подход к микросервисам заключается в том, чтобы разбить вашу систему ("кучу кода") на множество небольших сервисов, каждый из которых обычно имеет свой собственный:

  • понятное дело-ответственность
  • запуск процесса
  • база данных
  • управление версиями кода (например, Git) репозиторий
  • API
  • UI

сами услуги сохраняются маленький так как ваша система растет, есть больше услуг-скорее чем больше услуг.

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

6

API-интерфейс = Интерфейс Прикладного Программирования

микрослужб = архитектура

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

вы можете прочитать http://samnewman.io/books/building_microservices/ прежде чем вы решите использовать микросервисы (если это не для учебных целей).

5

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

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

микросервисный сервер и интерфейс микросервис может быть разделен на 2 части

  1. frontend microservice, который предоставляет конечную точку rest так же, как Web API
  2. backend microservice, который фактически выполняет все операции.

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

1

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

1

микрослужб

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

API

a (web) приложение должно разработать бизнес-логику со всем набором объектов (моделей) и возможных операций над ними. Ан (Прикладное Программирование Интерфейс] [https://en.wikipedia.org/wiki/Application_programming_interface)-это способ выполнения запросов к приложению, предоставляя определенные точки входа, которые отвечают за вызов соответствующих операций приложения.

REST(ful) APIs ("REST", как в передаче репрезентативного состояния) являются API, соответствующие, по крайней мере, этим 5 ограничения:

  • пользовательский интерфейс отличается от хранения данных и манипуляция (архитектура клиент-сервер)
  • на сервере не хранится контекст клиента ("без состояния")
  • ответы сервера должны, неявно или явно, определять себя как кэшируемые или нет
  • клиент не должен знать о слоях между ним и сервером
  • сообщения ответа / запроса должны быть: быть самоописательными; позволять идентифицировать ресурс; использовать представления, позволяющие манипулировать ресурсами; объявлять доступные действия и ресурсы ("единый интерфейс").

"реальное различие"

Итак, хотя эти понятия, очевидно, связаны, они являются четко определенными понятиями:

  • быть спокойным или нет, an API предоставляет операции, предоставляемые сервером, которые могут (но не обязательно) быть обстреляны меньшими компонентами (микрослужб).

  • кроме того, в то время как типичный web (REST)API использует протокол HTTP между клиентом и сервером, компоненты архитектура конструирование может общаться, используя другой протокол(ы) (например,ПУВР, протокол AMQP, JSON-RPC, XML-RPC, мыло, ...)

0