Building reactive microservices with MicroProfile

the micro-services my name is Martin Stefano I work as software engineer at Red Hat I'm a big makeup of elf and I also make a profile kilometres since August this year and you can find me on Twitter on the handle like Stefan today I'm going to talk about how we do reactive in micro profile and I would like to start with a quick story or better direct you story it all started a long long time ago in 2014 with reactive manifesto where a group of independent companies came together and identified a set of properties that we can found in modern robust and resilient micro-services applications they call these applications are active systems and these four properties that they identified was a synchronous message passing that basically means that the communication between your services needs to be decoupled to basically a named channels that means that you are always sending a synchronous messages to somewhere to lized address what is in turn gives you is directly elasticity so you can scale the services behind this virtual address and you have some form of world balancer that is just distributing the messages and resiliency because if there is no service behind this virtual address the channel itself or the publishing side can somehow buffer the messages and resend them if needed basically a synchronous messages always needed to be acknowledged so unless there is an acknowledgement the message will be sent again all these three properties together will give you together principle responsive system and this is the most important emphasis that the reactive system put on because if you don't make correct sorry responsive system what will happen basically the long answer is interacting money faster itself but the short answer is that we all know what the users do if your system is not responding and then it's a different kind of story so after active system and this properties we came up with an idea that maybe we can expand on this and we identified that there we are already doing this in one form of another in many different forms and we call this collectively reactive programming so we are probably familiar with fibers or project room which is coming next versions of Java even based system like message driven beings or even Excel spreadsheets when you can set one table to be updated every time some other table is updated other cell is updated so basically what these all things have in common is that they are reacting to change instead of creating the situation itself so we are reacting on receiving the message we are not requesting a message to be received what they all have in common is that they need to be non-blocking because if you block in anything that is a synchronous you are basically degra gating back to a synchronous system from reactive programming and this non balking ideas a few years back another group of companies led by light band came with the specification of a really simple API call active streams basically the active streams are for Java interfaces that are able to define non-blocking data pipes with back pressure that means that we have now some publishing side connected to a pipe to receiving or subscribing side and only form of communication is done to this pipe a synchronously what the backpressure mean is basically that the subscriber can tell to the publishing side that I am NOT able to consume any more messages until I process what I already got and after I am finished with my processing I will tell you that you can continue publishing again these four interfaces that there are in reactive streams are publisher publishing side on the pipe subscriber receiving side processor is something in bit in between it's able also to consume messages and also produce them and subscription is an object which is linking basically publish another subscriber since Java 9 all of these interfaces are actually part of the JDK in itself in Java you talk on current flow class so basically the communication interactive streams greatest reward a pretty straightforward we as a first request there is a unsubscribe call or sorry subscribe call on publisher with the subscriber instance publisher in turn must invoke unsubscribe call began a subscriber in which subscriber rich received the subscription the subscription has only two methods one is for consuming the receiving and the second one is for bit pressure and this one is called request which is taking a single long value with the number of values that the subscriber is telling publisher that is able to receive so if we request two values publisher is then requested to invoked on the next callback on a subscriber two times with different published values this can happen several times always only the allowed value of requested which a subscriber is sending until a subscriber requests more values that there are actually present or there is an error in that sense the subscriber will receive on complete or on error callbacks which basically terminates the stream and terminates the communication pretty simple like this whole API has together around ten methods so it's simple Java API we can implement it actually there is several good articles on the internet why you shouldn't do it yourself but there is also a TCK for these active streams API so if you are willing to do that I would say go give it a try but to get it right to pass this d ck is really hard so from our active streams basically we needed some form of abstraction on top of that because if we are only subscribing to values which are published there is nothing really much do there is nothing that we can really do with it we are just receiving the values that are being published so another group of companies came with an idea to create something which reactive extensions which is expanding on reactive streams providing the implementation of the publisher and subscriber for instance and also giving you a set of operation operators that you can use to manipulate these things like basic operations from Java eight streams like map or filter and the most known ones are attics Java for Bible class or project reactor in spraying flux or mono so maybe you already are using this and you maybe even don't know it and Michael Provo basically comes somewhere between these two because it's building on top of reactive streams but it's also providing something similar to reactive extensions and this is what we are going to talk about today so Michael profile reactive is actually or consists of two specification the first one is reactive streams operators which is reactive streams class plus the set of operators like map and the second one is called reactive messaging which is a development model based on CDI beans which you are able to connect throughout the reactive streams and we will go through both of them but I prefer to show you this in our IDE so I will create now a new project with Quercus call imperial active and open I did I come on I need to change first and opening it IBE and I will put Quercus into a death mode so we can see the live reload sorry I need to close a few things and let's open the generated class so for starters we will start with just active streams operators this is a really simplistic specification which is more targeted as a base for active messaging so what it provides us with is basically this reactive and sorry I didn't include it because in Quercus we have this form of extension so I need to actually include reactive streams operators as an extensions to actually get this functionality in focus sorry about that and let's return to the death note now if I enable import I should get a reactive streams class come on idea live demos and now when it's running idea should be happy and I can return their active streams directive streams I still can't oh now I can and I will be using their active streams off so basically this is really similar to project reactor or to Eric's Java so if you are familiar with it this is just like unifying naming on top of that so I can create the stream with directly some default values like uppercase that was a new starburst or trailer yesterday in my new car and then you can play with this kind of stream that is going to be publish so my stream is really simple it's going to only publish free values but I can directly use operations that you are used from Java 8 streams so I can for instance map everything to uppercase I can filter only ones which are shorter let's say than 3 characters and then I can collect everything to a list and what this gives us back is something which is called competition runner which has only one method run which will return a competition stage and this we can directly return from our objects are in the end point users are typically not required to call this around Metin themselves because the framework will run dn't for boredom so if I now invoke this in point we should get back only three wrong characters with in uppercase so this is the basic idea of reactive streams really use these reactive streams as an entry point and build whatever reactive streams classes that you will need I can also show here just to say see something different there are also a bunch of from methods which are taking for instance reactive streams publishers so I can create here some publish for instance and this will be publisher I wants bubbly strings and I can for instance use Eric's Java here so I can use reactive streams as a specification then unifies these two I don't know flammable interesting so I can't because I don't have follow ball and I should have okay nevermind or this is not the right aquifer no it is yeah but I should have Eric's Java coming with but my idea is making fun of me really live demo so I have it here so let's just publish every second this will give us a long so let's just map it to string yeah just drink so I'm now creating Eric's java publisher but I am plugging it into a publisher of reactive streams now we don't need this mapping and we can collect this two lists because actually this will produce values every second so let's just create also subscriber subscriber and as I said this is really hard thing to do so don't try this at home and I will do a new subscriber of let's just print here m and we will save subscription which we received this will be a subscription and we will request one element in our own next goal we will just print the value that we received and again we need to request another value we want to continue continuously on error we can just print this error and completely print that we are completed so this looks good up to the point that this is now going to run independent in definitely so we are unable to return anything so I can just avoid it here and now if I type everything right when I recently received our unsubscribe and every second we are getting values so this is really this pipe that we are connecting now publisher to a subscriber so this would be really the simplest possible example of reactive streams operators and let's continue with our active messaging so as I said reactive messaging is basically specification that allows you to build these individual parts in CDI beans and interconnect them throughout your application or with your micro service so in the beginning we have some CDI bean which is defining some publisher who is publishing some values to some channel this can be directly consuming some different cd-i being which for instance only do some evaporation and continuously continuously up to the point it receives it is received by some CDI being which will consume them so there is a subscriber on the other end but because all of the CDI beans are always on one micro-service you are probably wanting to put this reactive architecture throughout your all microservices deployment so what my cup of reactive messaging also allows you to do is to consume the stream directly from somewhere outside of your service outside of your system and also produce it somewhere else to do these there is a motion of a connector in my capri for active messaging which is basically a class that you can implement yourself it needs to implements two interfaces which basically only create publisher builder and subscriber builder which are classes in reactive messaging which are transforming the messages from your external services to something reactive messaging can understand so then your users are just able to plug these connectors directly into their micro services and you can for instance consume messages directly from Kafka and push them on the other side on the other end to an I'm qpq from a user perspective what really micro profile reactive messaging is is are only two annotations the first one is outgoing which is taking one required string which is the name of the channel that you are going to consume messages from and the second one is incoming oh sorry you are going to produce messages and the second one is incoming which is defining the channel which you are going to consume you are also able to combine these two annotations to defy reactive streams processors and I want to point out that in all of these examples you can notice that we are always processing on doing a single message so basically this method is going to be invoked for every value that is going to be produced in my incoming channel and it's going to produce exactly one value to my outgoing channel there is also an option to work with a whole stream if you prefer to define your map and filter operations on that and with that I will get to my last demo which will be a coffee shop which we are going to start with basic HTTP coffee shop and we will see what the issues with synchronous and blocking calls are and we will try to rewrite this to a messaging so what we will start with that we have our user who are making HTTP calls to our front-end coffee shop service which in turns makes a HTTP request on our bacon sandwich with this barista which is actually responsible for preparing the coffee so if a user requests coffee the call is propagated in a blocking manner to a barista series barista will take some time which is randomized after the coffee is prepared it the call HTTP call just returned the response and this response is propagated to users so you would say that user is happy because he got the coffee but actually he is or she is not because they needed to wait for the whole duration of the request so that you can imagine that you will come to a coffee shop and you will order a coffee and they will stand there for five minutes until the coffee is prepared so what will happen when actually barista burns down or takes a break so again somebody requests the coffee the call to the barista service will fail because there is no barista and we will just return this error to the user so user is again not really happy because I just count out the coffee anymore and I have this prepared so let's try to take a look I have this kind of naming I hope that is readable so I will start my coffee shop service I will start my oh sorry come on and what sorry maybe I need to compile it first so I will start my hopefully coffee shop service yeah it's running let's start our barista series which are still based on HTTP and what we are able to do now is actually to make this user request we are requesting a coffee if you're not familiar with HTTP this is just invoking localhost / HTTP sorry and this product and name is going to be concluded in a JSON format so we are sending JSON with two properties and if we send the message it was received in our coffee shop from and propagated to barista and after barista was ready maybe it was too fast now it's preparing coffee it will just say that the coffee is ready and the call is returned back as you can see for the duration of the request as it is randomized my client is booked I cannot do anything with it if I now kill the barista service and try to order coffee we all get a really nice error to the users which users definitely know how to decode so let me stop stop these services and what I'm going to do now is actually rewrite this service really quickly to Iraq the messaging so we will still have our users which are making HTTP requests to our front end but this time we are not doing back to the back end HTTP requests we are we will be using messages sending to an Apache Kafka through through two different topics the first message is sent to queue topic which will be answering people directly return so we will be not blocking anymore the other clients that means that we are making actually responsive system the first message is going to be propagated to a queue which will be displayed on the board which users can read that my coffee is still being prepared and the second order is going to be consumed by a barista service which will take again it's time to actually prepare the coffee and when the coffee is ready he or she will again push the message to a queue service we just changed the state of the coffee on the board that the coffee is prepared and the users can a synchronously read that the coffee was prepared from the board so this is more similar to a Starbucks model so we will order the coffee they will give you some ticket you will go sit somewhere and when the coffee is ready they will just notify you a synchronously that the coffee is ready so you can pick it up you are not standing at the counter so let me try to actually implement this so here I have our micro services deployment open in an IDE and we will start by changing our coffee shop resource as you can see here we only have one HTTP endpoint which is our blocking HTTP big big hint call if you are familiar with micro profile restclient this is basically only definition of res invocation so this will block until exactly as we saw previously so what I will do now is to add a new endpoint and we will call it messaging and I will write an a synchronous and a responsive endpoint that will just propagate messages to the Apache Kafka which I got running in the background so now I cannot return beverage because I will not have beverage ready in time so let's just create something which will return an order and we will also take an order as an argument that's that JSON that I was sending from command line I can actually use the same because we will need to come on I cannot use this oh but it's somewhere hidden okay I will copy paste because I cannot see the window who will which will refactor to a method will need to again set the ID on the order we will print it to the standard output but here we will send messages to Kafka we will not make an HTTP call and since we don't want to block this method anymore we can directly return and order so the user has something to confirm that the order was received to actually send messages to Kafka we need to first configure our connector which is quite maybe more otherwise configurations that we need to put into our services I will just save time because it's a lot of typing basically this is the standard format how we could configure an interactive messaging Connect or any basically messaging reactive channel it's always MP messaging then it's incoming or outgoing depending on what we are going with to do with the channel then it's the name of the order and then it's concrete values that you are going to set as you can see all of the other example is going to go through Kafka smaller Kafka is an implementation of the connector and we will be sending string messages so I can see here that I will be sending out going to two topics one is called order and one is called Q so if I want to use these I can use CDI since this is a CDI beam and I can inject directly the channel itself and again idea is and yeah I forgot again to add the extensions sorry so again with Kirkus if we want to start using some functionality we first need to edit as an extension so what I'm adding here is reactive messaging and the calf connector and I will actually need to edit into both of the services you can see that it was added successfully and if now I go back I should have channel and I don't come on idea now I have as a channel is a custom annotation for smaller which allows you to bridge synchronous or blocking world with the reactive so if I want to publish messages to Kafka from and blocking HTTP requests I need to inject the channel itself and I know the first one was called queue and what I will be injecting is an emitter object which allows us to send messages to the channel and I will do the same for our topic orders so I can inject orders since I will be marshalling Jason I will also inject Jason B and Jason B's now joke at a specification that allows us to change or like exchange Java objects to a JSON representation so I will do just Jason B okay so we want to send our messages to Kafka first thing that we want to send is a message to the board that the coffee is actually being prepared for did I have a helper class which will just say order s cute come on order this is a helper class that will just marshal JSON with some specialized property which is then recognized on the front end our second message needs to be sent to an orders queue and here we need to use actually Jason B to marshal the JSON to a string representation ourself so I just called to JSON order and we should be good to go in our front-end one last thing that I need to do is to create our dashboard which will be displaying something in a front-end because that's only a simple HTML and for that I will use servers and eiements server sent events so this will be available at queue and we will be producing media type and not this media type as SSC and I can come on idea like this yes so and this will be actually publishing I know what I did wrong I forgot that it will be publishing with throughout the joxer's publisher because as easy or jax-rs is able to breach directly list at least reactive streams publisher to service tournaments so we know that we will be publishing strings from our get queue let's call it that and here I would like to return the queue itself and for that we can can look into other configuration we have a one incoming channel called now beverages which is still defaulting to queue just we can recognize that this is an incoming channel so this is actually consuming from the topic queue into a channel beverages so if I now want to use this channel I can again just inject inject Channel but this time is called juice and this time we are not going to produce value so we need to inject something different and we can also directly inject publisher but for the time being I would like to inject rather specialized form from reactive messaging which is called publisher builder because I want to log these messages as they are arriving so let's call this Q and here we can just return Q but first I want to peek at every message that is being received to this Q and I will just bring it to standard output got process and now I can build it as reactive streams implementation and that's it so that would be everything for our front-end what we need to do to actually change our backend barista who is now defined with only blocking post endpoint to actually make this endpoint work within the reactive way so I will actually change only these endpoints to now or first lets me start it again a bunch of properties that I need to come in put into our properties file in this case is a little bit more properties because here we are really configuring Kafka itself this everything after what is especially specialized for micro profile active messaging are settings that are going to be passed to the Kafka this is why there is a little bit more of configuration here but this is already available online so this is not something that you will type every time this time we are not going to be injecting any channels we are going to use that incoming and outgoing annotations directly and since I always forgot how these are cold we are going to be consuming from an orders and we are going to be producing to a queue so I know that I will have incoming messages messages from orders and I will be outputting to queue since now we are working with Kafka and we are selling everything into a string we need to change this method signature to actually consume and produce strings messages and this method is going to be invoked for every message that is going to be produced into an orders topic and we are going to produce exactly one message to a topic queue so this can be again the same we first need to dis relies our order from the message because we are sending it there from the front and we know that it's a JSON representation in string form so we can again do JSON be let's just do it differently this way just to change things listen be and since I can only have the default one I can create it myself and I can now do Jason B and called the other for moment from Jason which will take our message and weave in we know that it's sir sorry sir allies order Clause so now we have our order and the last thing that we need to do is to publish a message to our topic q so now it's not going to be beverage but it's again to be a preparation state which is a helper class but this time it's already we already know that the beverage is ready so we can just say here order and created beverage and that's it that's everything that we need to do to change from HTTP to reactor so if I now restart the services again and I didn't make any silly errors now we should be able come on do I have cough chronic now I don't have cataracts okay sorry so let me just start Kafka and also create only one of the topics that we are going to use because we I want to show you scaling so we need to some specialized settings for a Kafka for the orders topic and now if I start services they shouldn't have problem to connect to a Kafka but okay that looks better and now if we try to invoke that a new endpoint that we created you see that it returned immediately but the coffee was preferred just now so I can queue several messages and you see that my service is responsive and the coffee is still being prepared in our barista service there is actually this front-end that I was talking about and let me just pick this out too what we are showing you here so basically we have our queue here so if I now in queue some order we should see it here in queue state and after our barista will prepare it develop this transform from the two ready so our front-end is consuming from the topic queue and it's directly displaying the messages we can also see them locked in our front-end service so going back to my slides just really quick I don't really have time to show it now to you but since our messages are now killed in orders topic what will happen if we kill the barista service they will just stay in a cafe and when barista comes back again it will continue consuming messages what the CAF this decoupling also allows us to do is to scale baristas on the background and if they are not able to consume messages in a timely manner they will just start some round-robin algorithm on the background and this is basically it like really you saw how easy is it to move from synchronous and blocking HTTP way of processing to reactive way of defining things it requires a little change of mindset of how we think about defining our software but it's not something that we are not doing already nowadays so if you like what you're sorry both of these specifications are available as open source we are encouraging anybody to contribute so if you think that this would be useful for you or you have some ideas how to improve these just go to github or find us on Twitter any ideas are welcome this would be everything from myself and if you have any questions I have one minute it depends if you have that satellizer and this or eliezer but you can implement it yourself and sorry I should have if I can strongly type Sarah desires ha sanitizers and disorder lasers that was the question anything else if no thank you for your attention and hopefully you like what you see

Channel: Eclipse Foundation

Views: 1,458

Keywords: EclipseCon Europe, Microservices, Java

Id: sldnpoEtVWY

Length: 35min 0sec (2100 seconds)

Published: Mon Nov 25 2019