Статьи

Анатомия микросервиса, один сервис, несколько серверов

Первая статья этой серии, « Определение и архитектура микросервисов », включает диаграмму архитектуры высокого уровня. Последующие статьи охватили первые два уровня архитектуры. Настало (наконец) время взглянуть на уровень API-сервера и представить бизнес-сервис для внешнего мира. Как и в случае с этой серией, я продолжу демонстрировать решение с помощью примера проекта, который можно найти на GitHub по адресу https://github.com/relenteny/microservice .

Есть два API-сервера ; RESTful и gRPC. Источник находится в модуле медиа-сервера . Почему две реализации? Транспортный механизм имеет значение. Безусловно, наиболее распространенным протоколом является REST. Протокол легко производить и потреблять. Это использует очень зрелый транспортный механизм; HTTP 1.x. Его повсеместная поддержка в технических стеках действительно делает его стандартным протоколом API Server.

Вам также может понравиться: Настроить конечную точку API, распределенную по нескольким серверам, с использованием NGINX Upstreams

С другой стороны, gRPC требует более преднамеренного проектирования, предоставляя спецификацию интерфейса (protobuf) и требует HTTP / 2 в качестве протокола, который в настоящее время не имеет широкой поддержки браузера. Однако gRPC предлагает значительные преимущества, включая компактный двоичный формат сообщений, двунаправленную потоковую передачу и улучшенную производительность в масштабе. Возникает вопрос: если gRPC не имеет широкой поддержки браузеров, какова его ценность? Для меня это становится основным определением микросервиса.

Хотя основанные на HTTP технологии являются ключом к микросервисной архитектуре, они не являются определяющим компонентом микросервисной архитектуры.

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

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

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

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

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

Поэтому развертывание эффективных микросервисов влияет на масштабирование, что влияет на стоимость. Есть много статей и блогов о производительности и эффективности gRPC по сравнению с REST. Хотя в настоящее время он не может быть легко использован в типичном случае использования внешнего API-сервера; браузер, потратив время на добавление микросервиса к реализации API сервера gRPC, может сыграть роль в развертывании эффективных микросервисов. Помните, что возможности и эффективность развертывания играют важную роль в конкурентоспособности бизнеса. Использование инфраструктуры как конкурентного преимущества — это реальная вещь.

Использование инфраструктуры как конкурентного преимущества — это реальная вещь.

Есть много ресурсов gRPC. У Microsoft хорошая, лаконичная страница с очень хорошим обзором. Вы можете найти его в разделе Сравнение сервисов gRPC с HTTP API , и да, парень из Linux / Java только что ссылался на веб-сайт Microsoft.

На странице Microsoft кратко представлены API-интерфейсы gRPC и HTTP:

Характерная черта КПГР HTTP API с JSON

контракт

Обязательно (.proto)

Необязательно (OpenAPI)

протокол

HTTP / 2

HTTP

полезная нагрузка

Протобуф (маленький, бинарный)

JSON (большой, читаемый человеком)

Prescriptiveness

Строгая спецификация

Сними. Любой HTTP действителен

Потоковый

Клиент, сервер, двунаправленный

Клиент, сервер

Поддержка браузера

Нет (требуется grpc-web)

да

Безопасность

Транспорт (TLS)

Транспорт (TLS)

Генерация клиентского кода

да

OpenAPI + сторонние инструменты

Несколько API-серверов и общая микросервисная архитектура

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

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

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

Кроме того, если вы копируете и вставляете, почему бы просто не вырезать из одного API-сервера и вставить в бизнес-сервис?

Пересмотр внедрений бизнес-услуг

В моей предыдущей статье из этой серии «Анатомия микросервиса», «Удовлетворение интерфейса» , я продемонстрировал несколько реализаций бизнес-службы. Две из этих реализаций предназначены для использования в серверных приложениях. Если вы следили за этой серией, надеюсь, неудивительно, что существуют клиентские реализации как для вызова RESTful, так и для вызова бизнес-сервисов gRPC.

Это контрактный дизайн, использующий внедрение зависимостей в лучшем виде. Здесь нет ничего нового, но, как ни странно (по крайней мере, мне), этот паттерн встречается редко.

Для меня это — то, где дизайн интерфейса / контракта и инверсия управления / внедрения зависимости — оба основных арендатора SOLID — действительно сияют.

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

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


Простой текст