Синхронная связь предполагает взаимодействие в реальном времени, при котором одна служба отправляет запрос другой и приостанавливает свою работу до тех пор, пока не будет получен ответ. REST API и gRPC — это распространенные протоколы, используемые для облегчения такого типа связи.
RESTful API (передача репрезентативного состояния) — это один из наиболее распространенных методов взаимодействия сервисов друг с другом в системе микросервисов. REST использует форматы HTTP/HTTPS и JSON или XML для обмена данными.
Обычно сервисы взаимодействуют друг с другом путем прямого вызова API другого сервиса.
Пример запроса и ответа:
GET /users/12345 HTTP/1.1 Host: api.userservice.com Accept: application/json Authorization: Bearer your-access-token { "userId": "12345", "name": "Michel J", "email": "[email protected]", "address": "Mountain View, Santa Clara, California" }
Пример исходного кода
import org.springframework.web.client.RestTemplate; import org.springframework.http.ResponseEntity; public class OrderService { private final RestTemplate restTemplate = new RestTemplate(); private final String userServiceUrl = "https://api.userservice.com/users/"; public User getUserById(String userId) { String url = userServiceUrl userId; ResponseEntityresponse = restTemplate.getForEntity(url, User.class); return response.getBody(); } }
Преимущества:
Легко развернуть и интегрировать с различными языками и инструментами.
Может легко использовать инструменты тестирования и мониторинга.
Недостатки:
Может оказаться неэффективным для высокоскоростных требований из-за своей синхронной природы.
Могут возникнуть трудности при обработке сетевых ошибок или отключений.
gRPC, что означает удаленный вызов процедур Google, представляет собой высокопроизводительную универсальную платформу RPC с открытым исходным кодом. Он использует HTTP/2 для эффективной передачи данных и обычно полагается на буферы протокола, независимый от языка и платформы, расширяемый механизм для сериализации структурированных данных, чтобы определить структуру отправляемых и получаемых данных.
Пример: определение буферов протокола
syntax = "proto3"; package userservice; // Define message User message User { string userId = 1; string name = 2; string email = 3; string address = 4; } // Define service UserService service UserService { rpc GetUserById (UserIdRequest) returns (User); } // Define message UserIdRequest message UserIdRequest { string userId = 1; }
Для службы управления пользователями необходимо реализовать сервер gRPC, соответствующий определению службы, приведенному в файле .proto. Это включает в себя создание необходимой серверной логики для обработки входящих запросов gRPC и генерации соответствующих ответов.
import io.grpc.stub.StreamObserver; import userservice.User; import userservice.UserIdRequest; import userservice.UserServiceGrpc; public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase { @Override public void getUserById(UserIdRequest request, StreamObserverresponseObserver) { // Assuming you have a database to retrieve user information. User user = User.newBuilder() .setUserId(request.getUserId()) .setName("Michel J") .setEmail("[email protected]") .setAddress("Mountain View, Santa Clara, California") .build(); responseObserver.onNext(user); responseObserver.onCompleted(); } } import io.grpc.Server; import io.grpc.ServerBuilder; public class UserServer { public static void main(String[] args) throws Exception { Server server = ServerBuilder.forPort(9090) .addService(new UserServiceImpl()) .build() .start(); System.out.println("Server started on port 9090"); server.awaitTermination(); } }
Преимущества:
Высокая производительность и эффективность использования полосы пропускания благодаря использованию HTTP/2 и буферов протоколов.
Поддерживает несколько языков программирования и обладает хорошей масштабируемостью.
Недостатки:
Требуется уровень трансляции, если сервисы не поддерживают gRPC.
Может быть сложнее в развертывании и управлении.
Асинхронная связь — это процесс отправки службой запроса другой службе без блокировки собственной операции для ожидания ответа. Обычно это достигается с помощью очередей сообщений или систем публикации/подписки.
Системы очередей сообщений, такие как RabbitMQ и Apache ActiveMQ, облегчают асинхронную связь между службами.
Преимущества:
Улучшенная масштабируемость и отказоустойчивость: система может лучше справляться с возросшими рабочими нагрузками и менее подвержена сбоям.
Снижение нагрузки на службы. Благодаря разделению отправки и получения запросов основные службы могут сосредоточиться на обработке задач, не перегружаясь постоянными запросами.
Недостатки:
Могут потребоваться дополнительные усилия для управления и обслуживания: системы на основе очередей могут быть более сложными и требовать больше ресурсов для работы.
Сложности с обработкой заказов и обеспечением доставки сообщений. Обеспечение того, чтобы запросы обрабатывались в правильном порядке и чтобы ни одно сообщение не было потеряно, может оказаться технической проблемой.
Система Pub/Sub (публикация/подписка), такая как Apache Kafka или Google Pub/Sub, позволяет сервисам публиковать сообщения и подписываться на темы.
Преимущества:
Поддерживает крупномасштабные потоки данных с высокой пропускной способностью.
Уменьшает зависимости между сервисами.
Недостатки:
Требуется более сложный уровень для управления темами и сообщениями и их мониторинга.
Может быть сложно справиться с проблемами порядка и надежности сообщений».
Если вам интересно, вы можете прочитать мои предыдущие статьи на тему pub/sub.
Очередь недоставленных писем в брокере сообщений, часть 1
Очередь недоставленных писем в брокере сообщений, часть 2
Проблемы согласованности и надежности в системе Message Broker
Обмен данными, управляемый событиями, — это когда служба генерирует событие, а другие службы реагируют или предпринимают действия на основе этих событий.
Синхронные события возникают, когда служба отправляет событие и ожидает ответа от других служб.
Преимущества:
Легко контролировать и контролировать процесс обработки событий.
Недостатки:
Может вызвать узкие места, если отвечающие службы работают медленно или сталкиваются с ошибками
Асинхронные события возникают, когда служба генерирует событие и ей не нужно ждать немедленного ответа.
Преимущества:
Сокращает время ожидания и улучшает масштабируемость.
Помогает службам работать более независимо и уменьшает взаимные зависимости.
Недостатки:
Требуются дополнительные механизмы для обеспечения правильной и своевременной обработки событий.
Сложности в обеспечении порядка и обработке повторяющихся событий.
Выбор метода связи между службами в системе микросервисов зависит от таких факторов, как требования к производительности, надежность и сложность системы. Каждый метод имеет свои преимущества и недостатки, и понимание этих методов поможет вам построить более эффективную и гибкую систему микросервисов. Внимательно рассмотрите требования вашей системы, чтобы выбрать наиболее подходящий метод связи.
Отказ от ответственности: Все предоставленные ресурсы частично взяты из Интернета. В случае нарушения ваших авторских прав или других прав и интересов, пожалуйста, объясните подробные причины и предоставьте доказательства авторских прав или прав и интересов, а затем отправьте их по электронной почте: [email protected]. Мы сделаем это за вас как можно скорее.
Copyright© 2022 湘ICP备2022001581号-3