Слайды доклада с конференции dotnetconf в апреле 2014 в Челябинске. Серверная разработка в .NET исторически ассоциируется с Enterprise архитектурами и монолитным кодом, который сложно и дорого поддерживать. Мы поговорим о принципах построения micro-services архитектур, когда достаточно сложная система складывается из небольших приложений в 200-300 строчек кода. Этот подход достаточно часто встречается в Linux среде, но некоторые моменты довольно успешно переносятся и в сторону .NET

1. Ринат Абдуллин
HappyPancake
twitter.com/abdullin
8-я конференция .NET разработчиков
6 апреля 2014
dotnetconf.ru
Micro-services
Упрощаем монолитные приложения

2. Обо мне
• До 2014 - .NET Tech Lead в lokad.com
• C 2014 - разработчик в HappyPancake
• Блог - abdullin.com / twitter.com/abdullin
• Подкасты
• BeingTheWorst.com
• DistributedPodcast.com
• Happy Friday : RD.HappyPancake.com
• Я еще только учусь

3. План
• Что такое micro-services?
• Опыт применения в .NET компании
• Опыт применения в !.NET компании

4. Архитектура в .NET
N-Layered Architecture

6. А в другой галактике
Micro-services holy wars raged

8. Fred George
https://twitter.com/fgeorge52
Computer Anarchist

9. James Lewis
https://twitter.com/boicy
Consultant at ThoughtWorks

10. Stefan Tilkov
https://twitter.com/stilkov
CEO at InnoQ

11. Martin Fowler
https://twitter.com/
martinfowler
Programmer at
ThoughtWorks

12. Micro-Services
Что это такое?

13. Монолит vs Компоненты
Весь функционал
в одном процессе
Каждый элемент
в отдельном процессе

14. Монолит vs Компоненты
Масштабирование

15. Это уже было!
• Service-Oriented Architecture
• Enterprise Integration Patterns
• SOAP, WS-*, ESB
!
• Или “micro-services с вредными привычками”

16. Micro-services
• Новое название для старого подхода
• Просто нормальный Service-oriented design
• Без фанатичного использования технологий

17. Архитектура
это “побочный эффект”

18. Нас интересует
процесс
Micro-services - это лишь результат

20. Как разбить монолит?
“Protective bubble”

21. Разбить
непросто

22. Методики
• Domain-driven analysis
• Event storming
• Transaction boundaries
• Technological requirements
• Существующие команды
• Существующие продукты

23. Где узнать больше?
• Fred George: http://vimeo.com/79866979
• James Lewis: http://vimeo.com/74452550
• Martin Fowler: http://martinfowler.com/articles/
microservices.html
• Stefan Tilkov : http://www.infoq.com/presentations/
Breaking-the-Monolith

24. Опыт в Lokad.com

25. Lokad.com
• Основана в 2008 в Париже
• BigData аналитика для
торговых сетей
• ~6 разработчиков
• ~5 продуктов
• ~15 git repositories
• .NET & Windows Azure

26. История одного
приложения
Lokad.HUB

27. Что такое Lokad HUB
• Регистрация
• Управление аккаунтами
• Статистика
• Авторизация
• Биллинг
• Администрирование
• Платформа + Web UI
• Windows Azure
• API : JSON + HTTP
• ~99% SLA
• ~10 запросов в секунду
• 99% < 18ms
• 200000 events
• Простая как пень

28. Lokad Hub 2008
ASP.NET + SQL

29. Проблемы 2008
• SQL + CRUD
• Угадайте, где бизнес логика
• Монолитная архитектура - сложно менять
• Не любит Windows Azure

30. Решение
• Domain-Driven Design
• CQRS + EventSourcing
• Event-Driven Design
• Lokad.CQRS

31. Процесс
• Отчаянное прототипирование
• Отчаянное разделение на Bounded Contexts
• Общаются между собой сообщениями
• Каждый BC - строится из кирпичиков

32. Кирпичики
Lokad.CQRS
Это сработало, но было ошибкой

33. 1. Aggregate with ES
Источник событий

34. 2. Projection
Проецирует события во вьюхи

35. 3. Process
Реализация бизнес-процессов

36. 4. Workflow
Связывание раздельных контекстов

37. –Из опыта
“Детали реализации каждого компонента -
это только его собачье дело.”

38. Lokad Hub 2011
Lokad.CQRS + Windows Azure

39. Lokad Hub 2011
• 5 bounded contexts
• Event Sourcing rules
• Команда обожает Views
• Быстрые итерации
• Работает как локально так и
в Azure
• Про проект написали в
Microsoft P&P CQRS Journey

40. Проблемы
• Все еще монолит
• Плохая производительность
• Функционал повторяется в
других системах
• Building blocks все
усложняют
• Команда ругается

41. Решение
• Разбить все на компоненты
• Пусть компоненты общаются по HTTP
• Дизайн каждого компонента - это его дело
• Компоненты должны быть простыми

42. Lokad Hub 2013

43. Простой Stack
Только самое нужное

44. Простой
дизайн

45. Код == дизайн

46. Компоненты
просты

47. Самый сложный компонент
Все остальные - проще

48. Жизнь компонента
У каждого - свой путь

49. Плюшки
• Fiddler + wrk + weighttp
• Авто-генерируемая документация
• Полная статистика
• Разработчикам очень просто начать работать
• Апгрейды без отключений

50. Узнать больше
http://beingtheworst.com

51. Опыт за
пределами .NET
HappyPancake

52. HappyPancake.com
• Крупнейшая сеть знакомств в
Швеции
• Каждый 10-й швед в сети
• Норвегия и Финляндия
• Бесплатная, доход за счет
рекламы
• С 2014г - 3 разработчика

53. HPC 2013
Работает

54. Проблемы
• ASP.NET + SQL
• Бизнес-логика - сами знаете
где
• Плохо масштабируется
• Сложно разрабатывать

55. Требования
• Простая архитектура из небольших компонентов
• 99% запросов (без кэша) - быстрее 25ms
• при 25000 запросов в секунду
• в виртуализированной среде
• Linux
• event-sourcing (для аналитики)

56. HPC 2014
В разработке

57. Stack
• Ubuntu 12 LTS
• Go
• FoundationDB
• Sublime / Vim
• Docker
• Statsd + Librato Metrics
• Logsd + Logentries

58. Sublime IDE
или vim/emacs

59. Design
• Вся логика - в одном сервере
• Несколько экземпляров сервера за load balancer
• Сервер состоит из компонентов
• FoundationDB кластер для хранения
• Event-driven design + CQRS + Domain-driven
design

60. Хотелки
• Подключение новых компонентов “на лету”
• Feature toggling
• Ghost mode
• Ramp up

61. HPC 2015
В планах

62. Планируется
• + NanoMsg
• + ETCD
• + Drone.io
• + Quay.io

63. Узнать больше
http://rd.happypancake.com

64. Вопросы?
http://twitter.com/abdullin