We are designing a reporting system using microservice architecture. All the services are supposed to be subscribers to the event bus and they communicate by raising events. We also decided to expose each of our services using REST api. Now the question is , is it a good idea to create our services as web api [RESTful] applications which are also subscribers to the event bus? so basically there are 2 ponits of entry to each service - api and events. I have a feeling that we should separate out these 2 as these are 2 different concerns. Any ideas?
Since Microservices architecture are Un-opinionated software design. So you may get different answers on this questions.
Yes, REST and Event based are two different things but sometime both combined gives design to achieve better flexibility.
Answering to your concerns, I don't see any harm if REST APIs also subscribe to a queue as long as you can maintain both of them i.e changes to message does not have any impact of APIs and you have proper fallback and Eventual consistency mechanism in place. you can check discussion . There are already few project which tried it such as nakadi and ponte.
So It all depends on your service's communication behaviour to choose between REST APIs and Event-Based design Or Both.
What you do is based on your requirement you can choose REST APIs where you see synchronous behaviour between services
and go with Event based design where you find services needs asynchronous behaviour, there is no harm combining both also.
Ideally for inter-process communication protocol it is better to go with messaging and for client-service REST APIs are best fitted.
Check the Communication style in microservices.io
REST based Architecture
Advantage
Request/Response is easy and best fitted when you need synchronous environments.
Simpler system since there in no intermediate broker
Promotes orchestration i.e Service can take action based on response of other service.
Drawback
Services needs to discover locations of service instances.
One to one Mapping between services.
Rest used HTTP which is general purpose protocol built on top of TCP/IP which adds enormous amount of overhead when using it to pass messages.
Event Driven Architecture
Advantage
Event-driven architectures are appealing to API developers because they function very well in asynchronous environments.
Loose coupling since it decouples services as on a event of once service multiple services can take action based on application requirement. it is easy to plug-in any new consumer to producer.
Improved availability since the message broker buffers messages until the consumer is able to process them.
Drawback
Additional complexity of message broker, which must be highly available
Debugging an event request is not that easy.
Related
all new to Masstransit and are currently evaluating it for a larger project and
wondering if anyone could help get a better understanding of the following challenges:
"Single consumer of events in a loadbalanced environment"
In production our services will be runinng multiple instances for scalability and failvover and be
part of a larger ecosystem of microservices. The overall architecture is based on Microsofts eshoponcontainers
reference implementation where different microservices are communicating with each other via "integrationevents".
When publishing a IntegrationEvent to other services which I assume should be done as described in Masstransit Producers / Publish
, https://masstransit-project.com/usage/producers.html#publish, how can I assure that only ONE instance in a specific microservice are processing
the event but of course that the event reaches ALL microsystem that depends on the event? When we have done similar solutions based on Azure Functions
this requirement has been solved by using the "Singelton" attribute (https://learn.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to#singleton-attribute).
Azure Service Bus
Reading the documentation my impression is that Masstransit is very RabbitMQ centric.
Since we will be on the Azure Service bus when moving to production is there any limitations or features
not available on that "transport"?
Regards Niclas
For the first question, it's a normal publish-subscribe with competing consumers. It works like this out of the box, there's nothing that needs to be done to achieve this.
When running multiple instances of the same service
Use the same queue name for each instance
Messages from the queue will be load balanced across all instances (the competing consumer pattern)
It's from the RMQ Guidances, but it's like this for all transports.
Concerning the Azure Service Bus transport, it works as expected and has a lot of production users. It's properly documented as well.
I'd say for both of your questions the answer is "it just works".
gRPC is a modern open source high performance RPC framework that can
run in any environment. It can efficiently connect services in and
across data centers with pluggable support for load balancing,
tracing, health checking and authentication. It is also applicable in
last mile of distributed computing to connect devices, mobile
applications and browsers to backend services.
I'm finding GRPC is becoming increasingly more pertinent in backend infrastructure, and would've liked to have it in my favorite language/tsdb kdb+/q.
I was surprised to find that kdb+ does not have a grpc implementation. Obviously, the (https://code.kx.com/q/interfaces/protobuf/)
package doesn't support the parsing of rpc's, is there anything quantitatively preventing there being a KDB+ implementation of the rpc requests/services etc. found in grpc?
Why would one not want to implement rpc's (grpc) in kdb+ and would it be a good idea to wrap a c++/c implemetation therin inorder to achieve this functionality.
Thanks for your advice.
Interesting post:
https://zimarev.com/blog/event-sourcing/myth-busting/2020-07-09-overselling-event-sourcing/
outlines event sourcing, which I think might be a better fit for kdb?
What is the main issue with services using RPC calls to exchange information? Well, it’s the high degree of coupling introduced by RPC by its nature. The whole group of services or even the whole system can go down if only one of the services stops working. This approach diminishes the whole idea of independent components.
In my practice I hardly encounter any need to use RPC for inter-service communication. Partially because I often use Event Sourcing, more about it later. But we always use asynchronous communication and exchange information between services using events, even without Event Sourcing.
For example, an order microservice in an e-commerce system needs customer data from the customer microservice. These dependencies between microservices are not ideal. Other microservices can go down and synchronous RESTful requests over https do not scale well due to their blocking nature. If there was a way to completely eliminate dependencies between microservices completely the result would be a more robust architecture with less bottlenecks.
You don’t need Event Sourcing to fix this issue. Event-driven systems are perfectly capable of doing that. Event Sourcing can eliminate some of the associated issues like two-phase commits, but again, not a requirement to remove the temporal coupling from your system.
Edit v1:
I have been going through some system design videos and learnt about microservice architecture using message queues and event-driven architecture.
But I don't seem to find any substantial point of difference between the two.
Both have different components/services publishing or subscribing to eventBus/messagingQueues and performing the tasks associated with the published event.
Is microservice architecture with messaging queues a subset of event driven architecture or is there something more to it that I need to figure out.
Original V0:
I have been going through some system design videos and learnt about microservice architecture and event-driven architecture.
But I don't seem to find any substantial point of difference between the two.
Both have different components/services publishing or subscribing to eventBus/messagingQueues and performing the tasks associated with the published event.
Is microservice architecture a subset of event driven architecture or is there something more to it that I need to figure out.
Event Driven Architecture is a system design concept where we use "techniques" to achieve synchronous or asynchronous communication in our system. More likely than not we want asynchronous communication.
Such techniques can be pub/sub, long polling, Queueing, websockets and etc.
Microservice is an approach to designing our system where we make our services decoupled to one another or at least we try our best to. For example, Facebook's newsfeed service is independent of other services like Profile, photos and messaging. One benefit of this is "separation of concerns", so for example if newsfeed goes down we can still continue to upload photos and chat our friends. If FB was "monolith", one service going down could have taken down the whole site. Another benefit of microservice is deployability, the smaller the service the faster to test and deploy.
Let's take pizza for example, deciding whether to cut it in squares or triangular, or how big/small the slices are is thinking microservices. Which one to eat first and next is thinking event-driven. Do you go for the larger slices, mixed, small ones or meatier ones? Just like how our systems can decide intelligently what events to trigger next.
Just remember that these are concepts to help you understand an existing system, or help you decide how you would build your system. In the real-world when you onboard to a new company you'll find yourself asking questions like
How service-oriented is the system?
How eventful is the flow of data?
Short answer to your question... they're not necessarily related but inevitably we implement them together when scaling one or the other.
For example given this microservice architecture
[checkout service] ---> [email service]
Let's say the user waits very long for checkout and email to finish. 90% of the wait is coming from the email service. In reality the user should be able to continue browsing the other pages while they wait for the email.
In this example we solved the long wait time by adding Queue
[checkout service] ---> [Queue] ---> [email service]
We've improved user experience by making our microservice more eventful. When the user clicks the checkout button, a response is returned immediately allowing the user to continue browsing while the "email event" is dispatched to the queue.
Short answer: No, these are not the same and not subsets.
Both have different components/services publishing or subscribing to eventBus/messagingQueues and performing the tasks associated with the published event.
This is wrong. Microservices are not necessary about events and publishing/subscribing.
In this case Wikipedia tackles this very question.
From a formal perspective, what is produced, published, propagated,
detected or consumed is a (typically asynchronous) message called the
event notification, and not the event itself, which is the state
change that triggered the message emission. Events do not travel, they
just occur. However, the term event is often used metonymically to
denote the notification message itself, which may lead to some
confusion. This is due to Event-Driven architectures often being
designed atop message-driven architectures, where such communication
pattern requires one of the inputs to be text-only, the message, to
differentiate how each communication should be handled.
https://en.wikipedia.org/wiki/Event-driven_architecture
I'll be honest, I treated them the same when designing and writing code. But I guess technically there is a difference, as per the paragraph quoted above.
Technically we cannot use the word "Same" in this case. Below will give a clear relation between these artifacts:
Event-driven Microservices rely on message queues (to store/forward messages) to send/receive events, wrapped in messages.
Event-driven architectures usually leverage messaging technology in order to transport the information that something has happened in the past from one place to another or many other places.
Message queues can also be used in a non-event driven architecture, for instance, to perform asynchronous request/response communication.
In addition, when using an event-driven approach the information that is transmitted is usually different, it is just indicating what (business) event has happened with usually fewer information than provided by normal messages.
For instance, you can send a message to create a new order in an online shop system and the message could contain all the information the receiver needs to process it. The important thing is also that there is dedicated receiver of the message.
In the event-driven approach some component would rather send some order checkout requested event (or similar) without knowing what other component or what other components (think of publish/subscribe mechanisms) will "listen* to that event and perform corresponding actions. In such an architecture it would also make sense to send other events before the actual checkout happens, such as new shopping cart created or item added to cart event.
So the event-driven approach also implies some kind of choreography between your Microservices where more complex business operations can include lots of events published and processed by different components without having one central component which orchestrates who gets what information in what order.
Of course, from my experience, it makes perfect sense to combine event-driven choreography and non-event driven orchestration in a Microservices architecture depending on the use cases.
I'm developing an application that must both handle events coming from other systems and provide a REST API. I want to split the applications into micro services and I'm trying to figure out which approach I should use. I drew attention to the Spring Cloud Netflix and the Spring Cloud Data Flow toolkit, but it's not clear to me whether they can be integrated and how.
As an example, suppose we have the following functionality in the system:
1. information about users
card of orders
product catalog
sending various notifications
obtaining information about the orders from third-party systems
processing, filtering, and transformation of order events
processing of various rules based on orders and sending notifications
sending information about user orders from third-party systems to other users using websockets (with pre-filtering)
Point 1-4 - there I see the classical micro service architecture. Framework - Spring Netflix Stack.
Point 5-9 - it's best to use an event-driven approach. Toolkit - Spring Data Flow.
The question is how to build communication between these platforms.
In particular - POPULATE ORDER DETAILS SERVICE must transform the incoming orders and save additional information (in case it needed) in the database. ORDER RULE EXECUTOR SERVICE should obtain information about the current saved rules, execute them and send notifications. WEB SOCKET SERVICE should send orders information only if a particular user has set the filters, and ORDER SAVER SERVICE should store the information about the transformed orders in the database.
1.
Communication between the micro-services within the two platforms could be using the API GATEWAY, but in this case, I have the following questions:
Does the Spring Cloud platform allow to work with micro services that way?
Performance - the number of events is very huge, which can significantly slow down the processing of events. Is it possible to use other approaches, for example, communication not through the API Gateway but through in-memory cache?
2.
Since some functionality intersects between these services, I have a question about what is "microservice" in the understanding of the Spring Cloud Stream framework. In particular, does it make sense to have separate services? Can the microservice in the Spring Cloud Stream have a REST API, work with the database and simultaneously process the events? Does such a diagram make sense and is it possible to build such a stack at the moment?
The question is which of these approaches is more correct? What did Spring Data Streams mean by "microservice"?
Given the limited information in the post, it is hard to convince on all the matters pertaining to this type of architecture, but I'll attempt to share some specifics, and point to samples. Also for the same reasons, it is hard to solve for your needs end-to-end. From the surface, it appears you're attempting to build event-driven applications and wondering whether Spring Cloud Stream (SCSt) and Spring Cloud Data Flow (SCDF) could help.
They can, yes.
The Order, User, and Catalog seem like domain objects and it would all come together to solve for a use-case. For instance, querying for a number of orders for a particular product, and group by the user. There are a few samples that articulate the data flow between the entities to solve similar problems. Here's a live code-walkthrough of event-driven systems in action. There's another example of social-graph application, too.
Though these event-driven applications can run standalone as individual services with the help of of message broker (eg: Kafka or RabbitMQ), you could of course also register them in SCDF and use them in the SCDF DSL to build a coherent data pipeline. We are expanding on more direct capabilities in SCDF for these types of use-cases, but there are ways to orchestrate them today with current abilities, too. Follow spring-cloud/spring-cloud-#2331#issuecomment-406444350 for more details.
I hope this gives an idea. Try to build something small using SCSt/SCDF, prove it out, and expand to more complex use-cases.
I've been reading up on Microservice Architecture But I still can't understand the inter-microservices communication mechanism.
In many articles they said that microservices are usually exposed over a RESTful API. But when you search the internet you always see implementations based on messaging and events for the backend communications.
So I'm confused, Is REST API a standard for all the microservices or we can see microservices without a REST endpoints.
For your problem , first lets understand the ways in which one service interacts with each other , lets create two service order service and customer service :
One service need some data from other service to process its requests, eg: lets say you want to place an order , so from ui you must hit http request to order service (which can be rest , or have a api gateway in between n that use some other protocol like protobu ) to call order service for placing an order , now assume order service needs to check the validity of the customer , so order service needs to call customer service in sync — most probably you will hit rest or create a protobuf or have a persistent websocket between the service and then after response from customer service , order service move ahead.
In this case sync communication needs to be imitated , one direct approach is rest or protobuff , or imitate it through messaging
Based on one service events , you want to update other service : in this generally the preferred style is messaging bus , where one service emits out event and multiple other services have a listener on the messaging bus and react accordingly . Eg : lets say on update of customer name in customer service , you want to update the cached name of the customer in order service , in this when name is updated in customer service , it emits customer name updated event , order service subscribe to it , then react to it
Your third question is , is it possible to have service with no rest endpoint ::: yes its possible , but every service needs to be reachable . So use rest or other form is needed
Above mentioned link : microservices.io is very good , go through it once again
REST is not the only style available for microservice-to-microservice (aka inter-process communication/IPC) but it is the most popular IPC technology used by applications based on microservices-styled architecture. There are other technologies like Apache Thrift and gRPC which can serve the same purpose. Essentially all of these technologies are industry-grade implementations of RPC (Remote Procedure Call).
I highly recommend you to read this link by Microservices Expert - Chris Richardson
One of the benefits of using microservices (if not the biggest) is that it eliminates any long-term commitment to a technology stack. When developing a new service you can pick a new technology stack. Similarly, when making major changes to an existing service you can rewrite it using a new technology stack.
So, you can choose whatever communication mechanism you want as long as it does not prevent you changing the technology stack. REST over HTTP is a good choice because it hides the technologies used by the microservice to generate the responses in a request-response synchronous style. Message-based communications are also a good fit because the messages could also hide the technologies used to produce them (as long as you don't use the builtin serialization of the producer programming language), i.e. RabbitMQ or Apache Kafka.
REST is universally supported, its accepted on all languages, if all your backend services are running in the same location you may not see much different in throughput.
Anyhow its a good idea to invest and learn gRPC or Thrift as mentioned above, you could convert all your internal services to gRPC for example (supported on most languages) and do a conversion between gRPC and REST at your Universal Gateway.
There are two approaches to internal architecture, CQRS vs Plain REST calls. The eventing/messaging is an example of CQRS, where you can separate read/write side operations and all write side operations can be implements through eventing for better scalability and throughput.