Вадим Мадисон "Опыт разработки через микросервисы"
•
0 likes•417 views
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять. Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт. В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Вадим Мадисон "Опыт разработки через микросервисы"
Similar to Вадим Мадисон "Опыт разработки через микросервисы" (20)
More from Tanya Denisyuk
More from Tanya Denisyuk (13)
Вадим Мадисон "Опыт разработки через микросервисы"
- 2. • Услуги системной интеграции, начиная от разработки технологических решений и заканчивая доставкой видео-сигнала до конечного пользователя • Интернет-видеоплатформа для каналов МатчТВ и НТВ-ПЛЮС • 300 000 одновременных пользователей • > 1 000 000 уникальных посетителей в сутки • Отдаем контента до 300 Тб/час
- 4. Кривая Гартнера Появление технологии Ажиотаж (завышенные ожидания)
- 5. Кривая Гартнера Появление технологии Ажиотаж (завышенные ожидания) Разочарование
- 6. Кривая Гартнера Появление технологии Ажиотаж (завышенные ожидания) Разочарование Осмысление
- 7. Кривая Гартнера Появление технологии Ажиотаж (завышенные ожидания) Разочарование Осмысление Развитие
- 8. Минусы микросервисов • Распределенные коммуникации, дополнительное API, больше точек отказа и логики их обработки • Оверхед: сетевой, сериализация/десериализация • Обнаружение сервисов • Инструментарий!
- 10. Плюсы микросервисов • Независимая разработка • Лучший контроль технического и технологического долга • Скорость тестирования, доставки, запуска • Упрощение масштабирования
- 11. Когда микросервисы не нужны / вредны? • Небольшой проект • Сжатые сроки разработки • Короткий цикл поддержки • Отсутствие CI / CD • Нет команды, отвечающей за инфраструктуру • Высокие требования к эффективности
- 12. Когда микросервисы “must have”? • Большой проект • Высокие нагрузки • Долгий цикл разработки • Длительный период жизни и поддержки • Высокие требования к использованию оптимальных технологий • Готовы к исследованиям, оптимизациям и новым технологиям
- 14. Сервис должен быть независимым!
- 15. Сервис независим если… • Возможно описать бизнес-задачу сервиса одним простым предложением • У сервиса больше одного потребителя • Деплой сервиса не приводит к деплою других сервисов
- 16. Сервис независим если… • Возможно описать бизнес-задачу сервиса одним простым предложением • У сервиса больше одного потребителя • Деплой сервиса не приводит к деплою других сервисов
- 17. Сервис независим если… • Возможно описать бизнес-задачу сервиса одним простым предложением • У сервиса больше одного потребителя • Деплой сервиса не приводит к деплою других сервисов
- 19. Общие рекомендации • Не использовать фреймворки • Собирать проект из шаблона • Не бояться “copy-paste” • Обратить внимание на манифест “12-факторное приложение”
- 20. Общие рекомендации • Не использовать фреймворки • Собирать проект из шаблона • Не бояться “copy-paste” • Обратить внимание на манифест “12-факторное приложение”
- 21. Общие рекомендации • Не использовать фреймворки • Собирать проект из шаблона • Не бояться “copy-paste” • Обратить внимание на манифест “12-факторное приложение”
- 22. Общие рекомендации • Не использовать фреймворки • Собирать проект из шаблона • Не бояться “copy-paste” • Обратить внимание на манифест “12-факторное приложение” https://12factor.net/ru/
- 23. Конфигурация
- 24. Конфигурация Что пробовали? • файлы конфигурации при деплое разливать по всем целевым машинам • файлы конфигурации класть в контейнер • выставлять переменные окружения • при сборке контейнера (ENV DB=…) • при запуске контейнера
- 25. Конфигурация Что пробовали? • файлы конфигурации при деплое разливать по всем целевым машинам • файлы конфигурации класть в контейнер • выставлять переменные окружения • при сборке контейнера (ENV DB=…) • при запуске контейнера
- 26. Конфигурация Что пробовали? • файлы конфигурации при деплое разливать по всем целевым машинам • файлы конфигурации класть в контейнер • выставлять переменные окружения • при сборке контейнера (ENV DB=…) • при запуске контейнера
- 27. Конфигурация ! Единая точка конфигурирования " Но не единая точка отказа! ! Проверенные решения…
- 29. <СЕРВИС>/ (/conf/ms/recorder/) <СЕРВИС>/<ВЕРСИЯ>/ (/conf/ms/recorder/0.12) <СЕРВИС>/<СРЕДА>/ (dev, stage, production) Кофигурация к KV
- 30. <СЕРВИС>/ (/conf/ms/recorder/) <СЕРВИС>/<ВЕРСИЯ>/ (/conf/ms/recorder/0.12) <СЕРВИС>/<СРЕДА>/ (dev, stage, production) /conf/ms/recorder/production/db : "recorder" /conf/ms/recorder/production/server : "10.0.102.2" Кофигурация к KV
- 31. <СЕРВИС>/ (/conf/ms/recorder/) <СЕРВИС>/<ВЕРСИЯ>/ (/conf/ms/recorder/0.12) <СЕРВИС>/<СРЕДА>/ (dev, stage, production) /conf/ms/recorder/0.12/production/db : "recorder" /conf/ms/recorder/0.12/production/server : "10.0.0.12" Кофигурация к KV
- 32. Конфигурация 1. git2consul • не используем отдельные проекты/бранчи в git для основных параметров • загружаем конфигурацию при деплое • стартовый путь: /conf/ms/<ИМЯ СЕРВИСА>/<BUILD NO>/ 2. Vault все секретное храним в отдельных проектах
- 33. Журналирование • Единый формат логов, сведение в общее хранилище
- 34. Журналирование
- 35. Health-check ! HTTP / HTTPS ! 2 основных метода /ready /health ! 1 опциональный /info
- 36. Health-check
- 37. Тестирование
- 38. В чем сложность? • Корректность взаимодействия с другими сервисами • Сервис назначения доступен, но: • Отвечает очень медленно • Отвечает эпизодически • Отвечает некорректно
- 39. В чем сложность? • Корректность взаимодействия с другими сервисами • Сервис назначения доступен, но: • Отвечает очень медленно • Отвечает эпизодически • Отвечает некорректно
- 40. В чем сложность? • Корректность взаимодействия с другими сервисами • Сервис назначения доступен, но: • Отвечает очень медленно • Отвечает эпизодически • Отвечает некорректно Circuit Breaker! [Hystrix, Netflix]
- 41. В чем сложность? • Корректность взаимодействия с другими сервисами • Сервис назначения доступен, но: • Отвечает очень медленно • Отвечает эпизодически • Отвечает некорректно Circuit Breaker! [Hystrix, Netflix]
- 43. Хранение
- 44. Что пробовали? • Проброс файловой системы в контейнер
- 45. Что пробовали? • Проброс файловой системы в контейнер • «Собирающие контейнеры»
- 46. Что пробовали? • Проброс файловой системы в контейнер • «Собирающие контейнеры» • Shared data volume
- 47. Что пробовали? • Проброс файловой системы в контейнер • «Собирающие контейнеры» • Shared data volume • Flocker
- 48. Для файлового хранения Распределенная файловая система: CEPH (http://ceph.com/)
- 49. Для БД • Выделенные сервера • Особая конфигурация машин • Расширенная сеть
- 50. Оркестрация
- 51. Оркестрация
- 52. Оркестрация
- 53. Оркестрация
- 54. Consul Template {{range services}}{{ if in .Tags "demo" }}{{if .Tags | join "," | regexMatch "urlprefix-"}} upstream {{.Name}} { least_conn; {{range service .Name}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=30 weight=1;{{end}} } {{end}}{{end}}{{end}} server { listen 80 default_server; location /health { add_header Content-Type text/plain; return 200 'OK'; } {{range services}}{{ if in .Tags "demo" }}{{if .Tags | join "," | regexMatch "urlprefix-"}} {{range .Tags}}{{ if . | contains "urlprefix-" }}location {{. | replaceAll "urlprefix-" ""}} { {{end}}{{end}} proxy_pass http://{{.Name}}/; # / в конце означает обрезку проксируемого пути proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } {{end}}{{end}}{{end}} }
- 55. Consul Template {{range services}} {{ if in .Tags "demo" }} {{if .Tags | join "," | regexMatch “urlprefix-“}} #urlprefix-/playlist upstream {{.Name}} { least_conn; {{range service .Name}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=30 weight=1;{{end}} } {{end}} {{end}} {{end}} в списке только прошедшие health-check!
- 56. Consul Template {{range services}} {{ if in .Tags "demo" }} {{if .Tags | join "," | regexMatch "urlprefix-"}} {{range .Tags}}{{ if . | contains "urlprefix-" }} # Tag: urlprefix-/playlist location {{. | replaceAll "urlprefix-" ""}} { {{end}}{{end}} proxy_pass http://{{.Name}}/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } {{end}}{{end}}{{end}}
- 57. Consul Template upstream playlistapi { least_conn; server 10.1.1.2:5100 max_fails=3 fail_timeout=30 weight=1; } ... location /playlist { proxy_pass http://playlistapi/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }
- 59. Чек-лист Как конфигурировать? Как мониторить и считать метрики? Как сервисы будут находить друг друга? Как сервис будет взаимодействовать с остальными частями проекта? Как тестировать сервис и систему целиком? Как обрабатывать сбои связанных сервисов? Как переезжать на новую версию? Как масштабировать под нагрузкой?