Downloaded 15 times
Uploaded byDataArt
«Microservices. Как правильно делать и когда применять?»
Доклад посвящен микросервисам, их преимуществам и недостаткам, а также сравнению с монолитными архитектурами. Рассматриваются основные характеристики микросервисов, принципы их взаимодействия и архитектурные подходы, такие как SOA и event-driven architecture. Дается рекомендация по выбору между монолитом и микросервисами в зависимости от бизнес-контекста и командной структуры.
More Related Content
Similar to «Microservices. Как правильно делать и когда применять?»
«Microservices. Как правильно делать и когда применять?»
- 1. Microservices Pros and cons. SpeakerVyacheslav Mikhaylov (vmikhaylov@dataart.com) IT Talks 1
- 2. О чем доклад? •Что такое микросервисы? • Немного теории • За и против различных типов архитектур • Способы взаимодействия сервисов • Когда делать монолит, а когда микросервисы? 2
- 3.
- 4. Монолит 4 User Interface Business LogicLayer Data Access Layer DataBase
- 5. Монолит 5 User Interface (App1) BusinessLogic Layer Data Access Layer DataBase User Interface (App2) Business Logic Layer Data Access Layer
- 6. Проблемы 6 • Растет сложностьсистемы • Сложно поддерживать • Не разобраться
- 7. Проблемы 7 • Много багов •Мало тестов • Дорого вносить изменения
- 8. Проблемы 8 • Застревание натехнологиях
- 9.
- 10. Развитие системы 10 • Каксделать систему доступной из разный регионов? • Как обеспечить согласованность данных? • Как ускорить систем в N раз?
- 11.
- 12. CA – consistency+ availability • Данные во всех узлах согласованы • Обеспечена доступность • Жертвуем распадом на секции • ACID • классические монолиты 12
- 13. CP – consistency+ partitioning • Данные во всех узлах согласованы • Способна разделяться на независимые секции • Жертвуем отсутствием отклика (долго согласуются транзакции) • Монолиты, которым пришлось скалироваться. 13
- 14. AP – availability+ partitioning • Система доступна с предсказуемым временем отклика • Система распределена • Отказ от целостности результата. • Eventually consistent • DNS 14 - Знаете как заинтересовать идиота? - Как? - Завтра расскажу
- 15. Развитие системы 15 • Каксделать систему доступной из разный регионов? • Как обеспечить согласованность данных? • Как ускорить систем в N раз? НИКАК!
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22. Что такое Микросервисы? Архитектурныйпаттерн в котором сервисы: • Small • Focused • Loosely coupled • Highly cohesive 22
- 23. Small • Насколько маленький? •Разрабатывается одной командой (7±2) • Одна бизнес задача • Один человек в состоянии понять сервис 23
- 24. Focused • Что значитсфокусированный? • Решает только одну бизнес задачу, но решает ее хорошо • Имеет смысл в отрыве от остальных сервисов 24
- 25. Low coupled • Чтотакое сильное зацепление и слабое зацепление? • Изменения одного класса/модуля слабо влияет на необходимость изменений другого • IoC, DI 25
- 26. High cohesion • Высокоесцепление (согласованность) • Класс/компонент содержит все нужные методы для решения поставленной задачи 26
- 27. High cohesion vsSRP • У нас есть класс, отвечающий за управление кухней • SRP – Класс содержит методы по управлению только КУХНЕЙ • HC – Класс содержит ВСЕ методы по управлению кухней 27
- 28. Характеристики микросервисов • Разделениена компоненты (сервисы) • Группировка по бизнес задачам • Сервисы имеют бизнес-смысл • Умные сервисы & простые коммуникации • Децентрализованное управление • Децентрализованное управление данными • Автоматизация развертывания и мониторинга • Design for failure (Chaos Monkey) 28
- 29.
- 30.
- 31. Характеристики микросервисов • Разделениена компоненты (сервисы) • Группировка по бизнес задачам • Сервисы имеют бизнес-смысл • Умные сервисы & простые коммуникации • Децентрализованное управление • Децентрализованное управление данными • Автоматизация развертывания и мониторинга • Design for failure (Chaos Monkey) 31
- 32. Группировка по бизнесзадачам 32 UI BL DB Order Management Order Execution Market Data
- 33. Характеристики микросервисов • Разделениена компоненты (сервисы) • Группировка по бизнес задачам • Сервисы имеют бизнес-смысл • Умные сервисы & простые коммуникации • Децентрализованное управление • Децентрализованное управление данными • Автоматизация развертывания и мониторинга • Design for failure (Chaos Monkey) 33
- 34. Умные сервисы &простые коммуникации 34 ESB
- 35. Умные сервисы &простые коммуникации 35 ESB
- 36. Характеристики микросервисов • Разделениена компоненты (сервисы) • Группировка по бизнес задачам • Сервисы имеют бизнес-смысл • Умные сервисы & простые коммуникации • Децентрализованное управление • Децентрализованное хранение • Автоматизация развертывания и мониторинга • Design for failure (Chaos Monkey) 36
- 37. Децентрализованное хранений 37 Service AService B Service C Service C
- 38. Сетевое взаимодействие 38 Service AService B Service C Service C
- 39.
- 40.
- 41.
- 42.
- 43.
- 44. Разные типы архитектур •Service Discovery (RPC Style) • Message Bus (Event Driven) • Hybrid 44
- 45.
- 46. 46 Service Discovery (Server– Side)
- 47. Service Discovery (Client– Side) 47
- 48. Message Bus • Нужноуметь готовить • Нужно поддерживать • Снижение производительности за счет появления брокера 48
- 49. Message Bus 49 ЗА ПРОТИВ Диктуетархитектуру Сложно менять контракты Легко расширять Обычно асинхронны Построена для скалируемости Нужна хорошая квалификация Круто звучит Сложности развертывания и поддержки Есть готовые решения. Написано не нами
- 50.
- 51.
- 52.
- 53. Переход от монолитак микросервисам • Ограниченный бизнес контекст • Частота изменений • Структура команды (Conway’s law) • Меняем то, что сильнее болит 53
- 54.
- 55. Как выбрать? 55 Монолит Микросервисы Новыйдомен, нет знаний домена Прототипы, Быстрое решение Низкая квалификация (все джуны) Написал и забыл Мало денег
- 56. Как выбрать? 56 Монолит Микросервисы Новыйдомен, нет знаний домена Точно нужно будет скалировать линейно Прототипы, Быстрое решение Мы можете обеспечить согласованность на бизнес уровне Низкая квалификация (все джуны) Высокая квалификация, есть опыт и пара загубленных проектов в прошлом Написал и забыл Готовы инвестировать в инфраструктуру Мало денег Много денег
- 57. За и против 57 Микросервисыдают преимущества… За счет… Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков. Distribution Тяжелее разрабатывать. Нужен опыт и хороший опыт. Аvailability Сервисы могут работать не все Eventual Consistency придется иметь дело со слабой (отложенной) целостностью Technology Diversity Легко менять технологии, пробовать что-то действительно подходящее. Правильные инструменты Operational Complexity Опытная команда Devop’ов Independent Deployment Простые сервисы проще деплоить Меньше вероятность отказа системы
- 58. Jeff Bezos Manifesto •All teams will henceforth expose their data and functionality through service interfaces. • Teams must communicate with each other through these interfaces. • no direct linking • no direct reads of another team’s data store • no shared-memory model • no back-doors whatsoever. • The only communication allowed is via service interface calls over the network. • It doesn’t matter what technology they use. • All service interfaces, without exception, must be designed from the ground up to be externalizable. • No exceptions. 58
- 59. Источники • https://www.nginx.com/blog/ • https://www.nginx.com/blog/introduction-to-microservices/ •https://www.nginx.com/blog/building-microservices-inter-process-communication/ • http://plainoldobjects.com/presentations/decomposing-applications-for-deployability-and-scalability/ • http://highscalability.com/blog/2016/2/10/how-to-build-your-property-management-system-integration-usi.html • https://lostechies.com/gabrielschenker/2016/01/27/service-discovery/ • http://microservices.io/ • http://martinfowler.com/articles/microservices.html 59
- 60. Thank you To becontinued…
Editor's Notes
- #15 Большинство NoSQL-систем принципиально не гарантируют целостности данных, и ссылаются на теорему CAP как на мотив такого ограничения[5]. Задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных, в этом смысле про AP-системы говорят как о «целостных в конечном итоге» (англ. eventually consistent)[15] или как о «слабо целостных» (англ. weak consistent)[16].
- #22 Большинство NoSQL-систем принципиально не гарантируют целостности данных, и ссылаются на теорему CAP как на мотив такого ограничения[5]. Задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных, в этом смысле про AP-системы говорят как о «целостных в конечном итоге» (англ. eventually consistent)[15] или как о «слабо целостных» (англ. weak consistent)[16].
- #23 Набор правил, как одно приложение или компонет взаимодействует с другими. И механизм, который обеспечивает это взаимодействие Обычно это не про UI Взаимодействие виде Software-to-software (Component)
- #24 Размер микросервисов – единственная вещь про которую программисты могут гордиться у кого меньше Two pizza team at amazon
- #26 Проблема перевода
- #33 Convey’s Law
- #40 Есть три вещи которые все говорят что делают Подростковый секс DevOps ОЧЕНЬ ВАЖНО. Новый компы, развертывание, мониториг, отладка
- #50 Строгие контракты
- #51 Строгие контракты
- #52 Строгие контракты
- #53 Строгие контракты
- #54 The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context.
- #55 The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context.
- #56 The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context.
- #57 The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context.