Recommended
More Related Content
What's hot
What's hot (20)
Similar to Event Driven Architecture
Similar to Event Driven Architecture (20)
More from Sistek Yazılım
Recently uploaded
Recently uploaded (20)
Event Driven Architecture
- 2. Agenda 01 02 03 04 Introduction To Event Driven Architecture What is Saga Pattern? Choreography-Based Saga Orchestration-Based Saga Benefits of Event Driven Architecture Message Brokers What is Message Broker? Vert.x What is Vert.x? How Does It Work? Spring Web Reactive What is WebFlux? Spring MVS vs WebFlux
- 3. Event Driven Programming Event-driven programming is a programming paradigm in which the flow of program execution is determined by events - for example a user action such as a mouse click, key press, or a message from th e operating system or another program. An event-driven application is designed to detect events as they occur, and then deal with them using an appropriate event-handling procedure.
- 4. What is a distributed transaction? When a microservice architecture decomposes a monolithic system into self-encapsulated services, it can break transactions. This means a local transaction in the monolithic system is now distributed into multiple services that will be called in a sequence. Monolithic System Microservices 03
- 5. What Is The Problem? In a database system, atomicity means that in a transaction either all steps complete or no steps complete. The microservice- based system does not have a global transaction coordinator by default. In the example above, if the CreateOrder method fails, how do we roll back the changes we applied by the CustomerMicroservice? How do we keep the transaction atomic? Do we isolate user actions for concurrent requests? If an object is written by a transaction and at the same time (before the transaction ends), it is read by another request, should the object return old data or updated data? In the example above, once UpdateCustomerFund succeeds but is still waiting for a response from CreateOrder, should requests for the current customer’s fund return the updated amount or not?
- 6. Possible SolutionsThe problems are important for microservice-based systems. Otherwise, there is no way to tell if a transaction has completed successfully. 2pc Pattern 2pc is widely used in database systems. For some situations, you can use 2pc for microservices. Just be careful; not all situations suit 2pc and, in fact, 2pc is considered impractical within a microservice architecture Saga Pattern The Saga pattern is another widely used pattern for distributed transactions. It is different from 2pc, which is synchronous. The Saga pattern is asynchronous and reactive.
- 7. So what is a two-phase commit? As its name hints, 2pc has two phases: A prepare phase and a commit phase. In the prepare phase, all microservices will be asked to prepare for some data change that could be done atomically. Once all microservices are prepared, the commit phase will ask all the microservices to make the actual changes.
- 8. Agenda Style2pcPattern 2pc is a very strong consistency protocol. First, the prepare and commit phases guarantee that the transaction is atomic. The transaction will end with either all microservices returning successfully or all microservices have nothing changed. Secondly, 2pc allows read-write isolation. This means the changes on a field are not visible until the coordinator commits the changes. Advantages While 2pc has solved the problem, it is not really recommended for many microservice-based systems because 2pc is synchronous (blocking). The protocol will need to lock the object that will be changed before the transaction completes. This is not good. In a database system, transactions tend to be fast—normally within 50 ms. However, microservices have long delays with RPC calls. Disadvantages
- 9. The SAGA Pattern A saga is a sequence of local transactions where each transaction updates data within a single service The first transac tion is initiated by an external request corresponding to the system operation, and then each subsequent step is triggere d by the completion of the previous one. Events/Choreography: When there is no central coordination, each service produces and listen to other service’s events and decides if an action should be taken or not. Command/Orchestration: when a coordinator service is responsible for centralizing the saga’s decision making and sequencing business logic
- 10. Events/Choreography 1.Order Service saves a new order, set the state as pe nding and publish an event called ORDER_CREATED _EVENT. 2. The Payment Service listens to ORDER_CREATED _EVENT, charge the client and publish the event BILLED_ORDER_EVENT. 3. The Stock Service listens to BILLED_ORDER_EVE NT, update the stock, prepare the products bought in t he order and publish ORDER_PREPARED_EVENT. 4. Delivery Service listens to ORDER_PREPARED_E VENT and then pick up and deliver the product. At the end, it publishes an ORDER_DELIVERED_EVENT 5. Finally, Order Service listens to ORDER_DELIVERED_EVENT and set the state of th e order
- 11. Rolling back in Saga’s Events/Choreography 1.Stock Service produces PRODUCT_OUT_OF_STOCK_EVE NT; 2.Both Order Service and Payment S ervice listen to the previous message: 3.Payment Service refund the client 4.Order Service set the order state as failed
- 12. Command/Orchestration 1.Order Service saves a pending order and asks Order Saga Orchestrator (OS O) to start a create order transaction. 2.OSO sends an Execute Payment co mmand to Payment Service, and it repli es with a Payment Executed message 3.OSO sends a Prepare Order comman d to Stock Service, and it replies with a n Order Prepared message 4.OSO sends a Deliver Order comman d to Delivery Service, and it replies with an Order Delivered message
- 13. Rolling back in Saga’s Command/Orchestration 1.Stock Service replies to OSO with an Out-Of-Stock message; 2. OSO recognizes that the transaction has failed and starts the rollback In this case, only a single operation wa s executed successfully before the failu re, so OSO sends a Refund Client com mand to Payment Service and set the o rder state as failed
- 14. Agenda StyleSagaPattern One big advantage of the Saga pattern is its support for long- lived transactions. Because each microservice focuses only on its own local atomic transaction, other microservices are not blocked if a microservice is running for a long time. This also allows transactions to continue waiting for user input. Also, because all local transactions are happening in parallel, there is no lock on any object. Advantages The Saga pattern is difficult to debug, especially when many microservices are involved. Also, the event messages could become difficult to maintain if the system gets complex. Another disadvantage of the Saga pattern is it does not have read isolation. For example, the customer could see the order being created, but in the next second, the order is removed due to a compensation transaction. Disadvantages
- 15. Message Broker In its core, a message broker is “a program that translates a message to a formal messaging protocol of the sender, to the formal messaging protocol of the receiver”
- 16. Which Message Brokers are out there to process my events? There are tons of message brokers out there (ActiveMQ, Kafka, RabbitMQ, OMS, JMS, Redis , Service Bus, …) three popular ones Apache Kafka Azure Event Hub RabbitMQ RabbitMQ was one of the first open source message brokers, developed to implement AMQP to work across different platforms and languages. Apache Kafka is a Message Broker originally developed by LinkedIn and open sourced early 2011. It is just like Azure Event Hub a platform capable of handling millions of events. Azure Event Hub allows you to set up a scalable Event Hub that suits your needs in a couple of seconds. It is a PaaS offering by Microsoft Azure, so that you do not need to manage it, but rather just consume it.
- 17. Blocking vs. Non-Bloking Blocking In traditional MVC applications, when a request come to server, a servlet thread is created. It delegates the request to worker threads for I/O operations such as database access etc. During the time worker threads are busy, servlet thread (request thread) remain in waiting status and thus it is blocked. It is also called synchronous request processing. Non-Bloking All incoming requests come with a event handler and call back information. Request thread delegates the incoming requests to a thread pool (generally small number of threads) which delegate the request to it’s handler function and immediately start processing other incoming requests from request thread. When the handler function is complete, one of thread from pool collect the response and pass it to the call back function.
- 18. Eclipse Vert.x is event driven and non blocking. This means your app can handle a lot of concurrency using a small number of kernel threads. Vert.x lets your app scale with minimal hardware. Vert.x is incredibly flexible - whether it's simple network utilities, sophisticated modern web applications, HTTP/REST microservices, high volume event processing or a full blown back- end message-bus application, Vert.x is a great fit. You can use Vert.x with multiple languages including Java, JavaScript, Groovy, Ruby, Ceylon, Scala and Kotlin. 01 02 03 04 Vert.x Eclipse Vert.x is a tool-kit for building reactive applications on the JVM. Polyglot Scale Flexible Vert.x is an ideal choice for creating light-weight, fast, high- performance, microservices. Fast
- 19. How does it look like? Vert.x Spring MVC As you can see, you add a request handler to your verticle. Then this handler will be invoked by the event loop for every request. After that you filter the requests (e.g. by HttpM ethod and path) and respond. You also have to start your HTTP server. The difference is here that Spring Boot provides defaults which allow you an easy start and get fast results. Spring MVC combined with Spring Boot has a higher usability and an easier readability in general. Also, you do not have to understand all that is going on in the background to create your Hello World application.
- 20. Spring WebFlux Spring WebFlux framework is part of Spring 5 and provides reactive programming support for web applications. Web Flux A non-blocking approach which makes it possible to handle concurrency with a small number of threads and to scale effectively Functional programming Less memory Availibility to serve traffic Spring WebFlux is a reactive web framework based on a reactive HTTP layer; such apps can be deployed on Netty or Undertow (with native adapters) or Jetty/Tomcat/any Servlet 3.1 container (thanks to a Servlet 3.1 adapter).