Микросервисная архитектура на базе CoreOS и Kubernetes
4 likes1,910 views
Документ освещает микросервисную архитектуру и её преимущественные характеристики по сравнению с монолитной архитектурой, включая устойчивость, скорость поставки и гибкость изменений. Также описывается процесс масштабирования, использование Docker и CoreOS, а также интеграция с Kubernetes для оптимизации разработки и развертывания приложений. В заключение, документ подчеркивает важность автоматизации процессов развертывания и мониторинга производительности.
![Z-Axis Scaling
36
Load
Balancer
[A - I]
[J - R]
[S - Z]
/catalog/*
/catalog/*
/catalog/*
Разделение
данных](https://image.slidesharecdn.com/random-160714172208/85/CoreOS-Kubernetes-36-320.jpg)
Микросервисная архитектура на базе CoreOS и Kubernetes
- 1. Микросервисная архитектура на базе CoreOS и Kubernetes Денис Измайлов 13 июля 2016
- 2. Денис Измайлов • 16 лет опыта разработки ПО и web • Последние 6 лет посвятил Front-end, Node.js и архитектуре • Более 15 проектов SPA, React.js и high- load • Коммиты в Redux, webpack и koa • Спикер HighLoad++ 2015, AgileDays 2016, RIT 2016, DevConf 2016, MoscowJS, React Amsterdam Meetup • Статьи на Habrahabr и Medium • Два года назад основал Startup Makers
- 3. • Мы делаем web, мобильные приложения и DevOps для наших клиентов • Мы используем самые передовые и эффективные технологии • Более 20 талантливых разработчиков
- 4. Микросервисы
- 5. “Microservices allow engineering teams to move quickly to grow a product… assuming they don’t get bogged down by the complexity of operating a distributed system”
- 7. Микросервисы создают новый уровень проблем
- 8. Так ли это?
- 11. Хрупкость Если падает, то падает всё
- 12. Хрупкость Если падает, то падает всё С учётом высокой связанности, падает всё часто
- 13. Низкая скорость поставки Тяжелые процессы сборки и запуск Необходимость выкатывать всё даже при небольших изменениях
- 14. Ментальная сложность изменений • Slow IDE • Ментальная нагрузка • Высокая ответственность каждого • Что я не должен делать? • Высокие риски провала
- 16. Типичный монолит - человечное тело
- 17. Организационная сложность Необходимость согласований и координации Затягивание сроков
- 18. Дорогой технологический стэк • Мы не можем его менять • Необходимо брать с запасом, а это all-in-one и дорого • Небольшой выбор средств • Vendor lock-in
- 20. Монолитная архитектура • Хрупкость • Низкая скорость доставки • Ментальная сложность изменений • Организационная сложность • Дорогой технологический стук • Медленно. Дорого. Высокие риски.
- 23. Устойчивость Если падает один сервис, система продолжает работать Fail-over. Сервисы взаимозаменяемы. Переключение.
- 24. Высокая скорость поставки Быстрая сборка и запуск Разработка и независимые выкатка сервисов Прогрессивное обновление UI
- 25. Ментальная легкость изменений • Изолированность сервиса • Низкие риски провала • Точечные изменения • Fast IDE • Rollback
- 26. Свободный технологический стэк • Agile Way • Оптимальный для каждого сервиса инструмент • Подходящий под экспертизу команды и каждого разработчика • Open-Source Software • SaaS
- 28. Микросервисная архитектура • Устойчивость • Высокая скорость поставки • Ментальная легкость изменений • Свободный технологический стэк • Быстро. Надёжно. Эффективно.
- 30. The Art Of Scalability
- 31. Scale Cube 31 Monolith Infinite Scaling Y axis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
- 32. The Scale Cube • X - добавление новых копий приложения • Y - разделение приложение на сервисы • Z - разделение данных или ресурсов (например, для платных пользователей)
- 35. • За какую функцию отвечает? Что делает? - управление формами, отправка e-mail, мониторинг • С какими данными работает? Кем используется? - пользовательский UI, менеджеры, отдел поддержки • Комбинированный способ • Single Responsibility Principle Y-Axis Scaling
- 36. Z-Axis Scaling 36 Load Balancer [A - I] [J - R] [S - Z] /catalog/* /catalog/* /catalog/* Разделение данных
- 38. Scale Cube 38 Monolith Infinite Scaling Y axis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
- 39. - OK, Google. Как с этим двигаться?
- 40. Процесс роста • Новая версия - новый сервис •
- 41. Новая версия - новый сервис Blue-Green Deployment
- 42. Процесс роста • Новая версия - новый сервис • Effortless data model versioning for Javascript and Node.js https://github.com/TechnologyAdvice/ Vers
- 44. Процесс роста • Новая версия - новый сервис • Effortless data model versioning for Javascript and Node.js https://github.com/TechnologyAdvice/ Vers • GraphQL
- 45. GraphQL
- 47. Scale Cube 47 Monolith Infinite Scaling Y axis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
- 48. - С чего начать?
- 49. Разбиваем монолит 1. Сборка и поставка сервисов 2. Взаимодействие сервисов 3. Масштабирование
- 51. Платформа Docker
- 52. Docker allows you to package an application with all of its dependencies into a standardized unit for software development.
- 53. Build Приложение + Зависимости = Image
- 54. Run 1. Image via LXC 2. Network 3. Environment
- 55. Dockerfile
- 56. Dockerfile
- 59. Docker Image
- 60. Docker Image • Запускается в отдельном контейнере • Иногда - ещё и Volumes • Взаимодействует с другими контейнерами через сетевой интерфейс
- 62. Микросервисное взаимодействие • RESTful API, JSON API • OAuth, JWT • AMQ, WebSocket, JSON RPC, WAMP, etc • API Based Collaboration • Database
- 63. Масштабирование
- 65. CoreOS • Скоро будет 3 года • Мини-дистрибутив на базе Chrome OS • Нет пакетного менеджера • Все приложения - через Docker • Cloud Config • Автоматические обновления • Инфраструктура для кластеров
- 66. CoreOS • Etcd • Fleet • Flannel
- 67. Etcd • Распределённое key-value хранилище • Назначение: • Общая конфигурация • Service Discovery • Блокировка ресурсов
- 68. Etcd
- 69. Fleet • Распределённый systemd • Набор Unit-файлов • Назначение: • Запуск Docker-контейнеров • Распределение их в кластере • Планирование запуска
- 70. Fleet - планирование • Global (можно запускать в любом месте кластера) • MachineMetadata (только на определённых машинах) • Conflicts (для избежания конфликта с коллоцированием) • MachineOf (запускать только там, где запущены определённые Unit)
- 72. Fleet
- 73. Fleet
- 74. Как Load Balancer узнает про адрес и порт контейнеров?
- 75. Service Discovery • Fleet Unit • MachineOf • Определяет IP и порт целевого контейнера • Записывает в etcd • Через 5 секунд повторяет • = Sidekick Pattern
- 76. Service Discovery • Fleet Unit • MachineOf • Определяет IP и порт целевого контейнера • Записывает в etcd • Через 5 секунд повторяет • = Sidekick Pattern
- 78. Как объединить Docker- контейнеры в одну сеть?
- 79. Flannel
- 80. CoreOS • Etcd - распределённое хранилище данных
- 81. CoreOS • Etcd - распределённое хранилище данных • Fleet - распределённый запуск
- 82. CoreOS • Etcd - распределённое хранилище данных • Fleet - распределённый запуск • Flannel - виртуальная сеть
- 83. CoreOS
- 86. Реальный проект • Несколько сервисов (Y) • Сервис + Service Discovery • Несколько экземпляров (X) • Несколько окружений: dev, stage, production
- 87. Реальный проект Несколько сервисов (Y) Сервис + Service Discovery Несколько экземпляров (X) Несколько окружений: dev, stage, production 3 2 6 3
- 88. Реальный проект 3 2 6 3 = 108 контейнеров х x x
- 91. Kubernetes • Следующий уровень абстракции • Pods - группы контейнеров • Labels - тэги для идентификации Pods • ReplicationController - количество копий • Deployment - roll-out, roll-back, BGD • cAdvisor - анализ производительности и потребления ресурсов контейнеров • UI и прочее - про это всё в следующий раз
- 93. Stay tuned
- 94. О чём не рассказал?
- 96. Concourse CI
- 97. Resource Type
- 98. Resource
- 99. Resource
- 100. Concourse Pipeline
- 101. www.concourse.ci
- 102. Мониторинг производительности и ошибок
- 103. Уведомления при недоступности сервисов • Интеграционные тесты • Synthetic monitoring • Отправка E-mail и SMS
- 104. Логирование и агрегация логов
- 105. DC/OS
- 106. Мы рассмотрели • Монолитная архитектура • Микросервисная архитектура • Модель Scale Cube • Docker • CoreOS • Kubernetes • Concourse CI
- 110. Полезные ссылки • http://www.reactivemanifesto.org/ • http://12factor.net/ • https://www.infoq.com/articles/seven-uservices- antipatterns • https://www.quora.com/In-the-future-of-data-center- architecture-who-will-be-the-main-orchestrator- controller-of-containers-Mesos-or-Kubernetes-What- will-be-the-division-of-responsibilities