Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Consul: Microservice Enabling Microservices and Reactive Programming

27,698 views

Published on

Consul is a service discovery system that provides a microservice style interface to services, service topology and service health.

With service discovery you can look up services which are organized in the topology of your datacenters. Consul uses client agents and RAFT to provide a consistent view of services. Consul provides a consistent view of configuration as well also using RAFT. Consul provides a microservice interface to a replicated view of your service topology and its configuration. Consul can monitor and change services topology based on health of individual nodes.
Consul provides scalable distributed health checks. Consul only does minimal datacenter to datacenter communication so each datacenter has its own Consul cluster. Consul provides a domain model for managing topology of datacenters, server nodes, and services running on server nodes along with their configuration and current health status.
Consul is like combining the features of a DNS server plus Consistent Key/Value Store like etcd plus features of ZooKeeper for service discovery, and health monitoring like Nagios but all rolled up into a consistent system. Essentially, Consul is all the bits you need to have a coherent domain service model available to provide service discovery, health and replicated config, service topology and health status. Consul also provides a nice REST interface and Web UI to see your service topology and distributed service config.
Consul organizes your services in a Catalog called the Service Catalog and then provides a DNS and REST/HTTP/JSON interface to it.
To use Consul you start up an agent process. The Consul agent process is a long running daemon on every member of Consul cluster. The agent process can be run in server mode or client mode. Consul agent clients would run on every physical server or OS virtual machine (if that makes more sense). Client runs on server hosting services. The clients use gossip and RPC calls to stay in sync with Consul.

A client, consul agent running in client mode, forwards request to a server, consul agent running in server mode. Clients are mostly stateless. The client does LAN gossip to the server nodes to communicate changes.
A server, consul agent running in server mode, is like a client agent but with more tasks. The consul servers use the RAFT quorum mechanism to see who is the leader. The consul servers maintain cluster state like the Service Catalog. The leader manages a consistent view of config key/value pairs, and service health and topology. Consul servers also handle WAN gossip to other datacenters. Consul server nodes forwards queries to leader, and forward queries to other datacenters.
A Datacenter is fairly obvious. It is anything that allows for fast communication between nodes, with as few or no hops, little or no routing, and in short: high speed communication. This could be an Amazon EC2 availability zone, a networking environment like a subnet, or any private, low latency, high

Published in: Technology

Consul: Microservice Enabling Microservices and Reactive Programming

  1. 1. CONSUL Consul at a glance. ! The microservices architecture service discovery engine ! Enabling reactive programming by providing a reliable list of nodes participating in a cluster
  2. 2. Consul provides a consistent view of services and configuration
  3. 3. CONSUL • Service Discovery • Health • Config
  4. 4. Consul uses a microservices architecture to provide reliable service discovery and health monitoring
  5. 5. CONSUL • Consul provides service discovery • Consul provides a consistent view of services • Consul provides a consistent view of configuration • Consul uses a microservice interface to a replicated view of your topology and its configuration • Consul can monitor and change services topology based on health
  6. 6. FEATURES • scalable distributed health checks • minimal dc to dc communication • event system • domain model for managing topology of datacenters, server nodes, and services running on server nodes along with their configuration
  7. 7. CONSUL LIKE • DNS server plus Consistent Key/Value Store + ZooKeeper + Nagios + … = Consul • All the bits you need in a coherent model available to provide service discovery and replicated config
  8. 8. UI
  9. 9. SERVICES IN CATALOG • available via DNS • available via REST interface • Consul is a microservice architecture • HTTP • JSON
  10. 10. AGENT • Long running daemon on every member of Consul cluster • Client or server mode • Client runs on server hosting services • All nodes run an agent • Stays in sync, interface with REST and DHCP
  11. 11. CLIENT • Agent that forwards request to server • Mostly stateless • Client does LAN gossip (low traffic)
  12. 12. SERVER • Server also agent with more tasks • RAFT quorum, who is leader/master • Maintain cluster state • Handles WAN gossip to other datacenters • Forwards queries to leader/master • Forward queries to other datacenters
  13. 13. DATACENTER • Datacenter - obvious? • EC2 availability zone • Networking environment • Private, low latency, and high bandwidth • Fast between nodes, no hops, little routing, high speed
  14. 14. CONSENSUS • Agreement on who is the leader • Transactional finite state machine • Replicated Log, FSM, Peer Set (who gets the replicated log), Quorum (majority of peers agree), Committed Entry, Leader • End Result: Consistent view of configuration and live services
  15. 15. GOSSIP • Consul is built on top of Serf, • Serf is a full gossip protocol • Serf provides membership, failure detection, and event broadcast mechanisms • Clustering of server nodes
  16. 16. LAN,WAN,AND RPC • LAN Gossip - • LAN gossip pool, • all agent nodes (client and server) on same local network or datacenter • WAN Gossip - • WAN gossip pool • Only agent servers • Servers per datacenter (3 to 5 for redundancy per DC) • WAN gossip is used to communicate over public internet or wide area network • RPC - Remote Procedure Call. Request / response mechanism allowing a client to make a request of a server.
  17. 17. CONSUL Image from www.consul.io and property of HashiCorp
  18. 18. AGENT RESPONSIBILITIES • Maintains its • set of service • check registrations • health information • Updates • health checks • local state
  19. 19. CATALOG • Backs Consuls service discovery • Catalog is the service catalog • Aggregates information submitted by agents. • Maintains topology view of cluster,: • Services available, • Nodes which run those services (Node = Client Agent), • Health information, • Services and checks in catalog have less information than agent view • Catalog is maintained only by server nodes (server agents). • Catalog is replicated via Consul Consensus (RAFT, Serf)
  20. 20. AGENTSVS. CATALOG • Local agent state (agent client node) is different than catalog state (agent server node) • Local Agent notifies Catalog of changes. Updates are synced right away. • Agents check to make sure its view of the world matches the catalog, and if not the catalog is updated • Example: Registers a new service check with agent, • Agent notifies catalog that this service check exists • When a check is removed from the agent, it is removed from catalog
  21. 21. AGENTSVERSUS CATALOG 2 • If Agents run health checks, and status changes, then update is sent to catalog • Agent is the authority of that node, and the services that exist on that node • Scope • Agent = Server orVirtual Machine • Catalog = single datacenter, local area network, EC2 availability zone • Changes are also synchronized periodically every minute to ten minutes
  22. 22. CONSUL COMMAND LINE -server for server mode
  23. 23. STARTING UP A NEW SERVER • Expect min amount of servers for bootstrap $ consul agent -server -data-dir=“/opt/git/dc1" -bootstrap-expect 5
  24. 24. HTTP / JSON API ENDPOINTS • kv - key value • agent - api for dealing with agent • catalog - dealing with datacenter catalog • health - show health checks • sessions, events, acl, status, etc.
  25. 25. CONFIG FILES • config files can be stored locally and used to bootstrap config of consul
  26. 26. SERVICE DEFINITION Default check is dead man switch or tll
  27. 27. HEALTH CHECKS • Dead man switch, • time to live, you have to dial in with status update every X • HTTP ping every N time • HTTP Code 200 - 299 = PASS • HTTP Code 429 = WARN • anything else = FAIL • Run a script every N: • process 0 = pass, • process 1 = warn, • anything else = FAIL
  28. 28. SCRIPT CHECK
  29. 29. HTTP CHECK
  30. 30. DEAD MAN SWITCH CHECK
  31. 31. RPC PROTOCOL • All command line options available viaTCP/ MsgPack • MsgPack = binary JSON more or less
  32. 32. REGISTERING EXTERNAL SERVICES External registry plus HTTP health check = integration of service that has no idea that Consul exists = Legacy integration of services = service discovery for legacy services
  33. 33. WHAT WE HAVE DONE WITH CONSUL • wrote java microservices lib that uses consul for service discovery • Blog: Using Consul from QBit, the Java, JSON,WebSocket and REST microservice library, for health monitoring, clustering and service discovery • used consul to implement clustered, replicated event bus for qbit • Create general purpose service discovery that uses it • Used general purpose service discovery to build distributed/clustered stats service to implement things like client application id rate limiting at high- speeds
  34. 34. THANKYOU http://www.linkedin.com/in/ rickhigh/en

×