[Анализ и проектирование систем, IT-инфраструктура, Микросервисы] REST or Events? Choose the right communication style for your microservices
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Microservices Architecture is a well-known pattern for building a complex system that consists of loosely coupled modules. It provides better scalability, and it is easier to develop the system in multiple teams so that they don’t interfere with each other too much. Moreover, microservices can be platform-agnostic and be written in different languages. However, it is important to choose the right way of communication between them. Otherwise, this kind of architecture can do more harm than good.There are 3 main ways to organize interaction between microservices:
- Remote Procedure Calls (RPC)
- Representational State Transfer (REST)
- Event-based communication
All three ways have different pros and cons in different situations.Remote Procedure CallsRPC allow us to hide the complexity of making a call to a remote service and make an operation look like it is executing locally. There are a lot of frameworks that help to make such calls. For example, the WCF framework in .NET helps to easily generate client-code so that a call to a remote service occurs almost seamlessly. Also, it supports different formats of passing data, including the binary format which allows achieving high performance.Nevertheless, the RPC approach has some disadvantages. First of all, some RPC frameworks are technology-specific and require that both client and server run on the same platform like Java or .NET. Such restrictions in interoperability can limit our options when we develop our architecture.Another disadvantage is that RPC may require updating both the client and the service whenever some insignificant part of the contract changes. For example, if we want to remove the unnecessary field of the object that is returned by the service, we might be required to regenerate the client-side code. Otherwise, it could break when we deploy the new version of our service. Such a problem often occurs when the data is being passed in binary form.RESTREST is another popular style of communication. In fact, it is usually a default choice when it comes to building microservices because it provides scalability and flexibility. Also, it makes the interface predictable and consistent if you follow the standards closely. For example, if you use the POST request method, you know that some entity will be created on the server and if you use the GET method, you will receive a representation of an existing entity. No need to come up with your own custom names for operations like “createOrder” or “retrieveOrder”.One of the most important concepts of REST has a strange abbreviation HATEOAS (Hypermedia as the Engine of Application State). Basically, it helps us to decouple the interface of the operation from the particular implementation details. For example, if our consumer received a representation of an object Photo from the service, we might also want to find out in which album this photo is situated. If we don’t follow REST, we need to know in advance which URL address we should hit to get the album, for example /albumStorage/id. But what if the location of the album changes to another URL? We would need to update the configuration of our consumer to reflect that change so that we don’t send a request to the old address. This is time-consuming.HATEOAS comes in handy here. According to Wikipedia this REST principle states the following:
A REST client needs little to no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia.
In our example, if we follow the REST approach then when a consumer receives a Photo from the service, the JSON response will contain a separate field “album” with a value that represents a location of this resource: /albums/id. The client just needs to know that if it wants to get an album it should look in the corresponding field in the response. No need to know the exact URL in advance. Therefore if the URL of the album changes in the future, we don’t need to update the client.There are some situations when REST is not optimal though. For example, if performance is the primary concern, it might be better to try other options. This is because REST works via HTTP protocol and HTTP have some overhead in terms of passing data. If you want to increase the performance as much as possible, you could consider using RPC frameworks that work with other networking protocols, like UDP.Event-based communicationThough REST-style is probably the best default choice for inter-services communication, there is another approach that helps to decouple microservices even more — event messaging.Consider a situation when we have to perform a business operation like making a purchase. In case of a pure REST-approach, our PurchaseService will make a call to the NotificationService to send an email to a customer with the details about the purchase. But what if the NotificationService has a bug in it and it takes forever to process the request? The PurchaseService will be frozen until the NotificationService responds and this will spoil the customer experience — nobody wants to wait too long until our purchase is processed.
REST-based communicationWe can resolve this problem by applying events instead of requests/responses. Since immediate sending of an email notification is not really important at the time of purchase, it is ok if it is sent several minutes later. We just need to make sure that this event is scheduled and an email will be sent eventually. PurchaseService actually doesn’t need to know whether NotificationService is operational at the time of the purchase, so it can just emit an event that will be stored in the event message broker (like RabbitMQ for example). 
Event-based communicationThe NotificationService will subscribe for the events in the broker and will take them from the event queue. As a result, we don’t have a tight coupling between PurchaseService and NotificationService and they can work independently. Once the event is stored in the events queue of the broker, PurchaseService will return a response to a client, and customer experience will be improved because there is no need to wait until all non-urgent steps are finished.Though event-based communication style has a lot of advantages, they come with some tradeoffs. It may be hard to understand all steps of the business process since each service works independently and there is no single service that is responsible for the overall operation. This may lead to strange bugs when one part of the process finished correctly and another — failed. Debugging can be difficult since it is hard to say which exact request in microservice A caused the wrong behavior in microservice B. This problem can be mitigated by using correlation IDs and monitoring tools which can bind all parts of the operation together and show some meaningful logs.ConclusionAs we can see, all 3 communication styles have their own pros and cons. There is no silver bullet, it is ok to use a mix of them, we just need to make sure that we use them in the right context. I recommend to use REST by default and RPC for types of operations that require extremely low latency. In case some operations are non-urgent and don’t require immediate feedback from the service, an event-based approach is a way to go.I hope this information was useful and cast some light upon the topic. For further reading, I recommend the following great books: “Building Microservices” by Sam Newman, “Microservices Patterns” by Chris Richardson.
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Конференции, Будущее здесь, IT-компании] ЦИПР-2021: бизнес, власть, NFT и немного 18+
- [Разработка мобильных приложений, Разработка под Android, Kotlin] View Model не обязательно наследоваться от ViewModel
- [IT-инфраструктура, Облачные вычисления] Гибридная ИТ-инфраструктура: как прикрутить облака к реальности?
- [IT-инфраструктура, Облачные вычисления, Серверное администрирование, Облачные сервисы] Bare metal за 5 минут: как мы из андерклауда сделали облачный сервис для аренды выделенных серверов
- [PHP, API] На php тоже может быть легко и быстро
- [Высокая производительность, Системное администрирование, Хранение данных] Версионирование Инфомодели Авито
- [Системное администрирование, IT-инфраструктура, DevOps] Разбираем в деталях: Технология единого входа (SSO) в Kubernetes с использованием OpenID Connection через G Suite (перевод)
- [Системное администрирование, Python, IT-инфраструктура, DevOps] Зачем инженеру эксплуатации знать Python: три кейса из практики
- [Анализ и проектирование систем, Интерфейсы, API] Проектирование интеграции с веб-сервисом
- [Анализ и проектирование систем, Разработка мобильных приложений, Usability, Дизайн мобильных приложений] Запихнуть многоквартирный дом в маленький телефон
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_itinfrastruktura (IT-инфраструктура), #_mikroservisy (Микросервисы), #_rest_api, #_rpc, #_architecture, #_eventdriven_programming, #_rest, #_microservices, #_events, #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_itinfrastruktura (
IT-инфраструктура
), #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:58
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Microservices Architecture is a well-known pattern for building a complex system that consists of loosely coupled modules. It provides better scalability, and it is easier to develop the system in multiple teams so that they don’t interfere with each other too much. Moreover, microservices can be platform-agnostic and be written in different languages. However, it is important to choose the right way of communication between them. Otherwise, this kind of architecture can do more harm than good.There are 3 main ways to organize interaction between microservices:
A REST client needs little to no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia.
 REST-based communicationWe can resolve this problem by applying events instead of requests/responses. Since immediate sending of an email notification is not really important at the time of purchase, it is ok if it is sent several minutes later. We just need to make sure that this event is scheduled and an email will be sent eventually. PurchaseService actually doesn’t need to know whether NotificationService is operational at the time of the purchase, so it can just emit an event that will be stored in the event message broker (like RabbitMQ for example).  Event-based communicationThe NotificationService will subscribe for the events in the broker and will take them from the event queue. As a result, we don’t have a tight coupling between PurchaseService and NotificationService and they can work independently. Once the event is stored in the events queue of the broker, PurchaseService will return a response to a client, and customer experience will be improved because there is no need to wait until all non-urgent steps are finished.Though event-based communication style has a lot of advantages, they come with some tradeoffs. It may be hard to understand all steps of the business process since each service works independently and there is no single service that is responsible for the overall operation. This may lead to strange bugs when one part of the process finished correctly and another — failed. Debugging can be difficult since it is hard to say which exact request in microservice A caused the wrong behavior in microservice B. This problem can be mitigated by using correlation IDs and monitoring tools which can bind all parts of the operation together and show some meaningful logs.ConclusionAs we can see, all 3 communication styles have their own pros and cons. There is no silver bullet, it is ok to use a mix of them, we just need to make sure that we use them in the right context. I recommend to use REST by default and RPC for types of operations that require extremely low latency. In case some operations are non-urgent and don’t require immediate feedback from the service, an event-based approach is a way to go.I hope this information was useful and cast some light upon the topic. For further reading, I recommend the following great books: “Building Microservices” by Sam Newman, “Microservices Patterns” by Chris Richardson. =========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_itinfrastruktura ( IT-инфраструктура ), #_mikroservisy ( Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:58
Часовой пояс: UTC + 5