Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

«Микросервисы наносят ответный удар!» Олег Чуркин, Rambler&Co

260 views

Published on

Выступление на PYCON RUSSIA 2017

Published in: Internet
  • Be the first to comment

«Микросервисы наносят ответный удар!» Олег Чуркин, Rambler&Co

  1. 1. Микросервисы наносят ответный удар Что нужно знать Python-разработчику о микросервисных архитектурах. в 2017 году (кратко) Чуркин Олег <Rambler&Co>
  2. 2. О чем поговорим
  3. 3. О чем поговорим ● Когда стоит подумать о микросервисной архитектуре
  4. 4. О чем поговорим ● Когда стоит подумать о микросервисной архитектуре ● Декомпозиция монолитных приложений
  5. 5. О чем поговорим ● Когда стоит подумать о микросервисной архитектуре ● Декомпозиция монолитных приложений ● Требования к приложению
  6. 6. О чем поговорим ● Когда стоит подумать о микросервисной архитектуре ● Декомпозиция монолитных приложений ● Требования к приложению ● Отказоустойчивость и стабильность микросервисов
  7. 7. Monolith vs Microservices (SOA)
  8. 8. Monolith vs Microservices (SOA) Монолитная архитектура
  9. 9. Monolith vs Microservices (SOA) Монолитная архитектура Микросервисная архитектура
  10. 10. Типичный монолит
  11. 11. Client: mobile, web-browser Типичный монолит
  12. 12. Client: mobile, web-browser FRONTEND Типичный монолит Load balancer / Web server (nginx)
  13. 13. Client: mobile, web-browser MODULES BACKENDFRONTEND Типичный монолит Load balancer / Web server (nginx) Assets / Templates Search Admin / CMS Acquiring / Payments REST API Feedback / Support Chat Reports / Statistics Consumers / Workers Mobile API Authentication / Authorization
  14. 14. «Распиливаем» монолит
  15. 15. Client: mobile, web-browser «Распиливаем» монолит
  16. 16. Client: mobile, web-browser FRONTEND «Распиливаем» монолит Load balancer / Web server (nginx) SPA / Isomorphic application (node.js)
  17. 17. Client: mobile, web-browser BACKEND Events Bus / Message broker FRONTEND «Распиливаем» монолит Load balancer / Web server (nginx) SPA / Isomorphic application (node.js) API Gateway / Facade FRONTEND Load balancer / Web server (nginx) SPA / Isomorphic application (node.js)
  18. 18. Client: mobile, web-browser BACKEND Events Bus / Message broker FRONTEND «Распиливаем» монолит Load balancer / Web server (nginx) SPA / Isomorphic application (node.js) API Gateway / Facade Feedback / Support Chat Authentication / Authorization Search Admin / CMS Acquiring / Payments REST API / Mobile API Reports / Statistics Consumers / Workers FRONTEND Load balancer / Web server (nginx) SPA / Isomorphic application (node.js)
  19. 19. Преимущества микросервисов
  20. 20. Преимущества микросервисов ● Независимая разработка – технологии, команды и процессы могут быть совершенно разными
  21. 21. ● Независимая разработка – технологии, команды и процессы могут быть совершенно разными ● Независимый деплой Преимущества микросервисов
  22. 22. Преимущества микросервисов ● Независимая разработка – технологии, команды и процессы могут быть совершенно разными ● Независимый деплой ● Один упал, остальное работает
  23. 23. Преимущества микросервисов ● Независимая разработка – технологии, команды и процессы могут быть совершенно разными ● Независимый деплой ● Один упал, остальное работает ● Модульность – просто включитьвыключить, легко удалять код, не такое страшное легаси
  24. 24. Преимущества микросервисов ● Независимая разработка – технологии, команды и процессы могут быть совершенно разными ● Независимый деплой ● Один упал, остальное работает ● Модульность – просто включитьвыключить, легко удалять код, не такое страшное легаси ● Децентрализованное управление данными
  25. 25. Микросервисы: trade-offs
  26. 26. ● Инфраструктура усложнилась – нужно время на доработку и более опытная команда для ее поддержки Микросервисы: trade-offs
  27. 27. ● Инфраструктура усложнилась – нужно время на доработку и более опытная команда для ее поддержки ● Появилось больше точек отказа Микросервисы: trade-offs
  28. 28. ● Инфраструктура усложнилась – нужно время на доработку и более опытная команда для ее поддержки ● Появилось больше точек отказа ● CPU-вызовы заменились на Network-вызовы: выросла нагрузка на сеть, вызовы стали медленнее и вероятность их отказа выросла Микросервисы: trade-offs
  29. 29. Микросервисы: trade-offs ● Инфраструктура усложнилась – нужно время на доработку и более опытная команда для ее поддержки ● Появилось больше точек отказа ● CPU-вызовы заменились на Network-вызовы: выросла нагрузка на сеть, вызовы стали медленнее и вероятность их отказа выросла ● Eventual consistency – нужно подождать, чтобы увидеть результаты изменений
  30. 30. Микрослужбы: когда еще рано
  31. 31. ● Небольшая кодовая база, простой/утилитарный проект, нет планов по расширению Микрослужбы: когда еще рано
  32. 32. ● Небольшая кодовая база, простой/утилитарный проект, нет планов по расширению ● Трудности обновления инфраструктуры перевешивают плюсы от микросервисов Микрослужбы: когда еще рано
  33. 33. Микрослужбы: когда еще рано ● Небольшая кодовая база, простой/утилитарный проект, нет планов по расширению ● Трудности обновления инфраструктуры перевешивают плюсы от микросервисов ● У вас и так все в порядке: быстро разрабатываете; быстро выкладываете в продакшен; пишите красивый, модульный код
  34. 34. Микрослужбы: когда стоит подумать
  35. 35. ● Появилась определенное требование к безопасности, стабильности и скорости разработки Микрослужбы: когда стоит подумать
  36. 36. ● Появилась определенное требование к безопасности, стабильности и скорости разработки ● Текущий фреймворк плохо подходит под новые задачи Микрослужбы: когда стоит подумать
  37. 37. ● Появилась определенное требование к безопасности, стабильности и скорости разработки ● Текущий фреймворк плохо подходит под новые задачи ● Большая команда и много кода – долгие релизы, частые merge-конфликты Микрослужбы: когда стоит подумать
  38. 38. ● Появилась определенное требование к безопасности, стабильности и скорости разработки ● Текущий фреймворк плохо подходит под новые задачи ● Большая команда и много кода – долгие релизы, частые merge-конфликты ● Сильная нагрузка на определенный функционал, его нужно либо переписать либо масштабировать Микрослужбы: когда стоит подумать
  39. 39. Микрослужбы: когда стоит подумать ● Появилась определенное требование к безопасности, стабильности и скорости разработки ● Текущий фреймворк плохо подходит под новые задачи ● Большая команда и много кода – долгие релизы, частые merge-конфликты ● Сильная нагрузка на определенный функционал, его нужно либо переписать либо масштабировать ● Долгие деплои, связынные с большим количеством кода и различных обслуживающих операций (скриптов)
  40. 40. Что нам нужно сделать (глобально)?
  41. 41. Что нам нужно сделать (глобально)? ● Определиться с разбивкой компонентов на сервисы
  42. 42. Что нам нужно сделать (глобально)? ● Определиться с разбивкой компонентов на сервисы ● Выбрать технологический стек
  43. 43. Что нам нужно сделать (глобально)? ● Определиться с разбивкой компонентов на сервисы ● Выбрать технологический стек ● Адаптировать инфраструктуру
  44. 44. Поговорим про технологии, а конкретно про фреймворки.
  45. 45. Выбор фреймворка под конкретный сервис/задачи
  46. 46. ● CPU-bound vs IO-bound Выбор фреймворка под конкретный сервис/задачи
  47. 47. ● CPU-bound vs IO-bound ● Стабильность и безопасность Выбор фреймворка под конкретный сервис/задачи
  48. 48. ● CPU-bound vs IO-bound ● Стабильность и безопасность ● Удобство разработки Выбор фреймворка под конкретный сервис/задачи
  49. 49. ● CPU-bound vs IO-bound ● Стабильность и безопасность ● Удобство разработки ● Количество доступных «батареек» Выбор фреймворка под конкретный сервис/задачи
  50. 50. Выбор фреймворка под конкретный сервис/задачи ● CPU-bound vs IO-bound ● Стабильность и безопасность ● Удобство разработки ● Количество доступных «батареек» ● Производительность
  51. 51. Выбор фреймворка под конкретный сервис/задачи ● CPU-bound vs IO-bound ● Стабильность и безопасность ● Удобство разработки ● Количество доступных «батареек» ● Производительность ● Поддержка (LTS релизы)
  52. 52. Вариантов много
  53. 53. Что выбрать?
  54. 54. Совет №1: чем стабильнее и функциональнее будет фреймворк, тем меньше головной боли вас ожидает в будущем. Что выбрать?
  55. 55. Совет №1: чем стабильнее и функциональнее будет фреймворк, тем меньше головной боли вас ожидает в будущем. Совет №2: не обязательно выбирать микрофреймворк для создания микросервиса. Что выбрать?
  56. 56. Типы web-фреймворков
  57. 57. «Синхронные» – используют модель workers pool, каждый worker приложения работает над одним запросом в единицу времени не прерываясь, оперируют функциями: Django, Flask, Falcon и т.д. Типы web-фреймворков
  58. 58. «Синхронные» – используют модель workers pool, каждый worker приложения работает над одним запросом в единицу времени не прерываясь, оперируют функциями: Django, Flask, Falcon и т.д. «Асинхронные» – используют паттерн Eventloop, оперируют корутинами: Tornado, aiohttp, Sanic и т.д. Типы web-фреймворков
  59. 59. Синхронный фреймворк
  60. 60. ● CRUD сервисы для работы с реляционными СУБД: Синхронный фреймворк
  61. 61. ● CRUD сервисы для работы с реляционными СУБД: ○ Удобные ORM с богатым функционалом Синхронный фреймворк
  62. 62. ● CRUD сервисы для работы с реляционными СУБД: ○ Удобные ORM с богатым функционалом ○ Удобные инструменты для создания и проведения миграций Синхронный фреймворк
  63. 63. ● CRUD сервисы для работы с реляционными СУБД: ○ Удобные ORM с богатым функционалом ○ Удобные инструменты для создания и проведения миграций ○ Ограничения psycopg2 при работы с асинхронными запросами (autocommit, set_client_encoding, executemany, large objects, named cursors) Синхронный фреймворк
  64. 64. ● CRUD сервисы для работы с реляционными СУБД: ○ Удобные ORM с богатым функционалом ○ Удобные инструменты для создания и проведения миграций ○ Ограничения psycopg2 при работы с асинхронными запросами (autocommit, set_client_encoding, executemany, large objects, named cursors) ○ aiomysql – еще в alpha Синхронный фреймворк
  65. 65. ● CRUD сервисы для работы с реляционными СУБД: ○ Удобные ORM с богатым функционалом ○ Удобные инструменты для создания и проведения миграций ○ Ограничения psycopg2 при работы с асинхронными запросами (autocommit, set_client_encoding, executemany, large objects, named cursors) ○ aiomysql – еще в alpha ● Админки и интерфейсы CMS Синхронный фреймворк
  66. 66. ● CRUD сервисы для работы с реляционными СУБД: ○ Удобные ORM с богатым функционалом ○ Удобные инструменты для создания и проведения миграций ○ Ограничения psycopg2 при работы с асинхронными запросами (autocommit, set_client_encoding, executemany, large objects, named cursors) ○ aiomysql – еще в alpha ● Админки и интерфейсы CMS ● REST поверх CRUD – за счет мощного Django Rest Framework Синхронный фреймворк
  67. 67. ● CRUD сервисы для работы с реляционными СУБД: ○ Удобные ORM с богатым функционалом ○ Удобные инструменты для создания и проведения миграций ○ Ограничения psycopg2 при работы с асинхронными запросами (autocommit, set_client_encoding, executemany, large objects, named cursors) ○ aiomysql – еще в alpha ● Админки и интерфейсы CMS ● REST поверх CRUD – за счет мощного Django Rest Framework ● Сервисы требующие повышенного отношения к безопасности (платежи, важные пользовательские данные и т.д.) Синхронный фреймворк
  68. 68. Асинхронный фреймворк
  69. 69. ● Много IO-bound задач, мало CPU-bound задач: Асинхронный фреймворк
  70. 70. ● Много IO-bound задач, мало CPU-bound задач: ○ Прокси сервисы Асинхронный фреймворк
  71. 71. ● Много IO-bound задач, мало CPU-bound задач: ○ Прокси сервисы ○ HTTP-интеграции со сторонними сервисами Асинхронный фреймворк
  72. 72. ● Много IO-bound задач, мало CPU-bound задач: ○ Прокси сервисы ○ HTTP-интеграции со сторонними сервисами ○ Обработчики очередей (workers/consumers) Асинхронный фреймворк
  73. 73. ● Много IO-bound задач, мало CPU-bound задач: ○ Прокси сервисы ○ HTTP-интеграции со сторонними сервисами ○ Обработчики очередей (workers/consumers) ○ Facade-сервисы Асинхронный фреймворк
  74. 74. Асинхронный фреймворк ● Много IO-bound задач, мало CPU-bound задач: ○ Прокси сервисы ○ HTTP-интеграции со сторонними сервисами ○ Обработчики очередей (workers/consumers) ○ Facade-сервисы ● Чаты, мессенджеры
  75. 75. Асинхронный фреймворк ● Много IO-bound задач, мало CPU-bound задач: ○ Прокси сервисы ○ HTTP-интеграции со сторонними сервисами ○ Обработчики очередей (workers/consumers) ○ Facade-сервисы ● Чаты, мессенджеры ● Сервисы для работы с websockets и server-sent events
  76. 76. «Детские болячки» в асинхронном мире
  77. 77. «Детские болячки» в асинхронном мире ● aiohttp pre 2.0 era ○ Socket leak and incorrect connection close ○ Обратно несовместимые изменения ○ Запутывающие ошибки вида "error handling response" и "cancelled error"
  78. 78. «Детские болячки» в асинхронном мире ● aiohttp pre 2.0 era ○ Socket leak and incorrect connection close ○ Обратно несовместимые изменения ○ Запутывающие ошибки вида "error handling response" и "cancelled error" ● pewee_async ○ Нет поддержки агрегационных запросов ○ Неправильно обрабатываются закрытые соединения
  79. 79. «Детские болячки» в асинхронном мире ● aiohttp pre 2.0 era ○ Socket leak and incorrect connection close ○ Обратно несовместимые изменения ○ Запутывающие ошибки вида "error handling response" и "cancelled error" ● pewee_async ○ Нет поддержки агрегационных запросов ○ Неправильно обрабатываются закрытые соединения ● asyncio_redis ○ дедлок
  80. 80. Но не стоит сгущать краски Twisted и Tornado – зрелые, стабильные, функциональные.
  81. 81. aiolibs https://github.com/aio-libs ● aiohttp (post 2.0 era) ● aioredis ● aiopg ● aiomysql
  82. 82. Новые перспективные игроки Sanic набирает популярность, как «асинхронный Flask» https://github.com/channelcat/sanic
  83. 83. Думаем о приложении/сервисе
  84. 84. Думаем о приложении/сервисе ● Архитектурный дизайн
  85. 85. Думаем о приложении/сервисе ● Архитектурный дизайн ● The Twelve-Factor App: https://12factor.net/
  86. 86. Думаем о приложении/сервисе ● Архитектурный дизайн ● The Twelve-Factor App: https://12factor.net/ ● API дизайн (версионирование, обратная совместимость)
  87. 87. Думаем о приложении/сервисе ● Архитектурный дизайн ● The Twelve-Factor App: https://12factor.net/ ● API дизайн (версионирование, обратная совместимость) ● Культура DevOps (описание инфраструктуры, infrastructure as code)
  88. 88. Думаем о приложении/сервисе ● Архитектурный дизайн ● The Twelve-Factor App: https://12factor.net/ ● API дизайн (версионирование, обратная совместимость) ● Культура DevOps (описание инфраструктуры, infrastructure as code) ● Контейнеризация (docker)
  89. 89. ● Маштабирование Думаем о приложении/сервисе
  90. 90. ● Маштабирование ● Не храним состояние (stateless) Думаем о приложении/сервисе
  91. 91. ● Маштабирование ● Не храним состояние (stateless) ● Шаблон сервиса (https://github.com/audreyr/cookiecutter) Думаем о приложении/сервисе
  92. 92. ● Маштабирование ● Не храним состояние (stateless) ● Шаблон сервиса (https://github.com/audreyr/cookiecutter) ● Обнаружение сервисов (service discovery) Думаем о приложении/сервисе
  93. 93. ● Маштабирование ● Не храним состояние (stateless) ● Шаблон сервиса (https://github.com/audreyr/cookiecutter) ● Обнаружение сервисов (service discovery) ● Взаимодействие между сервисами (IPC: json, thrift, protobuf) Думаем о приложении/сервисе
  94. 94. Отказоустойчивость и стабильность
  95. 95. Отказоустойчивость и стабильность ● Понятие recovery – контракт на то, как вести себя сервису в случае ошибок, которые он может обработать и которые не может
  96. 96. ● Понятие recovery – контракт на то, как вести себя сервису в случае ошибок, которые он может обработать и которые не может ● Обязательные и короткие таймауты Отказоустойчивость и стабильность
  97. 97. ● Понятие recovery – контракт на то, как вести себя сервису в случае ошибок, которые он может обработать и которые не может ● Обязательные и короткие таймауты ● Circuit Breakers – не заваливать сервис запросами, если он умирает. Отказоустойчивость и стабильность
  98. 98. ● Понятие recovery – контракт на то, как вести себя сервису в случае ошибок, которые он может обработать и которые не может ● Обязательные и короткие таймауты ● Circuit Breakers – не заваливать сервис запросами, если он умирает. ● Fail fast – лучше сразу упасть, чем ждать Отказоустойчивость и стабильность
  99. 99. ● Понятие recovery – контракт на то, как вести себя сервису в случае ошибок, которые он может обработать и которые не может ● Обязательные и короткие таймауты ● Circuit Breakers – не заваливать сервис запросами, если он умирает. ● Fail fast – лучше сразу упасть, чем ждать ● Общие клиенты вынесены в зависимости Отказоустойчивость и стабильность
  100. 100. Отказоустойчивость и стабильность ● Обязательное логирование, метрики и мониторинг, авторестарт
  101. 101. Отказоустойчивость и стабильность ● Обязательное логирование, метрики и мониторинг, авторестарт ● Правильная обработка сигналов SIGTERM и SIGINT
  102. 102. Отказоустойчивость и стабильность ● Обязательное логирование, метрики и мониторинг, авторестарт ● Правильная обработка сигналов SIGTERM и SIGINT ● Сохранение обратной совместимости в рамках одной версии API
  103. 103. Отказоустойчивость и стабильность ● Обязательное логирование, метрики и мониторинг, авторестарт ● Правильная обработка сигналов SIGTERM и SIGINT ● Сохранение обратной совместимости в рамках одной версии API ● Connection pools – правильно обрабатываем закрытые соединения, иначе zombie-service.
  104. 104. Отказоустойчивость и стабильность ● Обязательное логирование, метрики и мониторинг, авторестарт ● Правильная обработка сигналов SIGTERM и SIGINT ● Сохранение обратной совместимости в рамках одной версии API ● Connection pools – правильно обрабатываем закрытые соединения, иначе zombie-service. ● Request Id – подписываем (headers) все запросы, чтобы агрегировать логи между сервисами
  105. 105. Классические ошибки при внедрении и разработке микросервисов
  106. 106. ● Переход от вызовов функций к вызовам сервисов без адаптации архитектуры Классические ошибки при внедрении и разработке микросервисов
  107. 107. ● Переход от вызовов функций к вызовам сервисов без адаптации архитектуры ● Незафиксированные версии зависимостей (requirements.txt) Классические ошибки при внедрении и разработке микросервисов
  108. 108. ● Переход от вызовов функций к вызовам сервисов без адаптации архитектуры ● Незафиксированные версии зависимостей (requirements.txt) ● Слишком много CPU-bound задач в асинхронных сервисах, например json-сериализация. IO-bound в асинхронных. Классические ошибки при внедрении и разработке микросервисов
  109. 109. ● Переход от вызовов функций к вызовам сервисов без адаптации архитектуры ● Незафиксированные версии зависимостей (requirements.txt) ● Слишком много CPU-bound задач в асинхронных сервисах, например json-сериализация. IO-bound в асинхронных. ● loop.run_in_executor не всегда спасет от проблем с CPU-bound задачами Классические ошибки при внедрении и разработке микросервисов
  110. 110. ● Переход от вызовов функций к вызовам сервисов без адаптации архитектуры ● Незафиксированные версии зависимостей (requirements.txt) ● Слишком много CPU-bound задач в асинхронных сервисах, например json-сериализация. IO-bound в асинхронных. ● loop.run_in_executor не всегда спасет от проблем с CPU-bound задачами ● Использование глобальных объектов для хранения состояния запроса в памяти асинхронного приложения Классические ошибки при внедрении и разработке микросервисов
  111. 111. ● Длинные последовательные цепочки запросов между сервисами, необходимые для формирования данных. Классические ошибки при внедрении и разработке микросервисов
  112. 112. ● Длинные последовательные цепочки запросов между сервисами, необходимые для формирования данных. ● «Сервис на каждый чих» Классические ошибки при внедрении и разработке микросервисов
  113. 113. ● Длинные последовательные цепочки запросов между сервисами, необходимые для формирования данных. ● «Сервис на каждый чих» ● Один источник данных для всех сервисов Классические ошибки при внедрении и разработке микросервисов
  114. 114. ● Длинные последовательные цепочки запросов между сервисами, необходимые для формирования данных. ● «Сервис на каждый чих» ● Один источник данных для всех сервисов ● Копипаста кода между сервисами, вместо установки зависимостей (если у вас не монорепозиторий) Классические ошибки при внедрении и разработке микросервисов
  115. 115. ● Длинные последовательные цепочки запросов между сервисами, необходимые для формирования данных. ● «Сервис на каждый чих» ● Один источник данных для всех сервисов ● Копипаста кода между сервисами, вместо установки зависимостей (если у вас не монорепозиторий) ● Отсутствие автоматизации версионирования сервисов (versioneer, bumpversion) Классические ошибки при внедрении и разработке микросервисов
  116. 116. ● Длинные последовательные цепочки запросов между сервисами, необходимые для формирования данных. ● «Сервис на каждый чих» ● Один источник данных для всех сервисов ● Копипаста кода между сервисами, вместо установки зависимостей (если у вас не монорепозиторий) ● Отсутствие автоматизации версионирования сервисов (versioneer, bumpversion) ● Если где-то соединение открывается, то где-то оно должно быть закрыто Классические ошибки при внедрении и разработке микросервисов
  117. 117. Интеграции со сторонними сервисами
  118. 118. ● Правильно обрабатывать ошибки (коды ответа, правильный recovery) Интеграции со сторонними сервисами
  119. 119. ● Правильно обрабатывать ошибки (коды ответа, правильный recovery) ● Exponential backoff – увеличивать промежуток между опросами экспоненциально Интеграции со сторонними сервисами
  120. 120. Интеграции со сторонними сервисами ● Правильно обрабатывать ошибки (коды ответа, правильный recovery) ● Exponential backoff – увеличивать промежуток между опросами экспоненциально ● Строгая валидация данных чаще всего не работает. Активная валидация по json-schema – приводит к проблемам, т.к. поставщики на самом деле часто меняют API.
  121. 121. Интеграции со сторонними сервисами ● Правильно обрабатывать ошибки (коды ответа, правильный recovery) ● Exponential backoff – увеличивать промежуток между опросами экспоненциально ● Строгая валидация данных чаще всего не работает. Активная валидация по json-schema – приводит к проблемам, т.к. поставщики на самом деле часто меняют API. ● Фильтрация данных на html и sql-injections от поставщика.
  122. 122. В итоге: подготовьтесь теоретически
  123. 123. Designing and Deploying Microservices https://www.nginx.com/resources/library/designing-deploying-m icroservices/ Best Practices for Building a Microservice Architecture http://www.vinaysahni.com/best-practices-for-building-a-micros ervice-architecture В итоге: подготовьтесь теоретически
  124. 124. ● Обстоятельно выбирайте технологический стек ● Автоматизируйте все по максимуму ● Думайте не об единичных сущностях, а о системе в целом И еще
  125. 125. Спасибо! Вопросы и ответы https://fb.me/bahusoff https://telegram.me/bahusoff https://github.com/Bahus

×