Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Микросервисная архитектура на базе CoreOS и Kubernetes

13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.

В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.

Микросервисная архитектура на базе CoreOS и Kubernetes

  1. 1. Микросервисная архитектура на базе CoreOS и Kubernetes Денис Измайлов 13 июля 2016
  2. 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. 3. • Мы делаем web, мобильные приложения и DevOps для наших клиентов • Мы используем самые передовые и эффективные технологии • Более 20 талантливых разработчиков
  4. 4. Микросервисы
  5. 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”
  6. 6. Микросервисы не решают проблем
  7. 7. Микросервисы создают новый уровень проблем
  8. 8. Так ли это?
  9. 9. Монолитная архитектура
  10. 10. Хрупкость Если падает, то падает всё
  11. 11. Хрупкость Если падает, то падает всё С учётом высокой связанности, падает всё часто
  12. 12. Низкая скорость поставки Тяжелые процессы сборки и запуск
 Необходимость выкатывать всё даже при небольших изменениях
  13. 13. Ментальная сложность изменений • Slow IDE • Ментальная нагрузка • Высокая ответственность каждого • Что я не должен делать? • Высокие риски провала
  14. 14. Ментальная сложность изменений
  15. 15. Типичный монолит -
 человечное тело
  16. 16. Организационная сложность Необходимость согласований и координации Затягивание сроков
  17. 17. Дорогой технологический стэк • Мы не можем его менять • Необходимо брать с запасом, а это all-in-one и дорого • Небольшой выбор средств • Vendor lock-in
  18. 18. Медленно. Дорого. Высокие риски.
  19. 19. Монолитная архитектура • Хрупкость • Низкая скорость доставки • Ментальная сложность изменений • Организационная сложность • Дорогой технологический стук • Медленно. Дорого. Высокие риски.
  20. 20. Микросервисная архитектура
  21. 21. Устойчивость Если падает один сервис, система
 продолжает работать Fail-over. Сервисы взаимозаменяемы. Переключение.
  22. 22. Высокая скорость поставки Быстрая сборка и запуск Разработка и независимые
 выкатка сервисов Прогрессивное обновление UI
  23. 23. Ментальная легкость изменений • Изолированность сервиса • Низкие риски провала • Точечные изменения • Fast IDE • Rollback
  24. 24. Свободный технологический стэк • Agile Way • Оптимальный для каждого сервиса инструмент • Подходящий под экспертизу команды и каждого разработчика • Open-Source Software • SaaS
  25. 25. Быстро. Надёжно. Эффективно.
  26. 26. Микросервисная архитектура • Устойчивость • Высокая скорость поставки • Ментальная легкость изменений • Свободный технологический стэк • Быстро. Надёжно. Эффективно.
  27. 27. The Art Of Scalability
  28. 28. Scale Cube 31 Monolith Infinite Scaling Y axis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
  29. 29. The Scale Cube • X - добавление новых копий приложения • Y - разделение приложение на сервисы • Z - разделение данных или ресурсов (например, для платных пользователей)
  30. 30. X-Axis Scaling 33 Load Balancer Application Application Application Реплицирование
 приложения
  31. 31. Y-Axis Scaling 34 Load Balancer Chat Catalog Orders /catalog /chat /orders Разбиение
 приложения
  32. 32. • За какую функцию отвечает? Что делает? - управление формами, отправка e-mail, мониторинг • С какими данными работает? Кем используется? - пользовательский UI, менеджеры, отдел поддержки • Комбинированный способ • Single Responsibility Principle Y-Axis Scaling
  33. 33. Z-Axis Scaling 36 Load Balancer [A - I] [J - R] [S - Z] /catalog/* /catalog/* /catalog/* Разделение
 данных
  34. 34. Z-Axis Scaling 37 Load Balancer Regular Premium Premium /catalog/* /catalog/* /catalog/* Разделение
 ресурсов
  35. 35. Scale Cube 38 Monolith Infinite Scaling Y axis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
  36. 36. - OK, Google. Как с этим двигаться?
  37. 37. Процесс роста • Новая версия - новый сервис • 
 
 

  38. 38. Новая версия - новый сервис Blue-Green Deployment
  39. 39. Процесс роста • Новая версия - новый сервис • Effortless data model versioning for Javascript and Node.js
 https://github.com/TechnologyAdvice/ Vers
  40. 40. Процесс роста • Новая версия - новый сервис • Effortless data model versioning for Javascript and Node.js
 https://github.com/TechnologyAdvice/ Vers • GraphQL
  41. 41. GraphQL
  42. 42. Scale Cube 47 Monolith Infinite Scaling Y axis - functional decomposition X axis - horizontal duplication Zaxis-resources partitioning
  43. 43. - С чего начать?
  44. 44. Разбиваем монолит 1. Сборка и поставка сервисов 2. Взаимодействие сервисов 3. Масштабирование
  45. 45. Сборка и поставка сервисов
  46. 46. Платформа Docker
  47. 47. Docker allows you to package an application with all of its dependencies into a standardized unit for software development.
  48. 48. Build Приложение + Зависимости = Image
  49. 49. Run 1. Image via LXC 2. Network 3. Environment
  50. 50. Dockerfile
  51. 51. Dockerfile
  52. 52. Dockerfile Input Output
  53. 53. Dockerfile Input Output container = f(env)
  54. 54. Docker Image
  55. 55. Docker Image • Запускается в отдельном контейнере • Иногда - ещё и Volumes • Взаимодействует с другими контейнерами через сетевой интерфейс
 
 

  56. 56. Взаимодействие сервисов
  57. 57. Микросервисное взаимодействие • RESTful API, JSON API • OAuth, JWT • AMQ, WebSocket, JSON RPC, WAMP, etc • API Based Collaboration • Database
  58. 58. Масштабирование
  59. 59. CoreOS • Скоро будет 3 года • Мини-дистрибутив на базе Chrome OS • Нет пакетного менеджера • Все приложения - через Docker • Cloud Config • Автоматические обновления • Инфраструктура для кластеров
  60. 60. CoreOS • Etcd • Fleet • Flannel
  61. 61. Etcd • Распределённое key-value хранилище • Назначение: • Общая конфигурация • Service Discovery • Блокировка ресурсов
  62. 62. Etcd
  63. 63. Fleet • Распределённый systemd • Набор Unit-файлов • Назначение: • Запуск Docker-контейнеров • Распределение их в кластере • Планирование запуска
  64. 64. Fleet - планирование • Global (можно запускать в любом месте кластера) • MachineMetadata (только на определённых машинах) • Conflicts (для избежания конфликта с коллоцированием) • MachineOf (запускать только там, где запущены определённые Unit)
  65. 65. Fleet
  66. 66. Fleet
  67. 67. Как Load Balancer узнает про адрес и порт контейнеров?
  68. 68. Service Discovery • Fleet Unit • MachineOf • Определяет IP и порт целевого контейнера • Записывает в etcd • Через 5 секунд повторяет • = Sidekick Pattern
  69. 69. Service Discovery • Fleet Unit • MachineOf • Определяет IP и порт целевого контейнера • Записывает в etcd • Через 5 секунд повторяет • = Sidekick Pattern
  70. 70. Как объединить Docker- контейнеры в одну сеть?
  71. 71. Flannel
  72. 72. CoreOS • Etcd - распределённое хранилище данных
  73. 73. CoreOS • Etcd - распределённое хранилище данных • Fleet - распределённый запуск
  74. 74. CoreOS • Etcd - распределённое хранилище данных • Fleet - распределённый запуск • Flannel - виртуальная сеть
  75. 75. CoreOS
  76. 76. Real World Example
  77. 77. Реальный проект • Несколько сервисов (Y) • Сервис + Service Discovery • Несколько экземпляров (X) • Несколько окружений: dev, stage, production
  78. 78. Реальный проект Несколько сервисов (Y) Сервис + Service Discovery Несколько экземпляров (X) Несколько окружений: dev, stage, production 3 2 6 3
  79. 79. Реальный проект 3 2 6 3 = 108 контейнеров х x x
  80. 80. Kubernetes • Следующий уровень абстракции • Pods - группы контейнеров • Labels - тэги для идентификации Pods • ReplicationController - количество копий • Deployment - roll-out, roll-back, BGD • cAdvisor - анализ производительности и потребления ресурсов контейнеров • UI и прочее - про это всё в следующий раз
  81. 81. Stay tuned
  82. 82. О чём не рассказал?
  83. 83. Deployment Automation
  84. 84. Concourse CI
  85. 85. Resource Type
  86. 86. Resource
  87. 87. Resource
  88. 88. Concourse Pipeline
  89. 89. www.concourse.ci
  90. 90. Мониторинг производительности и ошибок
  91. 91. Уведомления при недоступности сервисов • Интеграционные тесты • Synthetic monitoring • Отправка E-mail и SMS
  92. 92. Логирование и агрегация логов
  93. 93. DC/OS
  94. 94. Мы рассмотрели • Монолитная архитектура • Микросервисная архитектура • Модель Scale Cube • Docker • CoreOS • Kubernetes • Concourse CI
  95. 95. Спасибо за внимание Денис Измайлов @DenisIzmaylov https://github.com/DenisIzmaylov www.startup-makers.com denis_izmaylov izmaylov.dm@gmail.com
  96. 96. Полезные ссылки • 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

×