CodeFst 2018. Иван Круглов (Booking.com) — Service mesh для микросервисов

16b6c87229eaf58768d25ed7b2bbbf52?s=47 CodeFest
April 09, 2018

CodeFst 2018. Иван Круглов (Booking.com) — Service mesh для микросервисов

Посмотрите выступление Ивана: https://2018.codefest.ru/lecture/1299/

Service mesh - это выделенный слой в инфраструктуре компании, который призван упростить взаимодействие между сервисами, а также сделать его надежным и безопасным. В юрисдикцию service mesh, по разным мнениям, входят: маршрутизация запросов, service discovery, балансировка, обработка ошибок, мониторинг, трейсинг, авторизация и аутентификация и др. вещи. Реализация тоже варьируется от размазывания функционала по всему стеку до концентрации большей части его в одной точке. В своем докладе я бы хотел затронуть тему построения service mesh на примере Booking.com в контексте перехода от монолитной к сервис-ориентированной архитектуре. Мы погрузимся в детали некоторых компонентов и рассмотрим примеры решений удачных и не очень. Также затронем опыт внедрения и эксплуатации L7 proxy envoy и linkerd.

16b6c87229eaf58768d25ed7b2bbbf52?s=128

CodeFest

April 09, 2018
Tweet

Transcript

  1. Service mesh для микросервисов Иван Круглов – 01.04.2018

  2. None
  3. Perl Java Go Python 5M main.git 4.5ГБ 7 мин

  4. bare metal

  5. монолит сервис сервис сервис сервис сервис сервис сервис сервис сервис

    сервис сервис
  6. монолит сервис сервис сервис сервис сервис сервис сервис сервис сервис

    сервис сервис
  7. None
  8. None
  9. RPC ≠ PC* * PC – procedure call

  10. RPC ≠ PC* * PC – procedure call

  11. application transport transport provider client library server service consumer service

    provider
  12. transport transport load balancing discovery retry timeouts circuit breaker back-off

    auth tracing/monitoring queue timeouts chaos monkey prioritization rate limiting service consumer service provider client library server auth ...
  13. Решения

  14. Подход №1: умная библиотека • библиотеки: • Java: finagle, histryx,

    grpc, … • Go: go-kit, grpc, … • Perl: in-house • плюсы: • понятно • готовые решения • минусы: • различия в инструментах и подходах • сложный апгрейд версий • сложная интеграция со старым кодом • опциональное использование load balancing discovery auth timeouts circuit breaker retry tracing/monitoring back-off
  15. Подход №2: локальный прокси • плюсы: • решение для любого

    стека • консистентное поведение • контролируемый апгрейд • интеграция со старым кодом • минусы: • накладные расходы • сложный сетап application 127.0.0.1 proxy
  16. умная библиотека прокси load balancing discovery auth timeouts circuit breaker

    retry tracing/monitoring back-off application 127.0.0.1 HTTP proxy application
  17. service mesh service mesh

  18. tl;dr: A service mesh is a dedicated infrastructure layer for

    making service-to-service communication safe, fast, and reliable. If you’re building a cloud native application, you need a service mesh. https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ Service Mesh is a network communication infrastructure which allows your to decouple and offload most of the application network functions from your service code. https://medium.com/microservices-in-practice/service-mesh-vs-api-gateway-a6d814b9bf56 A network for services, not bytes https://istio.io/talks/istio_talk_gluecon_2017.pdf
  19. application provider proxy proxy service consumer service provider control plane

    data plane control plane 1. routing policy 2. failure handling policy 3. server discovery 4. …
  20. application provider proxy proxy service consumer service provider control plane

    data plane control plane 1. routing policy 2. failure handling policy 3. server discovery 4. …
  21. None
  22. application provider proxy proxy service consumer service provider control plane

    data plane control plane
  23. Istio

  24. service mesh service mesh @ Booking.com

  25. application provider proxy proxy service consumer service provider control plane

    data plane control plane
  26. Почему прокси для Booking.com? • большая компания • гетерогенный стек

    • много legacy
  27. application provider proxy proxy service consumer service provider control plane

    data plane control plane
  28. application provider proxy nginx service consumer service provider control plane

    data plane control plane
  29. application provider proxy nginx service consumer service provider control plane

    data plane control plane
  30. application provider envoy nginx service consumer service provider control plane

    data plane control plane
  31. application provider envoy nginx service consumer service provider control plane

    data plane control plane
  32. application envoy provider nginx 127.0.0.1:9211 GET / HTTP/1.1 Host: search.srv

    route discovery cluster discovery server discovery domain: search.srv cluster: search.srv.ams timeout_ms: 2000 retry_on: 5xx max_retries: 3 cluster: search.srv.ams lb_type: random connect_timeout_ms: 500 cluster: search.srv.ams hosts: [ 10.1.1.1:443, 10.1.1.2:443 ] GET / HTTP/1.1 Host: search.srv HTTP/1.1 200 OK HTTP/1.1 500 HTTP/1.1 200 OK service consumer service provider control plane HTTPS
  33. application envoy provider nginx 127.0.0.1:9211 GET / HTTP/1.1 Host: search.srv

    route discovery cluster discovery server discovery domain: search.srv cluster: search.srv.ams timeout_ms: 2000 retry_on: 5xx max_retries: 3 cluster: search.srv.ams lb_type: random connect_timeout_ms: 500 cluster: search.srv.ams hosts: [ 10.1.1.1:443, 10.1.1.2:443 ] GET / HTTP/1.1 Host: search.srv HTTP/1.1 200 OK HTTP/1.1 200 OK service consumer service provider control plane HTTPS
  34. application provider envoy nginx service consumer service provider control plane

    data plane control plane
  35. route discovery cluster discovery server discovery ZooKeeper control plane Kubernetes

    envoy REST API 5 сек
  36. Production

  37. Практика использования • ~ 6 месяцев в бою • ~

    20 проектов • ~ 2000 cерверов • ~ сотни тысяч RPS • контроль трафика • кардинальное снижение уровня ошибок • observability • малые накладные расходы
  38. None
  39. p50 p75 p90 p95 p99 HTTP perceived latency 0ms 5ms

    10ms 15ms + 1ms
  40. HTTPS perceived latency p50 p75 p90 p95 p99 10ms +

    1ms 15ms 20ms 25ms 30ms 40ms
  41. Заключение • положительный опыт c service mesh и envoy •

    в середине пути • унификация и наличие из коробки: • управления трафиком • механизмов надёжности • мониторинга и трейсинга • большие планы • перевод всего HTTP(S) трафика • в перспективе MySQL, Redis, Kafka и др.
  42. Нужен ли мне service mesh? • крупный проект • много

    компонентов • сложная структура владения • гетерогенный стек
  43. Спасибо! Иван Круглов ivan.kruglov@booking.com

  44. Ссылки • https://envoyproxy.io/ • https://linkerd.io/ • https://conduit.io/ • https://istio.io/