Download as PDF, PPTX
![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)
Uploaded byDenis Izmaylov
Микросервисная архитектура на базе CoreOS и Kubernetes
Документ освещает микросервисную архитектуру и её преимущественные характеристики по сравнению с монолитной архитектурой, включая устойчивость, скорость поставки и гибкость изменений. Также описывается процесс масштабирования, использование Docker и CoreOS, а также интеграция с Kubernetes для оптимизации разработки и развертывания приложений. В заключение, документ подчеркивает важность автоматизации процессов развертывания и мониторинга производительности.
More Related Content
Микросервисная архитектура на базе 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 engineeringteams to move quickly to grow a product… assuming they don’t get bogged down by the complexity of operating a distributed system”
- 6.
- 7.
- 8.
- 9.
- 11. Хрупкость Если падает, топадает всё
- 12. Хрупкость Если падает, топадает всё С учётом высокой связанности, падает всё часто
- 13. Низкая скорость поставки Тяжелыепроцессы сборки и запуск Необходимость выкатывать всё даже при небольших изменениях
- 14. Ментальная сложность изменений •Slow IDE • Ментальная нагрузка • Высокая ответственность каждого • Что я не должен делать? • Высокие риски провала
- 15.
- 16.
- 17. Организационная сложность Необходимость согласованийи координации Затягивание сроков
- 18. Дорогой технологический стэк •Мы не можем его менять • Необходимо брать с запасом, а это all-in-one и дорого • Небольшой выбор средств • Vendor lock-in
- 19.
- 20. Монолитная архитектура • Хрупкость •Низкая скорость доставки • Ментальная сложность изменений • Организационная сложность • Дорогой технологический стук • Медленно. Дорого. Высокие риски.
- 21.
- 23. Устойчивость Если падает одинсервис, система продолжает работать Fail-over. Сервисы взаимозаменяемы. Переключение.
- 24. Высокая скорость поставки Быстраясборка и запуск Разработка и независимые выкатка сервисов Прогрессивное обновление UI
- 25. Ментальная легкость изменений •Изолированность сервиса • Низкие риски провала • Точечные изменения • Fast IDE • Rollback
- 26. Свободный технологический стэк •Agile Way • Оптимальный для каждого сервиса инструмент • Подходящий под экспертизу команды и каждого разработчика • Open-Source Software • SaaS
- 27.
- 28. Микросервисная архитектура • Устойчивость •Высокая скорость поставки • Ментальная легкость изменений • Свободный технологический стэк • Быстро. Надёжно. Эффективно.
- 30. The Art OfScalability
- 31. Scale Cube 31 Monolith Infinite Scaling Yaxis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
- 32. The Scale Cube •X - добавление новых копий приложения • Y - разделение приложение на сервисы • Z - разделение данных или ресурсов (например, для платных пользователей)
- 33.
- 34.
- 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/* Разделение данных
- 37.
- 38. Scale Cube 38 Monolith Infinite Scaling Yaxis - 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.
- 47. Scale Cube 47 Monolith Infinite Scaling Yaxis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
- 48. - С чегоначать?
- 49. Разбиваем монолит 1. Сборкаи поставка сервисов 2. Взаимодействие сервисов 3. Масштабирование
- 50.
- 51.
- 52. Docker allows youto package an application with all of its dependencies into a standardized unit for software development.
- 53.
- 54. Run 1. Image viaLXC 2. Network 3. Environment
- 55.
- 56.
- 57.
- 58.
- 59.
- 60. Docker Image • Запускаетсяв отдельном контейнере • Иногда - ещё и Volumes • Взаимодействует с другими контейнерами через сетевой интерфейс
- 61.
- 62. Микросервисное взаимодействие • RESTfulAPI, 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.
- 69. Fleet • Распределённый systemd •Набор Unit-файлов • Назначение: • Запуск Docker-контейнеров • Распределение их в кластере • Планирование запуска
- 70. Fleet - планирование •Global (можно запускать в любом месте кластера) • MachineMetadata (только на определённых машинах) • Conflicts (для избежания конфликта с коллоцированием) • MachineOf (запускать только там, где запущены определённые Unit)
- 72.
- 73.
- 74. Как Load Balancerузнает про адрес и порт контейнеров?
- 75. Service Discovery • FleetUnit • MachineOf • Определяет IP и порт целевого контейнера • Записывает в etcd • Через 5 секунд повторяет • = Sidekick Pattern
- 76. Service Discovery • FleetUnit • MachineOf • Определяет IP и порт целевого контейнера • Записывает в etcd • Через 5 секунд повторяет • = Sidekick Pattern
- 78. Как объединить Docker- контейнерыв одну сеть?
- 79.
- 80. CoreOS • Etcd -распределённое хранилище данных
- 81. CoreOS • Etcd -распределённое хранилище данных • Fleet - распределённый запуск
- 82. CoreOS • Etcd -распределённое хранилище данных • Fleet - распределённый запуск • Flannel - виртуальная сеть
- 83.
- 84.
- 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.
- 94. О чём нерассказал?
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103. Уведомления при недоступностисервисов • Интеграционные тесты • Synthetic monitoring • Отправка E-mail и SMS
- 104.
- 105.
- 106. Мы рассмотрели • Монолитнаяархитектура • Микросервисная архитектура • Модель Scale Cube • Docker • CoreOS • Kubernetes • Concourse CI
- 109.
- 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