SlideShare a Scribd company logo
1 of 21
Download to read offline
Микросервисы. Наш опыт
Михайлик Алексей,
директор по разработке
(Director of R&D) Global Fleet Management
Кто я
Наша компания - GFM
Наш продукт - PosiTrace
Микросервисы. Наш опыт
Disclaimers
Disclaimer #1: все выводы в докладе построены на нашем опыте, вы
можете быть с ними не согласны
Disclaimer #2: некоторые решения мы делали итеративно годами,
некоторые применили в последние несколько
месяцев, хронологически это не будет отображено
Disclaimer #3: многое сейчас находится
в состоянии далеком от микросервисного,
с чем-то смирились, для чего-то мы не знаем
решения, что-то запланировано
Микросервисы. Наш опыт
Resources
Микросервисы. Наш опыт
Software Development Life Cycle
Микросервисы. Наш опыт
SDLC. Take it easy
WaterFall
большой круг
Гибкие методологии - маленькие
кружочки
Микросервисы. Наш опыт
SDLC. Come back
Возврат = Увеличение времени = Увеличение цены
Микросервисы. Наш опыт
SDLC. Radius
Частота - частота релизов
Амплитуда - количество энергии, которые мы потратим для каждой итерации
Микросервисы. Наш опыт
Monolith
Год-два-три и у вас монолитный код
Монолитность - это норма, мы дописываем по требованию заказчика
Достаточно трудоемко монолитный код разбивать на части
Микросервисы. Наш опыт
Monolith Detector
● Билд запустился и можно
пойти пить кофе
● Долго стартующая аппликация
● Долгое тестирование
Как определить то, что код монолитный, всё просто - это когда все медленно:
Микросервисы. Наш опыт
История нашего продукта
С# везде - с одним общим codebase
До с# / Erlang / ruby / nodejs / elixir
Разнородность задач = разнородность мини-команд,
отвечающих за реализацию того или иного направления
Микросервисы. Наш опыт
Класс задач решаемых нашим продуктом
a. Принял - Разобрал
b. Обработал - Сохранил
c. Проанализировал - Уведомил
Зашел клиент - просмотрел всё что произошло на любом из этапов
Микросервисы. Наш опыт
Способы интеграции приложений
a. Передача файлов
b. Общая база данных
c. Удаленный вызов процедур
d. Обмен сообщениями
SOA: CORBA/WebServices/Queues/?
Микросервисы. Наш опыт
Принял - Разобрал - прием данных
a. Большая цена потери данных
b. Конвейерная передача данных на следующий
этап
Микросервисы. Наш опыт
Принял - Разобрал - общение в обратную сторону
Отдельные сервисы отвечающие за
i. Конфигурацию
ii. Состояние выхода
Микросервисы. Наш опыт
Обработал - Сохранил
1. Orleans - отдельный доклад
2. Новый сервис - Data Provider
3. Входные данные: сенсоры -> Выходные: состояния
Микросервисы. Наш опыт
Проанализировал - Уведомил
1. Проанализировал - это снова-таки новое состояние,
до этого у нас снова была реализация через очередь
2. Остаётся только “Уведомил”
Сообщество предпочитает другой подход: умные конечные точки и глупые
каналы. Микросервисы, из которых собираются приложения, должны как
можно меньше зависеть друг от друга и при этом быть очень тесно
связанными — они содержат собственную доменную логику и работают
скорее как фильтры с точки зрения классического Unix: получают запросы,
применяют логику и генерируют ответы. - Martin Fawler
Микросервисы. Наш опыт
Принял - Разобрал, где здесь микросервис?
1. Минимальные отличия друг от друга - только в “Разобрал”, много
общего codebase’a! Но это всё равно разные сервисы!
2. Манипуляции с входными данными для разделения потоков обработки
3. Независимые деплои - только разрыв соединения, небольшие бутстрап
задачи
4. Codebase может быть и разным! Очень полезно когда занимаешься
рефакторингом и/или апгрейдом библиотек
5. Раздельные сервисы можно останавливать/запускать когда тебе нужно
(тестовые запуски, течёт память)
Микросервисы. Наш опыт
Необходимость нескольких окружений
1. Параллельно в разработке несколько фич
2. Из-за микросервисных решений - макро коммуникации
3. Завести окружение - это еще та задача, нужна автоматическая
подготовка окружения
Микросервисы. Наш опыт
Нужно все равно следить за всем!
В микросервисном подходе добавляются проблемы с их
интеграцией между собой:
- Совместимость API
- Нагрузка, хоть она и внутренняя
- Время отклика
Микросервисы. Наш опыт
Почему микросервисы еще важны
- Переезд на новое железо / в новый ДЦ / в облака
- Все и сразу - такого не бывает
- Если делалось все правильно в staging окружении - уже легче
Микросервисы. Наш опыт
Недостатки: высокая сложность эксплуатации
- DevOps-составляющая.
- Много технологий и библиотек
- Согласование версий API
- Интеграционное тестирование

More Related Content

Similar to 06-mikhailik

Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESBАрхитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESBPavel Treshnikov
 
Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...
Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...
Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...Cisco Russia
 
Книга компании onpbx
Книга компании onpbxКнига компании onpbx
Книга компании onpbxonpbx
 
Gnevshev мониторинг
Gnevshev   мониторингGnevshev   мониторинг
Gnevshev мониторингkuchinskaya
 
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
 
Дикие микросервисы на JUG Екатеринбург
Дикие микросервисы на JUG ЕкатеринбургДикие микросервисы на JUG Екатеринбург
Дикие микросервисы на JUG ЕкатеринбургКирилл Толкачёв
 
Дмитрий Прокофьев: Эволюция системы синхронизации данных между сервисами
Дмитрий Прокофьев: Эволюция системы синхронизации данных между сервисамиДмитрий Прокофьев: Эволюция системы синхронизации данных между сервисами
Дмитрий Прокофьев: Эволюция системы синхронизации данных между сервисамиit-people
 
Система анализа работы приложений и протоколов Riverbed Cascade
Система анализа работы приложений и протоколов Riverbed CascadeСистема анализа работы приложений и протоколов Riverbed Cascade
Система анализа работы приложений и протоколов Riverbed CascadeКРОК
 
истории успеха. июнь 2013
истории успеха. июнь 2013истории успеха. июнь 2013
истории успеха. июнь 2013The Skolkovo Foundation
 
Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ
Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ
Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ Provectus
 
Жизненный цикл разработки крупного продукта несколькими командами (Александр ...
Жизненный цикл разработки крупного продукта несколькими командами (Александр ...Жизненный цикл разработки крупного продукта несколькими командами (Александр ...
Жизненный цикл разработки крупного продукта несколькими командами (Александр ...PCampRussia
 
Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0.
Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0. Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0.
Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0. Cisco Russia
 
микроСЕРВИСЫ: огонь, вода и медные трубы
микроСЕРВИСЫ: огонь, вода и медные трубымикроСЕРВИСЫ: огонь, вода и медные трубы
микроСЕРВИСЫ: огонь, вода и медные трубыAleksandr Tarasov
 
Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...
Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...
Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...Аліна Шепшелей
 
SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...
SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...
SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...Inhacking
 
Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»
Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»
Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»Cisco Russia
 

Similar to 06-mikhailik (20)

Wild microservices and imaginary DevOps
Wild microservices and imaginary DevOpsWild microservices and imaginary DevOps
Wild microservices and imaginary DevOps
 
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESBАрхитектура масштабируемых приложений. Микросервисы, CQRS, ESB
Архитектура масштабируемых приложений. Микросервисы, CQRS, ESB
 
Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...
Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...
Облачные приложения и построение платформ для них на базе Openstack Дмитрий Х...
 
Книга компании onpbx
Книга компании onpbxКнига компании onpbx
Книга компании onpbx
 
Node .js microservices
Node .js microservices Node .js microservices
Node .js microservices
 
Gnevshev мониторинг
Gnevshev   мониторингGnevshev   мониторинг
Gnevshev мониторинг
 
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)
 
Agile/Scrum
Agile/ScrumAgile/Scrum
Agile/Scrum
 
Дикие микросервисы на JUG Екатеринбург
Дикие микросервисы на JUG ЕкатеринбургДикие микросервисы на JUG Екатеринбург
Дикие микросервисы на JUG Екатеринбург
 
Scrum Wars
Scrum WarsScrum Wars
Scrum Wars
 
Дмитрий Прокофьев: Эволюция системы синхронизации данных между сервисами
Дмитрий Прокофьев: Эволюция системы синхронизации данных между сервисамиДмитрий Прокофьев: Эволюция системы синхронизации данных между сервисами
Дмитрий Прокофьев: Эволюция системы синхронизации данных между сервисами
 
Система анализа работы приложений и протоколов Riverbed Cascade
Система анализа работы приложений и протоколов Riverbed CascadeСистема анализа работы приложений и протоколов Riverbed Cascade
Система анализа работы приложений и протоколов Riverbed Cascade
 
истории успеха. июнь 2013
истории успеха. июнь 2013истории успеха. июнь 2013
истории успеха. июнь 2013
 
Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ
Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ
Eduard Dautov (Provectus): СКОРИНГ ML МОДЕЛЕЙ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ
 
Жизненный цикл разработки крупного продукта несколькими командами (Александр ...
Жизненный цикл разработки крупного продукта несколькими командами (Александр ...Жизненный цикл разработки крупного продукта несколькими командами (Александр ...
Жизненный цикл разработки крупного продукта несколькими командами (Александр ...
 
Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0.
Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0. Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0.
Новые возможности решений на базе Cisco Unified Contact Center в версии 9.0.
 
микроСЕРВИСЫ: огонь, вода и медные трубы
микроСЕРВИСЫ: огонь, вода и медные трубымикроСЕРВИСЫ: огонь, вода и медные трубы
микроСЕРВИСЫ: огонь, вода и медные трубы
 
Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...
Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...
Dmitriy Kouperman Working with legacy systems. stabilization, monitoring, man...
 
SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...
SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...
SE2016 Java Dmitriy Kouperman "Working with legacy systems. Stabilization, mo...
 
Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»
Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»
Опыт использования оборудования Cisco в дата-центре «Инфосистемы Джет»
 

More from ITconnectITconnect1 (9)

09-lymarev
09-lymarev09-lymarev
09-lymarev
 
01-tarasov
01-tarasov01-tarasov
01-tarasov
 
08-eremin
08-eremin08-eremin
08-eremin
 
10-toichkin
10-toichkin10-toichkin
10-toichkin
 
07-zaytcev
07-zaytcev07-zaytcev
07-zaytcev
 
05-kuzmin
05-kuzmin05-kuzmin
05-kuzmin
 
04-varzar
04-varzar04-varzar
04-varzar
 
03-chumakova
03-chumakova03-chumakova
03-chumakova
 
02-kozlov
02-kozlov02-kozlov
02-kozlov
 

06-mikhailik

  • 1. Микросервисы. Наш опыт Михайлик Алексей, директор по разработке (Director of R&D) Global Fleet Management Кто я Наша компания - GFM Наш продукт - PosiTrace
  • 2. Микросервисы. Наш опыт Disclaimers Disclaimer #1: все выводы в докладе построены на нашем опыте, вы можете быть с ними не согласны Disclaimer #2: некоторые решения мы делали итеративно годами, некоторые применили в последние несколько месяцев, хронологически это не будет отображено Disclaimer #3: многое сейчас находится в состоянии далеком от микросервисного, с чем-то смирились, для чего-то мы не знаем решения, что-то запланировано
  • 5. Микросервисы. Наш опыт SDLC. Take it easy WaterFall большой круг Гибкие методологии - маленькие кружочки
  • 6. Микросервисы. Наш опыт SDLC. Come back Возврат = Увеличение времени = Увеличение цены
  • 7. Микросервисы. Наш опыт SDLC. Radius Частота - частота релизов Амплитуда - количество энергии, которые мы потратим для каждой итерации
  • 8. Микросервисы. Наш опыт Monolith Год-два-три и у вас монолитный код Монолитность - это норма, мы дописываем по требованию заказчика Достаточно трудоемко монолитный код разбивать на части
  • 9. Микросервисы. Наш опыт Monolith Detector ● Билд запустился и можно пойти пить кофе ● Долго стартующая аппликация ● Долгое тестирование Как определить то, что код монолитный, всё просто - это когда все медленно:
  • 10. Микросервисы. Наш опыт История нашего продукта С# везде - с одним общим codebase До с# / Erlang / ruby / nodejs / elixir Разнородность задач = разнородность мини-команд, отвечающих за реализацию того или иного направления
  • 11. Микросервисы. Наш опыт Класс задач решаемых нашим продуктом a. Принял - Разобрал b. Обработал - Сохранил c. Проанализировал - Уведомил Зашел клиент - просмотрел всё что произошло на любом из этапов
  • 12. Микросервисы. Наш опыт Способы интеграции приложений a. Передача файлов b. Общая база данных c. Удаленный вызов процедур d. Обмен сообщениями SOA: CORBA/WebServices/Queues/?
  • 13. Микросервисы. Наш опыт Принял - Разобрал - прием данных a. Большая цена потери данных b. Конвейерная передача данных на следующий этап
  • 14. Микросервисы. Наш опыт Принял - Разобрал - общение в обратную сторону Отдельные сервисы отвечающие за i. Конфигурацию ii. Состояние выхода
  • 15. Микросервисы. Наш опыт Обработал - Сохранил 1. Orleans - отдельный доклад 2. Новый сервис - Data Provider 3. Входные данные: сенсоры -> Выходные: состояния
  • 16. Микросервисы. Наш опыт Проанализировал - Уведомил 1. Проанализировал - это снова-таки новое состояние, до этого у нас снова была реализация через очередь 2. Остаётся только “Уведомил” Сообщество предпочитает другой подход: умные конечные точки и глупые каналы. Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными — они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. - Martin Fawler
  • 17. Микросервисы. Наш опыт Принял - Разобрал, где здесь микросервис? 1. Минимальные отличия друг от друга - только в “Разобрал”, много общего codebase’a! Но это всё равно разные сервисы! 2. Манипуляции с входными данными для разделения потоков обработки 3. Независимые деплои - только разрыв соединения, небольшие бутстрап задачи 4. Codebase может быть и разным! Очень полезно когда занимаешься рефакторингом и/или апгрейдом библиотек 5. Раздельные сервисы можно останавливать/запускать когда тебе нужно (тестовые запуски, течёт память)
  • 18. Микросервисы. Наш опыт Необходимость нескольких окружений 1. Параллельно в разработке несколько фич 2. Из-за микросервисных решений - макро коммуникации 3. Завести окружение - это еще та задача, нужна автоматическая подготовка окружения
  • 19. Микросервисы. Наш опыт Нужно все равно следить за всем! В микросервисном подходе добавляются проблемы с их интеграцией между собой: - Совместимость API - Нагрузка, хоть она и внутренняя - Время отклика
  • 20. Микросервисы. Наш опыт Почему микросервисы еще важны - Переезд на новое железо / в новый ДЦ / в облака - Все и сразу - такого не бывает - Если делалось все правильно в staging окружении - уже легче
  • 21. Микросервисы. Наш опыт Недостатки: высокая сложность эксплуатации - DevOps-составляющая. - Много технологий и библиотек - Согласование версий API - Интеграционное тестирование