Vert.x for Microservices Architecture
Download as PPTX, PDF6 likes3,241 views
Vert.x is a toolkit for building reactive microservices applications on the JVM. It uses the reactor pattern with a single-threaded event loop to avoid the C10K problem. Verticles are lightweight concurrent units that communicate asynchronously via an event bus. This allows building scalable and reactive microservices. Vert.x supports websockets, clustering, reactive programming with RxJava, and can be deployed to production environments like AWS. It also integrates with Spring for dependency injection and configuration.
Vert.x for Microservices Architecture
- 1. Vert.x for Microservices Architecture Idan Fridman Idan.frid@gmail.com www.idanfridman.com
- 2. Agenda • The C10k problem • Understanding the Reactor pattern • The good (and the bad) of Vert.x and when we should use it. • Vertx and Websockets • RxJava And Vertx • Vert.x into production
- 3. Traffic, Traffic Traffic...! Lots of machines http://www.internetlivestats.com/one-second/
- 4. One machine scenario Simple use case: Response Request Datasource
- 6. Current Setup Opening a new connection for every single request/response pair Default HTTP connector is blocking and follows a one thread per connection model to serve 1000 concurrent users, it requires 1000 active threads
- 7. C10K Problem Prevented servers from handling more than 10,000 concurrent connections. The Apache problem is the more connections the worse the performance. Let’s assume we execute 1000 “quick” transactions then you’ll only have about a 1000 concurrent connections to the server Change the length of each transaction to 10 seconds now at 1000 transactions/sec - you’ll have 10K connections open
- 8. “Why like this?” Webserver gets a connection it starts a worker/thread 1. Memory limit Each Thread takes min memory(default 1024k == 1mb) 2. Operating system limit The operating system by default can't open 10k threads. 10 concurrent requests==10k threads==10k * 1MB==10GB
- 9. Reactor pattern From wiki: The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.
- 10. Reactor pattern(Revisited) We already understand the The disadvantage of using a separate thread for each event listener The reactor pattern is one implementation technique of event-driven architecture it uses a single threaded event loop blocking on resource-emitting events and dispatches them to corresponding handlers and callbacks.
- 11. Reactor pattern model Reactor A Reactor runs in a separate thread, and its job is to react to IO events by dispatching the work to the appropriate handler. It’s like a telephone operator in a company who answers calls from clients and transfers the line to the appropriate contact.
- 12. Reactor pattern model Handlers A Handler performs the actual work to be done with an I/O event, similar to the actual officer in the company the client wants to speak to. A reactor responds to I/O events by dispatching the appropriate handler. Handlers perform non-blocking actions.
- 13. Event-Loop Standard reactor implementation: single event loop thread which runs around in a loop delivering all events to all handlers as they arrive.
- 15. Don’t call us, we’ll call you Main thread should works very quickly No long jobs in the loop Schedule a call asynchronously Operations in event loop should just schedule all asynchronous operations with callbacks and go to next request without awaiting any results.
- 16. We love the JVM - Let’s have vert.x 1. Microservices toolkit for the JVM 2. Asynchronous 3. Scalable 4. Concurrent services development model 5. Polyglot language development with first class support for JavaScript, Ruby, Groovy, Scala, and of course Java. Vertx is a toolkit not a framework or/container (means you can use it within your existing application to give it the Vert.x super powers)
- 17. Vertx & Friends
- 18. Vertx main server types Httpserver Websockets server TCP server
- 19. Easy as that
- 20. Building Vertx with Verticles Verticle is the building blocks of Vert.X which reminds an Actor-like approach for concurrency model and avoiding mutable shared data Each Verticle can communicate with another using EventBus(explain later) Verticle types: Standard Verticles Worker Verticles
- 21. Verticle Types Standard verticles Assigned an event loop thread when they are created All the code in your verticle instance is always executed on the same event loop You can write all the code in your application as single threaded and let Vert.x worrying about the threading and scaling.
- 22. How to run blocking-code anyway? Worker verticles Executed not using an event loop, but using a thread from the Vert.x worker thread pool. Worker verticles are designed for calling blocking code, as they won’t block any event loops. *Unlike Nodejs where you need to use promises with vertx you can handle blocking-code out of the box
- 23. The Event Bus Eventbus is build-in tunnel which providing a messaging mechanism to all Vertx components. Different parts of your application able communicate with each other irrespective of what language they are written in. The event bus supports publish/subscribe, point to point, and request-response messaging. Eventbus features: registering handlers unregistering handlers and sending messages publishing messages.
- 24. Eventbus - Event Driven built-In Eventbus will be help you to scale up your Vert.x Cluster.
- 25. Eventbus and the Microservices way
- 26. Clustering Discovery and group membership of Vert.x nodes in a cluster Maintaining cluster with topic subscriber lists (so we know which nodes are interested in which event bus addresses) Distributed Map support Distributed Locks EventBus can be clustered: When clustering different vert.x instances on the network they going to use the same single distributed eventbus
- 27. Hazelcast Vertx can use different cluster-managers. The default one is Hazelcast Hazelcast is in-memory operational platform Easy Discovery service
- 28. Adding JWT capabilities Security is very important within microservices. Vert.x Has Built-in JWT support. You can issue JWT tokens and validate them within your Vert.x Endpoints
- 29. Websockets Web technology that allows a full duplex socket-like connection between HTTP servers and HTTP clients (typically browsers). Once established: “Push” messages Data frames can be sent back and forth between the client and the server in full- duplex mode Native to Browsers
- 30. WebSocket connection remains open so there is no need to send another request to the server
- 31. Websockets and Vertx Vertx enable out of the box support using Websockets. Vert.x supports WebSockets on both the client and server-side.
- 32. Websockets Handler server.websocketHandler(websocket -> { System.out.println("WebSocket is On!"); }); Handler will be called when connection established:
- 33. SockJS Client side JavaScript library and protocol which provides a simple WebSocket-like interface Make connections to SockJS servers irrespective of whether the actual browser or network will allow real WebSockets. Supporting various different transports between browser and server, and choosing one at run-time according to browser and network capabilities. Transparent
- 34. Eventbus using sockJS bridge Client side allows you to send and publish messages to the event bus and register handlers to receive messages Router router = Router.router(vertx); SockJSHandler sockJSHandler = SockJSHandler.create(vertx); BridgeOptions options = new BridgeOptions(); sockJSHandler.bridge(options); router.route("/eventbus/*").handler(sockJSHandler);
- 35. Reactive And Vertx Natural couple
- 36. Open many workers in eventloop? bad Open too many workers won't makes you any different Work asynchronously Who said callback (hell)? Vertx Supports the popular RxJava library that allows you to write observers that react to sequences of events.
- 37. Scenario Example 1. Client calls to our app’s web service -> 2. our webservice need to request multiple micro-services-> 3. uses a callbacks interface to pass the successful result to the next web service call 4. define another success callback- > 5. and then moves on to the next web service request. Orchestrator A B C F Client Request
- 38. Looks like that-> Also known as: “The Callback Hell”
- 39. //The "Nested Callbacks" Way public void fetchUserDetails() { //first, request the users... mService.requestUsers(new Callback<GithubUsersResponse>() { @Override public void success(final GithubUsersResponse githubUsersResponse, final Response response) { Timber.i(TAG, "Request Users request completed"); final List<GithubUserDetail> githubUserDetails = new ArrayList<GithubUserDetail>(); //next, loop over each item in the response for (GithubUserDetail githubUserDetail : githubUsersResponse) { //request a detail object for that user mService.requestUserDetails(githubUserDetail.mLogin, new Callback<GithubUserDetail>() { @Override public void success(GithubUserDetail githubUserDetail, Response response) { Log.i("User Detail request completed for user : " + githubUserDetail.mLogin); githubUserDetails.add(githubUserDetail); if (githubUserDetails.size() == githubUsersResponse.mGithubUsers.size()) { //we've downloaded'em all - notify all who are interested!
- 40. Async our microservices call (Using Reactor) A library for composing asynchronous and event-based programs by using observable sequences. ● Allow you to compose sequences together declaratively ● Abstracting away : o low-level threading o synchronization o thread-safety o concurrent data structures o non-blocking I/O.
- 41. RxJava for the rescue ● RxJava is single jar lightweight library. ● Using the Observable abstraction and related higher-order functions. (Support Java6+) The following external libraries can work with RxJava: ● Camel RX provides an easy way to reuse any of the Apache Camel components, protocols, transports and data formats with the RxJava API ● rxjava-http-tail allows you to follow logs over HTTP, like tail -f ● mod-rxvertx - Extension for VertX that provides support for Reactive Extensions (RX) using the RxJava library
- 42. Zipping Observables (Without blocking) public Observable<Boolean> registerRequest(..) { return Observable.zip( createNewRoomNode(), createNewWaveNode(), logRecordOnMysql(), sendWelcomeMessage() , (r1, r2, r3, r4) -> r1 && r2 && r3 && r4); } private Observable<Boolean> createNewRoomNode(..) { ... return } private Observable<Boolean> createNewWaveNode(..) { ... return } private Observable<Boolean> logRecordOnMysql(..) { ... return }
- 43. Vertx going to production (Deployment) Vertx can be deployed to AWS with Hazelcast Discovery is taking placing using the same security groups
- 44. Vertx going to production Enterprise ready solution which can be deployed on amazon Combining powerful technology with complete production solution Empower Spring configurations, env’s, defaults, libs with vertx technology
- 45. Spring Into Vertx (Benefits) DI Have a deployment ready container Configurations setup Endpoints and JMX ready Spring Data and more
- 46. Practical implementation Spring into vert.x ● On starter Verticle initiate Spring context ● Pass Spring context to each verticle as param ● Gotchas: Make sure you always share the same spring context
- 47. Vertx Into Spring Leverage Spring-MVC while expose controllers endpoints Send Operational events via Eventbus(e.g send commands to connected endpoints, websockets, etc.. Deploy Verticles inside Spring