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

1. SOA: строим свой service mesh
Иван Круглов | 08.11.2017

3. Повестка дня
• Проблема
• Решения
• Практика эксплуатации
• Заключение

4. монолит

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

17. data
bus

18. RPC ≠ PC*
* PC – procedure call

19. RPC ≠ PC*
* PC – procedure call

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

21. transport transport
load balancingdiscovery
retrytimeouts
circuit breakerback-off
authtracing/monitoring
queue timeouts
chaos monkeyprioritization
rate limiting
service consumer service provider
client library server
auth
...

22. SOA: послать запрос на сервер? Что может быть проще?!
https://www.youtube.com/watch?v=WASm5325GQg
http://junior.highload.ru/2017/abstracts/2577.html

24. Perl
Java
Go
Python
5 млн
main.git
4.5ГБ
7 мин

25. bare metal

26. Решения

27. Подход №1: умная библиотека
• библиотеки:
• Perl: in-house
• Java: finagle, histryx, grpc
• Go: go-kit, grpc
• плюсы:
• понятно
• готовые решения
• минусы:
• различия в инструментах и подходах
• сложный апгрейд версий
• сложная интеграция со старым кодом
• опциональное использование
load balancingdiscovery
authtimeouts
circuit breakerretry
tracing/monitoringback-off

29. Подход №2: локальный прокси
• плюсы:
• решение для любого стека
• консистентное поведение
• контролируемый апгрейд
• хорошая интеграция со старым кодом
• минусы:
• накладные расходы
• сложный сетап
application
127.0.0.1
proxy

30. service mesh

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

32. • Java (based on Finagle)
• L7 proxy
• features:
• HTTP 1/2, gRPC
• ingress/egress
• load balancing
• retries and deadlines
• circuit breaker
• service discovery
• request routing
• dynamic configuration
• instrumentation
• C++
• L4/L7 proxy
• features:
• HTTP 1/2, gRPC
• ingress/egress
• load balancing
• retries and timeouts
• circuit breaker
• service discovery
• request routing
• dynamic configuration
• instrumentation
no graceful
restart
HTTP only
proxy

33. application provider
proxy proxy
service consumer service provider
control plane
data plane
control plane

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

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

36. application
envoy
provider
nginx
127.0.0.1:9211
GET / HTTP/1.1
Host: search.srv
route
discovery
cluster
discovery
server
discoverydomain: 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.srvHTTP/1.1 200 OK
HTTP/1.1 500
HTTP/1.1 200 OK
service consumer service provider
control plane
HTTPS

37. application
envoy
provider
nginx
127.0.0.1:9211
GET / HTTP/1.1
Host: search.srv
route
discovery
cluster
discovery
server
discoverydomain: 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.srvHTTP/1.1 200 OK
HTTP/1.1 200 OK
service consumer service provider
control plane
HTTPS

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

39. route
discovery
cluster
discovery
server
discovery
ZooKeeper
control plane
Kubernetes
envoy
REST API
5 сек

40. istio.io
• control plane от Google
• очень умная
• но сложная
• production ready до конца 2017
• интеграция с:
• envoy, linkerd, nginx (nginmesh)
Istio

41. Production

42. envoy: практика
• ~1000 серверов
• сложности:
• HTTP заголовки в нижнем регистре
• много метрик
• проверено:
• рестарт не обрывает соединения
• умершая «control plane» не влияет на коммуникации
• timeout/retry/backoff/circuit breaker работают

43. p50
p75 p90
p95
p99
HTTP
perceived latency
0ms
5ms
10ms
15ms
+ 1ms

44. HTTPS
perceived latency
p50
p75 p90
p95
p99
10ms
+ 1ms
15ms
20ms
25ms
30ms
40ms

45. HTTPS 2K RPS

46. Заключение
• положительный опыт c service mesh и envoy
• в середине пути
• унификация и наличие из коробки:
• управления трафиком
• механизмов надёжности
• мониторинга и трейсинга
• большие планы

47. Заключение (продолжение)
• уделяйте внимание взаимодействию сервисов
• retry, backoff, таумауты, клиентский мониторинг, трейсинг, chaos monkey, …
• go-kit, histryx, finagle, grpc – если:
• гомогенная инфраструктура
• небольшая компания
• сильная культура
• нужна высокая производительность
• прокси – если:
• крупная компания
• гетерогенный стек
• следите за Istio

48. А как делаете вы?

49. Спасибо!
Иван Круглов
ivan.kruglov@booking.com

50. Ссылки
https://www.envoyproxy.io
https://linkerd.io/
https://istio.io/
https://github.com/nginmesh/nginmesh
https://github.com/go-kit/kit
https://github.com/twitter/finagle
https://github.com/Netflix/Hystrix
https://grpc.io/
Acknowledgement:
Peter Bourgon for the idea of monoliths -> SOA -> microservices slides.