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.

Transcript

1. Service mesh для микросервисов Иван Круглов – 01.04.2018
3. Perl Java Go Python 5M main.git 4.5ГБ 7 мин
4. bare metal
5. монолит сервис сервис сервис сервис сервис сервис сервис сервис сервис сервис сервис
6. монолит сервис сервис сервис сервис сервис сервис сервис сервис сервис сервис сервис
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. …
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 • малые накладные расходы
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/