Downloaded 40 times
Uploaded byElena Grahovac
Микросервисные архитектуры и немного жизненного опыта
Доклад посвящен микросервисным архитектурам, включая их определение, преимущества и недостатки по сравнению с монолитами. Обсуждаются ключевые принципы проектирования микросервисов, а также условия и этапы перехода от монолита к микросервисам. В конце представлены полезные ресурсы для более глубокого изучения темы.
More Related Content
Микросервисные архитектуры и немного жизненного опыта
- 1. Микросервисные архитектуры и немного жизненногоопыта Елена Румянцева апрель 2015
- 2. О чем доклад? Чтотакое микросервисы и зачем они нужны SOA и MSOA: сходства и различия Предусловия для перехода на (M)SOA Как выделить микросервисы из монолита? Бонус: что читать для погружения в тему 2
- 3.
- 4.
- 5. Принцип единственной обязанности Howsmall is small? Переписать за две недели Организация кода и опыт 5 Размер
- 6. Отдельные «приложения» наразных машинах? «-»: Накладные расходы «+»: Проще строить распределенные системы 6 Автономные
- 7. Сервис должен уметьразворачиваться самостоятельно вне зависимости от наличия или отсутствия по соседству других сервисов и без изменений в других сервисах. 7 «Золотое правило»
- 8. Максимальная толерантность к изменениямсоседних сервисов Слабая связанность Коммуникация по сети Использование разных технологий и языков программирования 8 Взаимодействие
- 9.
- 10. 10 SOA MSOA ESB Простые очередии запросы Бизнес-логика в ESB Бизнес-логика на стороне потребителей данных Сложные стандарты Простые интерфейсы
- 11.
- 12.
- 13. Зачем нужны микросервисы? Быстрореализовать новую фичу Быстро интегрировать ее в существующую систему Быстро протестировать Быстро порелизить 13
- 14. Профит от сервисакак отдельностоящего приложения Не надо копаться в чужих задачах из очереди на релиз Меньше вероятности зааффектить другие сервисы из-за глупых ошибок Проще выделить зоны ответственности конкретных людей за конкретный код 14
- 15.
- 16. Асинхронность и событийность Неболее одного синхронного действия за один вызов Реакция на события, генерируемые другими микросервисами 16
- 17. Доступ к данным Сервисне меняет данные другого сервиса напрямую Использование API для изменения данных в соседнем сервисе Использование очередей 17
- 18. Request - Response(пример) 18 E Requestor Q Replier EQ
- 19. Проектирование на отказ (Design for failure) Вся система в целом должна работать так, как будто в любой момент любой из микросервисов может оказаться не доступен. 19
- 20. «Интерфейсы» vs «Кишки» «Интерфейсы»важны «Кишки» не важны 20
- 21. Как выделить микросервисы напрактике
- 22. Понимание предметной области Построениемикросервисов вокруг бизнес-услуг DDD в помощь 22
- 23. «Эволюционная архитектура» Выделяем сервисытак, чтобы их можно было безболезненно переписать с нуля 23
- 24. Взаимопонимание Владельцы сервисов иответственные лица Коллеги из DEVOPS Клиентские приложения 24
- 25. Microservice way Соответствует лито, что я собираюсь делать, идеи микросервисов? 25
- 26.
- 27.
- 28.
- 29.
- 30. Пример про импортданных Основную информацию импортируем синхронно из основного сервиса Фотки загружает и импортирует другой сервис Анализом данных занимается третий сервис 30
- 31. Клиентские приложения исервисы 31
- 32.
- 33. Специальные бэкэнды дляфронтендов 33
- 34. Начинать с монолита— проще! Откалываем по кусочкам Начинаем там, где от микросервисов будет больше пользы Уменьшаем количество коммуникаций между модулями 34 Разбиваем монолит
- 35.
- 36. «Организации, занимающиеся проектированием систем,неизбежно производят системы, повторяющие структуру их коммуникаций» 36
- 37. Вывод Чтобы успешно проектировать микросервисы,команда сама должна взаимодействовать как совокупность микросервисов «Фичатим» 37
- 38. Когда есть смыслпереходить на (микро-) сервисы Команда разработчиков уже большая или планируется ее расширение Нужно реализовать много новых крупных фич, в т.ч. новых сущностей 38
- 39. Необходимые инструменты для переходана микросервисы
- 40. «DEVOPS — нашевсё»
- 41. Необходимые инструменты для переходана микросервисы или несколько слов на «авто-» Автокопирование базовых файлов из шаблона Авторазвервертвание (и автосвертывание) микросервисов на боевых и любых окружениях Автодокументация фронтендов Автомониторинг фронтендов Автоокументирование и автомониторинг взаимодействия микросервисов между собой 41
- 42.
- 43. Не ждите чуда,чудите сами релизьте без тестирования Релизьте сырое! Релизьте с багами! Релизьте то, что еще никто не собирается использовать! 43
- 44. Другие важные темы Каквсё это тестировать? Как разворачивать микросервисы на любом окружении? Как масштабировать? Как мониторить? SLA и метрики на сервисы Аутентификация и авторизация 44
- 45.
- 46.
- 47.
- 48. SoundCloud Dealing with theMonolith https://developers.soundcloud.com/blog/building- products-at-soundcloud-part-1-dealing-with-the-monolith 48
- 49. Микросервисы — небесплатный обед http://highscalability.com/blog/2014/4/8/microservices- not-a-free-lunch.html 49
- 50.