Scalable Highly Available Distributed System with JBoss/WildFly

4,873 views

Published on

JBoss Enterprise Application Platform and Wildfly are flexible and mature platforms with excited features like small memory footprint and lightning fast startup times.

Learn how JBoss can help to build distributed system and achieve scalability and high availability independently of application frameworks and datastores.

http://developer-should-know.tumblr.com/

Published in: Software

Scalable Highly Available Distributed System with JBoss/WildFly

  1. 1. SCALABLE HIGHLY AVAILABLE DISTRIBUTED SYSTEM WITH JBOSS Author Evgeniy Khist
  2. 2. SCALABLE HIGHLY AVAILABLE DISTRIBUTED SYSTEM WITH JBOSS JBoss Enterprise Application Platform and Wildfly are flexible and mature platforms with excited features like small memory footprint and lightning fast startup times Learn how JBoss can help to build distributed system and achieve scalability and high availability independently of application frameworks and datastores
  3. 3. WHY DO WE NEED DISTRIBUTED SYSTEM? We can't guarantee that single server instance will be able to handle growing amount of requests just updating hardware
  4. 4. WHAT IS DISTRIBUTED SYSTEM? A set of independent computers that can be viewed by its clients as a single system
  5. 5. WHAT DO WE EXPECT FROM DISTRIBUTED SYSTEMS? Ability to handle growing amount of load Little effort required to increase capacity No unplanned downtime
  6. 6. WHAT DIFFICULTIES DO DISTRIBUTED SYSTEMS INTRODUCE? Multiple points of failure Data consistency across the nodes Complexity of managing
  7. 7. DISTRIBUTED ARCHITECTURE Distributed system is heterogeneous Distributed system has multiple autonomous components Component is a modular unit that can be used exclusively
  8. 8. DISTRIBUTED SYSTEM
  9. 9. APPLICATION INTEGRATION STYLES There are four main approaches for integrating components of distributed system File transfer - application produces files of shared data for others to consume, and consumes files that others have produced Shared database - applications store the shared data in a common database RPC (Remote Procedure Call) - application exposes some of its procedures so that they can be invoked remotely by other applications to run behavior and exchange data Messaging - application is connected to a common messaging system, and exchange data and run behavior using messages
  10. 10. MESSAGING Messaging is a method of communication between software components or applications Messaging enables distributed communication that is loosely coupled Requires an extra component in the architecture, the message broker
  11. 11. MESSAGE BROKER
  12. 12. JMS Java Message Service is a Java API that allows applications to create, send, receive, and read messages. Asynchronous Reliable - message is delivered once and only once
  13. 13. MESSAGE QUEUE Producer puts message into the queue Any available at this moment consumer capable of handling this message takes it from the queue
  14. 14. MESSAGE QUEUE
  15. 15. MESSAGE QUEUE
  16. 16. SCALABILITY Scalability is the ability of a system to expand to handle a growing amount of work For example, ability of a system to scale to handle larger number of users
  17. 17. TWO WAYS OF SCALING APPLICATIONS Vertical Scalability - adding more resources within the same application to increase capacity (adding CPUs to an existing server, adding hard drive on an existing RAID storage) Horizontal Scalability - adding multiple application instances and making them work as a single unit
  18. 18. HORIZONTAL SCALABILITY Is typically achieved using clustering and load balancing Cluster is homogenous and consists of multiple instances of distributed system component Typically each cluster node runs on its own server instance
  19. 19. HORIZONTAL SCALABILITY
  20. 20. HORIZONTAL SCALABILITY
  21. 21. HORIZONTAL SCALABILITY
  22. 22. MESSAGE BROKER CLUSTERING
  23. 23. FAULT-TOLERANCE Fault-tolerance is ability of a system to continue operating properly when some part of the system fails Availability is the amount of time that a system is actually available relative to the amount of time it is expected to be available Fault-tolerant systems are typically based on the concept of redundancy Redundancy is the duplication of critical components of a system for increasing reliability of the system
  24. 24. STATELESSNESS Stateless means no client context being stored on the server between requests, but passed with each request But stateless service can talk to other services maintaining state of business objects
  25. 25. STATELESSNESS Easier to scale Reduces memory usage No need for session data replication
  26. 26. ASYNCHRONOUS REQUEST PROCESSING Asynchronous communication using JMS on back-end Request can be in one of states: S B I E , I _ R G E S UMTD NPORS, DN,FIE OE ALD Request can change from one state to another during processing by different modules
  27. 27. CONSISTENCY Message consumption from one queue and sending to another queue should be done in single transaction If node fails after message consumption, but before sending message to other destination, it will be returned to queue and can be consumed again by any other node
  28. 28. CONSISTENCY
  29. 29. CONSISTENCY Alternatively, write-ahead transaction log (journal) can be used In case of node failure transaction log can be replayed or other actions can be taken
  30. 30. CONSISTENCY
  31. 31. ASYNCHRONOUS REQUEST PROCESSING AJAX polling on front-end After sending request to API request id will be sent in response This request id will be used for polling request status Long-polling from async-servlets (Servlet 3.0) can be used for efficient polling When status shows that request is completed, additional details can be requested
  32. 32. SYNCHRONOUS JMS
  33. 33. JMS REQUEST-REPLY PATTERN JMS can be also used for synchronous communication Using temporary queues for replies Temporary queue address is sent in JMSReplyTo message property, so only sender knows about reply queue Using shared reply queue with message selector Filtering by JMSCorrelationID, for example Using exclusive reply queue Not cluster-safe until each node (even of the same module) has separate queue for replies
  34. 34. CONSISTENCY Calls to 3rd party services is often done by HTTP or other protocol not supporting ACID transactions
  35. 35. HTTP CALLS TO THIRD-PARTY SERVICE
  36. 36. HTTP CALLS TO THIRD-PARTY SERVICE
  37. 37. CONSISTENCY To solve this issue write-ahead transaction log (journal) can be used Transaction log can be stored locally for each node In case of node failure transaction log can be replayed After failure node will request 3rd party service for transaction status and basing on response will repeat transaction
  38. 38. WRITE-AHEAD TRANSACTION LOG
  39. 39. WHY JBOSS? Clustering Deployment API Distributed caching (Infinispan) Distributed deployment Failover Hibernate integration Robust messaging subsystem (HornetQ) Load balancing Management API Logging (SLF4J implementation) JBoss Modules
  40. 40. CONFIGURATION CONCEPTS standalone.xml or domain.xml and host.xml JBoss Web Console JBoss Command Line Interface (CLI)
  41. 41. JBOSS MODULES JBoss Modules is a standalone implementation of a modular (non-hierarchical) class loading and execution environment for Java. In other words, rather than a single class loader which loads all JARs into a flat class path, each library becomes a module which only links against the exact modules it depends on, and nothing more. It implements a thread-safe, fast, and highly concurrent delegating class loader model, coupled to an extensible module resolution system, which combine to form a unique, simple and powerful system for application execution and distribution.
  42. 42. JBOSS MODULES Unlike OSGi, JBoss Modules does not implement a container; rather, it is a thin bootstrap wrapper for executing an application in a modular environment.
  43. 43. DEMONSTRATION https://github.com/evgeniy-khist/blog/tree/master/Kiev-Ciklum-Java-Saturday-2013_11_23
  44. 44. More slides

×