Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Vert.X: Microservices Were Never So Easy (Clement Escoffier)

4.036 Aufrufe

Veröffentlicht am

Vert.x 3 is a framework to create reactive applications on the Java Virtual Machine. Vert.x 3 takes the JVM to new levels of performance yet having a small API. It lets you build scalable microservice-based applications transparently distributed and packaged as a single jar file. Due to this simplicity, deploying and managing Vert.x applications on OpenShift 3 is a breeze, upload your jar and Vert.x internal cluster manager will connect all your pods in single distributed network. Several examples are shown during the talk and demonstrate how Vert.x can simplify DevOps daily job when working together with OpenShift 3.

Veröffentlicht in: Software

Vert.X: Microservices Were Never So Easy (Clement Escoffier)

  1. 1. VERT.X M I C R O S E R V I C E S W E R E N E V E R S O E A S Y CLEMENT ESCOFFIER Vert.x Core Developer, Red Hat
  2. 2. VERT.X I N 1 0 S L I D E S . . .
  3. 3. V E R T. X I S A TO O L K I T T O B U I L D D I S T R I B U T E D A N D R E AC T I V E A P P L I C A T I O N S O N T O P O F T H E J V M U S I N G A N A S Y N C H R O N O U S N O N - B L O C K I N G D E V E L O P M E N T M O D E L .
  4. 4. TOOLKIT Vert.x is a plain boring jar Vert.x components are plain boring jars Your application depends on this set of jars (classpath, fat- jar, ...)
  5. 5. TOOLKIT These slides are served by a vert.x application: executed on Openshift packaged as a fat jar vertx-core: the main vert.x component vertx-web: a component to build modern web applications vertx-hazelcast: an implementation of the vert.x cluster manager vertx-service-discovery-bridge-kubernetes: an extension to interact with Kubernetes
  6. 6. DISTRIBUTED
  7. 7. DISTRIBUTED “ You know you have a distributed system when the crash of a computer you've never heards of stops you from getting any work done. (Leslie Lamport)
  8. 8. REACTIVE Reactive systems are Responsive - they respond in an acceptable time Elastic - they scale up and down Resilient - they are designed to handle failures gracefully Asynchronous - they interact using async messages http://www.reactivemanifesto.org/
  9. 9. REACTIVE “ "Moore's law" is the observation that, over the history of computing hardware, the number of transistors in a dense integrated circuit has doubled approximately every 2 years. Unfortunately, no free lunch anymore...
  10. 10. REACTIVE CPU manufacturers cannot get a single-core CPU to go any faster Multi-core Processors Require parallel execution Require a different way to design, develop and execute software Reactive systems is one solution to this issue
  11. 11. POLYGLOT Vert.x applications can be developed using Java Groovy Ruby (JRuby) JavaScript (Nashorn) Ceylon
  12. 12. MICROSERVICES R E B R A N D I N G D I S T R I B U T E D A P P L I C A T I O N S
  13. 13. MICROSERVICES “ The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. (Martin Fowler)
  14. 14. A SUITE OF INDEPENDENT SERVICES: Each service runs in its own process So they are distributed applications Lightweight interactions - Loose-coupling Not only HTTP Messaging Streams (async) RPC
  15. 15. A SUITE OF INDEPENDENT SERVICES: Independently developed, tested and deployed Automated process (Liskov) substitutability It's all about agility Agility of the composition You can replace any microservice You can decide who uses who
  16. 16. SORRY... NO FREE LUNCH Distributed applications are hard fail (fail-stop, byzantine fault) Discoverability issue Reliability issue Availability issue How to keep things on track Monitoring Health Tracing ...
  17. 17. COMPLEXITY GROWTH
  18. 18. VERT.X & MICROSERVICES We wont' build regular microservices, but reactive microservices Responsive - fast, is able to handle a large number of events / connections Elastic - scale up and down by just starting and stopping nodes, round-robin Resilient - failure as first-class citizen, fail-over Asynchronous message-passing - asynchronous and non- blocking development model
  19. 19. ASYNCHRONOUS & NON- BLOCKING
  20. 20. WHAT DOES VERT.X PROVIDE TO BUILD MICROSERVICES? TCP, UDP, HTTP 1 & 2 servers and clients (non-blocking) DNS client Event bus (messaging) Distributed data structures Load-balancing Fail-over Service discovery Failure management, Circuit-breaker Shell, Metrics, Deployment support
  21. 21. HTTP & REST B E C A U S E I T A L W A Y S B E G I N W I T H A R E S T
  22. 22. VERT.X HELLO WORLD vertx.createHttpServer() .requestHandler(request -> { // Handler receiving requests request.response().end("World !"); }) .listen(8080, ar -> { // Handler receiving start sequence completion (AsyncResult) if (ar.succeeded()) { System.out.println("Server started on port " + ar.result().actualPort()); } else { ar.cause().printStackTrace(); } });
  23. 23. VERT.X HELLO WORLD Invoke
  24. 24. E V E N T L O O PS
  25. 25. VERT.X ASYNC HTTP CLIENT HttpClient client = vertx.createHttpClient( new HttpClientOptions() .setDefaultHost(host) .setDefaultPort(port)); client.getNow("/", response -> { // Handler receiving the response // Get the content response.bodyHandler(buffer -> { // Handler to read the content }); });
  26. 26. SERVICE DISCOVERY Locate the services, environment-agnostic
  27. 27. SERVICE DISCOVERY - KUBERNETES No need for publication - Import Kubernetes services HttpEndpoint.getClient(discovery, new JsonObject().put("name", "vertx-http-server"), result -> { if (result.failed()) { rc.response().end("D'oh no matching service"); return; } HttpClient client = result.result(); client.getNow("/", response -> { response.bodyHandler(buffer -> { rc.response().end("Hello " + buffer.toString()); }); }); });
  28. 28. CHAINED HTTP REQUESTS Invoke
  29. 29. INTERACTING WITH BLOCKING SYSTEMS
  30. 30. MESSAGING WITH THE EVENT BUS T H E S P I N E O F V E R T . X A P P L I C A T I O N S
  31. 31. THE EVENT BUS The event bus is the nervous system of vert.x: Allows different components to communicate regardless the implementation language and their location whether they run on vert.x or not (using bridges) Address: Messages are sent to an address Handler: Messages are received in handlers.
  32. 32. POINT TO POINT
  33. 33. PUBLISH / SUBSCRIBE
  34. 34. REQUEST / RESPONSE
  35. 35. DISTRIBUTED EVENT BUS Almost anything can send and receive messages
  36. 36. DISTRIBUTED EVENT BUS Let's have a java (Vert.x) app, and a node app sending data just here: hello from java (8321) hello from java (8320) hello from java (8319) hello from java (8318) hello from java (8317) hello from java (8316) hello from java (8315) hello from java (8314) hello from java (8313)
  37. 37. DISTRIBUTED EVENT BUS
  38. 38. EVENTBUS CLIENTS AND BRIDGES Clients: SockJS: browser, node.js TCP: every system able to open a TCP socket Go: for system develop in Go Bridges: Stomp AMQP Camel
  39. 39. RELIABILITY PATTERNS D O N ' T B E F O O L , B E P R E P A R E D T O FA I L
  40. 40. RELIABILITY It's not about being bug-free or bullet proof, it's impossible. It's about being prepared to fail, and handling these failures.
  41. 41. MANAGING FAILURES Distributed communication may fail vertx.eventbus().send(..., ..., new DeliveryOptions().setSendTimeout(1000), reply -> { if (reply.failed()) { System.out.println("D'oh, he did not reply to me !"); } else { System.out.println("Got a mail " + reply.result().body()); } });
  42. 42. MANAGING FAILURES Invoke
  43. 43. MANAGING FAILURE client.get("/", response -> { response .exceptionHandler(t -> { // If the content cannot be read rc.response().end("Sorry... " + t.getMessage()); }) .bodyHandler(buffer -> { rc.response().end("Ola " + buffer.toString()); }); }) .setTimeout(3000) .exceptionHandler(t -> { // If the connection cannot be established rc.response().end("Sorry... " + t.getMessage()); }) .end();
  44. 44. MANAGING FAILURE Invoke
  45. 45. CIRCUIT BREAKER
  46. 46. CIRCUIT BREAKER cb.executeWithFallback(future -> { // Async operation client.get("/", response -> { response.bodyHandler(buffer -> { future.complete("Ola " + buffer.toString()); }); }) .exceptionHandler(future::fail) .end(); }, // Fallback t -> "Sorry... " + t.getMessage() + " (" + cb.state() + ")" ) // Handler called when the operation has completed .setHandler(content -> /* ... */);
  47. 47. CIRCUIT BREAKER Invoke
  48. 48. SCALABILITY PATTERNS B E P R E P A R E D T O B E F A M O U S
  49. 49. BALANCING THE LOAD When several consumers listen to the same address, Vert.x dispatches the sent messages using a round robin. So, to improve the scalability, just spawn a new node!
  50. 50. BALANCING THE LOAD
  51. 51. BALANCING THE LOAD Invoke
  52. 52. SCALING HTTP
  53. 53. THIS IS NOT THE END() BUT THE FIRST STEP ON THE REACTIVE MICROSERVICE ROAD
  54. 54. HOW TO START ? http://vertx.io http://vertx.io/blog/posts/introduction-to-vertx.html http://vertx-lab.dynamis-technologies.com https://github.com/vert-x3/vertx-examples
  55. 55. Red HatNews youtube.com/Red Hat facebook.com/redhatinc THANK YOU! linkedin.com/company/red-hat

×