Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Four Times Microservices: REST, Kubernetes, UI ...

Eberhard Wolff
September 21, 2017

Four Times Microservices: REST, Kubernetes, UI Integration, Aync

How you can build microservices:
- REST with the Netflix stack (Eureka for Service Discovery, Ribbon for Load Balancing, Hystrix for Resilience, Zuul for Routing)
- REST with Consul for Services Discovery
- REST with Kubernetes
- UI integration with ESI (Edge Side Includes)
- UI integration on the client with JavaScript
- Async with Apache Kafka
- Async with HTTP + Atom

Eberhard Wolff

September 21, 2017
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

Transcript

  1. What are Microservices? > Independent Continuous Delivery Pipeline including tests

    > Standardized Operations (configuration, log analysis, tracing, monitoring, deployment) > Resilient (compensate failure, crashes …) therefore separate processes, VM, Docker containers
  2. Synchronous Microservices > Service Discovery: IP / port? > Load

    Balancing: Resilience and independent scaling > Routing: Route external request to microservices > Resilience
  3. Why Eureka for Service Discovery? > REST based service registry

    > Supports replication > Caches on the client > Resilient > Fast > Foundation for other services
  4. Eureka Client > @EnableDiscoveryClient: generic > @EnableEurekaClient: specific > Dependency

    on spring-cloud-starter-eureka > Automatically registers application
  5. Eureka Server @EnableEurekaServer @EnableAutoConfiguration public class EurekaApplication { public static

    void main(String[] args) { SpringApplication.run(EurekaApplication.class, args); } } Add dependency to spring-cloud-starter-eureka-server
  6. Client Ribbon: Client Side Load Balancing > Decentralized Load Balancing

    > No bottle neck > Resilient Load Balancer Server
  7. Ribbon Example private LoadBalancerClient loadBalancer; … ServiceInstance instance = loadBalancer.choose("CATALOG");

    String url = "http://" + instance.getHost() + ":” + instance.getPort() + "/catalog/"; Via Dependency Injection Eureka name Need dependency to spring-cloud-starter-ribbon
  8. Timeout > Do call in other thread pool > Won’t

    block request handler > Can implement timeout
  9. Circuit Breaker > Called system fails -> open > Open

    -> do not forward call > Forward calls after a time window
  10. Hystrix & Spring Cloud > Annotation based approach > Annotations

    of javanica libraries > Simplifies Hystrix > No commands
  11. @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public class OrderApp { public static void

    main(String[] args) { SpringApplication.run(OrderApp.class, args); } } Enable Hystrix Need spring-cloud-starter-hystrix
  12. @HystrixCommand(fallbackMethod = "getItemsCache", commandProperties = { @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value

    = "2") } ) public Collection<Item> findAll() { … this.itemsCache = pagedResources.getContent(); return itemsCache; } private Collection<Item> getItemsCache() { return itemsCache; } Fallback
  13. Routing > One URL to the outside > Internal: Many

    Microservices > REST > Or HTML GUI > Hides internal structure (sort of) > Might add filters
  14. Customer Order Catalog Zuul Proxy Automatically maps route to server

    registered on Eureka i.e. /customer/** to CUSTOMER No configuration
  15. Netflix Stack > Service Discovery: Eureka > Load Balancing: Ribbon

    > Routing: Zuul > Resilience: Hystrix > Non-Java microservice: specific clients or sidecar
  16. Consul > Service Discovery by Hashicorp > DNS interface >

    Platform independent > Consul Template can fill out config file templates > e.g. for load balancer > …unaware of service discovery
  17. Kubernetes > Docker container on a single machine: Not resilient

    enough > Kubernetes: Run Docker container in cluster > …and much more!
  18. Pods > Kubernetes runs Pods > Pods = 1..n Docker

    containers > Shared volumes > …and ports
  19. Replica Sets > Deployment creates replica set > Replica sets

    ensure that a certain number of Pods run > ...for load balancing / fail over
  20. Services > Services ensure access to the Pods > DNS

    entry > Cluster-wide unique IP address for internal access > Node port … > … or external load balancer for external access
  21. Load Balancer Kubernetes Cluster Server Service 1 Service 2 Kubernetes

    Cluster Server Service 1 Service 2 Service adds a load balancer Load Balancer (e.g. Amazon Elastic Load Balancer)
  22. Kubernetes > Service Discovery: DNS > Load Balancing: IP >

    Routing: Load Balancer or Node Port > Resilience: Hystrix? envoy proxy? > Can use any language
  23. UI Integration > Very powerful > Often overlooked > UI

    should be part of a microservices > Self-contained System emphasize UI > http://scs-architecture.org/
  24. UI Integration > Extremely decoupled > Here is a link:

    http://ewolff.com > No need to know anything else about the system > What about more complex transclusion?
  25. Server-side Integration: Technologies > ESI (Edge Side Include) > E.g.

    Varnish cache > SSI (Server Side Include) > E.g. Apache httpd, Nginx
  26. ESI (Edge Side Includes) ... <header> ... Logged in as:

    Ada Lovelace ... </header> ... <div> ... a lot of static content and images ... </div> ... <div> some dynamic content </div>
  27. ESI (Edge Side Includes) ... <esi:include src="http://example.com/header" /> ... <div>

    ... a lot of static content and images ... </div> ... <esi:include src="http://example.com/dynamic" /> http://www.w3.org/TR/esi-lang
  28. Client-side Integration: Code $("a.embeddable").each(function(i, link) { $("<div />").load(link.href, function(data, status,

    xhr) { $(link).replaceWith(this); }); }); Replace <a href= " " class= "embeddable"> with content of document in a <div> (jQuery)
  29. Asynchronous > Do not talk to other microservices > ...and

    wait for a reply > …while processing a request. > Either don‘t wait for a reply > ...or don‘t communicate while processing a request.
  30. Asynchronous: Benefits > Deals with unreliable systems > Can guarantee

    delivery > Good fit for events > …and Bounded Context / DDD
  31. Kafka Records > Key > Value > Timestamp > No

    headers > Stored forever (!) Record Key Value Timestamp
  32. Kafka Topics > Named > Topics have partitions > Order

    guaranteed per partition > Consumer commits offset per partition > Consumer group: One consumer per partition Topic Partition Record Record Record
  33. Topic Partition Record Record Record Producer Offset Offset committed per

    consumer Offset Partition Record Record Record Partition Record Record Record
  34. Log Compaction > Remove all but the latest record with

    a given key > Idea: Old events not relevant > …if new events override > Efficient storage in the long run Partition Record id=42 Record id=23 Record id=42
  35. Asynchronous Microservices > Service Discovery: via topic > Load Balancing:

    via partitions / consumer groups > Routing: ./. > Resilience service fails – latency increases
  36. Kafka Conclusion > Provides access to old events > Guaranteed

    order per key > (Log compaction also per key) > Consumer groups send records to one consumer > Additional (complex) infrastructure
  37. Atom > Data format > …for feeds, blogs, podcasts etc

    > Access through HTTP > Idea: Provide a feeds of events / orders
  38. <feed xmlns="http://www.w3.org/2005/Atom"> <title>Order</title> <link rel="self" href="http://localhost:8080/feed" /> <author><name>Big Money Inc.</name>

    </author> <subtitle>List of all orders</subtitle> <id>https://github.com/ewolff/microservice- atom/order</id> <updated>2017-04-20T15:28:50Z</updated> <entry> ... </entry> </feed>
  39. Atom Feed > Some unneeded information > …but not a

    lot > Mostly links to details > ...and timestamps > Can use content negotiation to provide different data formats or details
  40. Subscribing to Feed > Poll the feed (HTTP GET) >

    Client decides when to process new events > …but very inefficient > Lots of unchanged data
  41. HTTP Caching > Client GETs feed > Server send data

    > + Last-Modified header > Client sends get > + If-Modified-Since header > Server: 304 (Not modified) > …or new data
  42. Atom > Service Discovery: REST > Load Balancing: REST >

    Routing: ./. > Resilience failures just increase latency
  43. Atom Conclusion > Can provides access to old events if

    they are stored anyway. > One consumer: idempotency > No additional infrastructure
  44. Conclusion: Communication > Netflix: Java focus, code dependencies > Kubernetes:

    No code dependencies > UI Integration: more decoupling > Asynchronous deals with challenges in distributed systems
  45. Links > List of microservices demos (sync, async, UI): http://ewolff.com/microservices-demos.html

    > REST vs. Messaging for Microservices https://www.slideshare.net/ewolff/rest-vs- messaging-for-microservices
  46. EMail [email protected] to get: Slides + Microservices Primer + Sample

    Microservices Book + Sample of Continuous Delivery Book Powered by Amazon Lambda & Microservices