service discovery in distributed systems
TRANSCRIPT
![Page 1: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/1.jpg)
Service DiscoveryIn Distributed Systems
IVAN VOROSHILIN@vibneiro
![Page 2: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/2.jpg)
My Interests:
Ivan Voroshilin - Computer geek
Bio
Distributed systemsArchitectureFunctional languagesAlgorithms
![Page 3: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/3.jpg)
Service Discovery?Let’s recall
![Page 4: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/4.jpg)
OMG! This is an unmanageable mess!
Netflix
![Page 5: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/5.jpg)
Why?I don’t have to restart a service to update configuration
I don’t have to redeploy something, when a service is moved to another box
I don’t have to know whether a needed service is alive at the moment
Load-balancing might be taken care for you by Service Discovery also
Service Discovery takes a responsibility to store configs for you in 1 place
![Page 6: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/6.jpg)
Agenda
- Main properties of Service Discovery- Popular Open-Source Solutions Differences, Trade-offs- Bonus
![Page 7: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/7.jpg)
Service Discovery The main components
![Page 8: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/8.jpg)
The main idea of Service Discovery insimple terms
Announce/LookUp
Service Directory
Register Services
Discover Services
ConsistentHighly-available
a.k.a. Announce
a.k.a. LookUp
![Page 9: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/9.jpg)
CAP?Consistency Availability
Partition Tolerance
2 out of 3 properties: Either CP or AP.No other options
![Page 10: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/10.jpg)
Issues when developingService Discovery
Fault ToleranceData ConsistencyDistributed LocksLeader Election (It is not trivial!)
![Page 11: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/11.jpg)
Review of Open Source ProjectsProject Name Implementor Год рождения
Chubby Google 2006
ZooKeeper [*] Apache 2007
Doozerd Blake Mizerany 2010
My in-house solution Deutsche bank 2012
Eureka [*] Netflix 2012
ETCD [*] CoreOS 2013
SmartStack AirBnb 2013
Surf HashiCorp 2014
SkyDNS Erik St. Martin 2014
Consul [*] HashiCorp 2014
![Page 12: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/12.jpg)
Name resolution and DNS
Announce/Lookup?! Sounds like DNS..
- Scales out badly- Split-brain- Too simple
![Page 13: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/13.jpg)
Architectural trade-offsZookeeperETCDConsul
EurekaSmartStackSkyDNSSerf
![Page 14: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/14.jpg)
Service Discovery Open Source Solutions
![Page 15: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/15.jpg)
2 Categories of solutions
- General purpose solutions:ZooKeeper, ETCD- Solely Service Discovery solutions:Eureka, Surf, Consul
![Page 16: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/16.jpg)
Apache Zookeeper- Consensus protocol ZAB, CP- Written in Java- Language binding: Java and C API- Key-value store based on ephemeral nodes- Clients need to handle any load balancing or failover
themselves- On any non-quorum side, reads and writes will return an
error.
-
![Page 17: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/17.jpg)
Apache Zookeeper
In Hadoop, Mesos, Kafka, NetflixDistributed lock for coordination
- Heavyweight- Difficult to use- Not ideal for Service Discovery- Ephemeral nodes not reliable
![Page 18: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/18.jpg)
Netflix Eureka- Eventually consistent, AP- Broadcast async replication among servers, no quorum- HTTP-REST API- Written in Java- Java smart client with round robin balancer- Caching of server entries on the client side- add/remove nodes online- TTL refreshment mechanism- Used for AWS cloud
![Page 19: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/19.jpg)
ETCD- Inspired by Zookeeper- Consensus protocol - RAFT, CP- Written in Go- HTTP REST API- Key-value: Store data in directories- TTLs for keys expiration- Clients need to handle any load balancing or failover
themselves- Watch a key or directory for changes and react to the
new values
![Page 20: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/20.jpg)
Consul- Consensus protocol RAFT: CP- HTTP REST API or even DNS interface- Built-in DNS server as a service registry- Security: TLS, ACLs- Comprehensive solution for Service Discovery- Specialized health-checks, besides just heartbeats- Optional read consistency mode: stale
(when leader is unavailable)
![Page 21: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/21.jpg)
What should do a comprehensive Service Discovery?
Nothing from the mentioned answers the following question:
How to without a hassle to integrate your existing landscape with a service discovery solution?Doesn’t matter whether 3-party or in-house applications
What about closed 3-rd party systems?
Language binding?
Need to write client code to adapt?
![Page 22: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/22.jpg)
Service Discovery in Docker environmentMeet - “Side-kick” processes. (Introduced in SmartStack and Serf Solutions)
Client application
Backend 1 Backend 2
application
HAProxy
ETCD-cluster
service process
side-kick
service process
side-kick
discover
HTTP/TCP proxied HTTP/TCP proxied
announce announce
watchhealth checkTTL TTL
check health
![Page 23: Service Discovery in Distributed Systems](https://reader034.vdocuments.us/reader034/viewer/2022042716/55a686b11a28ab31138b4630/html5/thumbnails/23.jpg)
Summary
No One size fits all solutions
The right architecture or Open-Source solution directly depends on clear requirements