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.

Микросервисные архитектуры и немного жизненного опыта

3,661 views

Published on

Published in: Technology

Микросервисные архитектуры и немного жизненного опыта

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

×