Первая статья этой серии, « Определение и архитектура микросервисов », включает диаграмму архитектуры высокого уровня. Последующие статьи охватили первые два уровня архитектуры. Настало (наконец) время взглянуть на уровень 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, но справа от диаграммы есть система, взаимодействующая напрямую с бизнес-службой.
Может случиться так, что по соображениям безопасности или производительности ничто не может пройти по проводам, и приложение должно встраивать сервис напрямую. Наряду с фактической реализацией бизнес-сервиса, предоставление клиентских реализаций предоставляет потребителю выбор интеграции бизнес-сервиса. Это контрактный дизайн, использующий внедрение зависимостей в лучшем виде. Здесь нет ничего нового, но, как ни странно (по крайней мере, мне), этот паттерн встречается редко.
Простой текст
1
public class SampleClient {
2
4
MediaService mediaService;
5
public static void main(String[] args) {
7
SampleClient sampleClient = new SampleClient();
8
sampleClient.getMovies();
10
}
11
public void getMovies() {
13
mediaService.getMovies().doOnNext(movie -> {
14
System.out.println(movie.getTitle());
15
}).blockingSubscribe();
16
}
17
}
Какая разница в приведенном выше коде, является ли реализация бизнес-службы нативной, REST или gGRPC, или имитацией по сравнению с реальной реализацией? Я бы сказал, что это вопрос с подвохом, но поскольку вы продвинулись так далеко в этой статье, вы уже знаете, что нет никакой разницы. Разница заключается в упаковке развертывания; не в скомпилированном коде.
Следующий
Когда я начал эту статью, я намеревался начать обсуждение по созданию микросервисов и взглянуть на функцию Quarkus при использовании GraalVM для создания собственного исполняемого файла. Как оказалось, я потратил немного времени на разработку некоторых принципов архитектуры, связанных с разработкой реализаций API-сервера. Надеюсь, вы нашли это полезным.
В моей следующей статье мы рассмотрим создание приложения и рассмотрим, как Quarkus поддерживает создание как Uber JAR, так и собственного исполняемого файла с использованием GraalVM. Следите за анатомией микросервиса, Java на Warp Speed.
Дальнейшее чтение
Многосерверный чат в узле без базы данных
Запуск и настройка нескольких экземпляров на одном сервере Tomcat
Как подготовить набор баз данных для нескольких серверов на основе Azure