Service Discovery; or, Why each microservice should believe it's the only one in the world - by Richard Rodger

Post on 16-Apr-2017

4969 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

Transcript

Service Discovery or

Why each microservice should believe it's the only one in the world.

Richard Rodger @rjrodger

What are microservices?

๏ Small independent processes; ๏ Communicating via messages; ๏ A powerful component model.

Why use microservices?

๏ Avoid technical debt; ๏ Get continuous delivery; ๏ Build fast.

What are the trade-offs?

๏ Deployment is more complex; ๏ Weird programming model; ๏ Services have to find each other;

Configuration Files

๏ Hard code all the locations; ๏ Automate update and reloads; ๏ Surprisingly workable; ๏ But gets messy fast!

Intelligent Load Balancing

๏ The load balancer knows where services are; ๏ Services have to register in some way; ๏ Load balancers are yet more things to manage; ๏ URL paths are still identifiers! ๏ Examples: Netflix Eureka, nginx, HAProxy

Service Registries

๏ Services lookup locations; ๏ Registries can provide health checks; ๏ Registries themselves need to be distributed; ๏ Service A still knows about Service B! ๏ Examples: consul, etcd, zookeeper

DNS

๏ Hide services behind domain names; ๏ We know DNS can scale; ๏ More management work; ๏ Service A still knows about Service B! ๏ Examples: Mesos, Weave, SkyDNS

Message Bus

๏ Hide services behind topic names; ๏ Nice for publish/subscribe models! ๏ You have to manage the bus; ๏ Rapids, rivers and pools; ๏ Topics are weak identifiers - better! ๏ Examples: Kafka, Rabbitmq, Redis

Pattern Matching Service discovery is an anti-pattern. Instead, make messages first-class citizens. Use message data to define patterns, and these patterns define a language! Transport Independence Services should not know about each other, or how to send messages. Services are fully defined by: message patterns that they recognise, and message patterns that they emit.

Blind Messages

๏ Services have zero-knowledge of other services; ๏ Services emit messages into the world; ๏ Services let the world know what they care about;

๏ The underlying infrastructure handles identity; ๏ Works with any of the service discovery methods!

Peer-to-peer

๏ Knowledge of identity can be distributed; ๏ Each service maintains a local view of world,

and updates this view as services come and go; ๏ Mapping from message to destination is not

exposed to developers.

SWIM

๏ "Scalable Weakly-consistent Infection-style Process Group Membership Protocol" ๏ https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf

๏ Designed for large scale (used by Uber); ๏ Basic idea:

๏ each service pings a random subset of other services, different each time

๏ the pings establish health and disseminate membership information

// a search message { "role": "search", // a namespace "cmd": "search", // this is a command "query": "ldap", // some data } !// the pattern to match role:search,cmd:search

// some nodezoo message patterns !role:search,cmd:search // do a search role:search,cmd:insert // insert into index role:info,cmd:get // get module info role:npm,cmd:get // get npm data role:npm,info:change // module changed! role:info,req:part // need module info role:info,res:part // here's module info !!!

role:search,cmd:search

role:info,cmd:get

synchronous request/response

role:npm,info:change

asynchronous "winner-take-all" (actor)

role:info,req:part

asynchronous "fire-and-forget" (publish/subscribe)

role:info,res:part

asynchronous "fire-and-forget" (publish/subscribe)

synchronous request/response

asynchronous "winner-take-all" (actor)

synchronous "sidewinder" (side effects!)

synchronous/ asynchronous

consumed/ observed

// nodezoo-web IN: none OUT: role:search,cmd:search // sync role:info,cmd:get // sync

// nodezoo-search IN: role:search,cmd:search // sync role:search,cmd:insert // async OUT: none

service specification

// nodezoo-info IN: role:info,cmd:get // sync role:info,res:part // async OUT: role:info,req:part // async

// nodezoo-npm IN: role:npm,cmd:get // sync role:npm,info:change // async role:info,req:part // async OUT: role:info,res:part // async

service specification

// role:search,cmd:search consumed: nodezoo-web -> nodezoo-search

// role:info,cmd:get consumed: nodezoo-web -> nodezoo-info

// role:npm,info:change observed: nodezoo-update -> nodezoo-npm

service interactions

// role:info,req:part observed: nodezoo-info -> nodezoo-npm nodezoo-info -> nodezoo-github

// role:info,res:part observed: nodezoo-npm -> nodezoo-info nodezoo-github -> nodezoo-info

service interactions

senecajs.org

Code! github.com/rjrodger/nodezoo

Thanks!Richard Rodger

@rjrodger richardrodger.com

senecajs.org github.com/apparatus/fuge

top related