По материалам конференции .NET разработчиков - http://dotnetconf.ru/materialy/frommonolittodistributed

1. Переход от монолитной
архитектуры к распределенной
Александр Бындю
http://byndyu.ru
8-я конференция .NET разработчиков
6 апреля 2014
dotnetconf.ru

2. 2
Обо мне
1. Владелец компании ByndyuSoft http://byndyusoft.com
2. Консультант по вопросам разработки приложений и организации работы IT
компаний, Certified CIAgile Professional
3. Внештатный сотрудник Академии АйТи
4. Технический блог http://blog.byndyu.ru
5. Преподаю в ЮУрГУ и ЧелГУ
6. Тренер на AgileCamp
7. Организую конференции .NET-разработчиков
http://dotnetconf.ru
8. Веду группу по проблемам разработки приложений
https://groups.google.com/forum/?hl=ru&fromgroups#!forum/dotnetconf

3. 3
Требования рынка
1. Много данных
2. Много пользователей
3. Быстрое масштабирование
4. Быстрое внесение изменений

4. 4
Теорема CAP
1. Consistency
(согласованность данных)
2.Availability
(доступность)
3.Partition tolerance
(устойчивость к разделению)

5. 5
Теорема CAP
Выбираем любые два свойства
A C
P

6. 6
Какие реализации?
Consistency + Availability
(MSSQL на сервере)
Consistency + Partition tolerance
(MSSQL на кластере с транзакцией)
Availability + Partition tolerance
(NoSQL решения)

7. 7
Consistency + Availability
Надежность,
Предсказуемость,
Исторически так
сложилось

8. 8
1. Создаем UI
2. Сборку BL
3. Сборку DAL
4. Создаем DB
5. …
6. Profit!
UI
Services
BL
DAL
DB

9. 9
Website Сервис1 Сервис2
Shared DB
CA

10. 10
DB
Get data Set data
Set data Get data

11. 11

12. 12
Решим проблему с нагрузкой на
чтение данных

13. 13
Что делать?
1. Оптимизировать скрипты выборки
2. Убираем ORM для лучшей оптимизации
3. Убираем весь код выборки в хранимки
4. Оптимизируем индексы
5. Денормализуем данные

14. 14
Денормализация v1.0
Создать дополнительные колонки в текущих
таблицах
SELECT pt.Code
FROM Products p
INNER JOIN ProductType pt ON
p.ProductTypeID = pt.ProductTypeID
WHERE p.ProductID = 20

15. 15
Денормализация v2.0
Создать отдельные таблицы/view для
денормализованных данных

16. 16
Денормализация v3.0
Создать еще одну БД (хранилище) c
«плоскими» данными для чтения
1. Отдельная реляционная БД с «плоскими»
данными без связей
2. Различные NoSQL
3. Поисковые системы

17. 17
cRud
1. «Плоский» SQL
2. NoSQL
3. Поисковые системы
4. Кэши
5. …
«Плоские» данные
UI
Только
выборка

18. 18
CrUD
1. Domain-driven design (DDD)
2. N- tier, onion,… architecture
3. ORM (NHibernate, Entity Framework,…)
Приложение
База
данных
Presenter
UI
Domain Model
Validation
...

19. 19
Отделяем чтение от записи
Приложение
MongoDB
Command
UI
Domain Model
Validation
...
Query Query Model
База
данных
Redis
Sphinx
...

20. 20
Горизонтальное масштабирование
• Cassandra
• ElasticSearch
• Couchbase
• …
Client
Node1
Node2
Node3
...
MongoDB
Redis
Sphinx
...

21. 21
Облачная инфраструктура
Масштабируемся в один клик!
Даешь больше равноценных нодов!

22. 22
ложение
MongoDB
Domain Model
Validation
...
Query Model
База
данных
?
Redis
Sphinx
...
Как синхронизировать
хранилища?

23. 23
Обновляем синхронно
Приложение
MongoDB
mand
Domain Model
Validation
...
uery Query Model
База
данных
Redis
Sphinx
...

24. 24
Приложение
MongoDB
mmand
Domain Model
Validation
...
uery Query Model
База
данных
Redis
Sphinx
...
С
о
б
ы
т
и
е
С
о
б
ы
т
и
е
Ш
и
н
а
д
а
н
н
ы
х
Обновляем асинхронно

25. 25
BASE-архитектура
Availability + Partition tolerance
1. Basically Available
(сбой в некоторых узлах не приводит к отказу в обслуживании)
2. Soft-state
(не согласованное состояние)
3. Eventually consistent
(в конце концов информация будет консистентна)

26. 26
Eventually consistent
Какое время уйдет
на синхронизацию?

27. 27
Пример из проекта с Couchbase

28. 28
Чтение данных разгрузили,
что с записью?

29. 29
Website Сервис1 Сервис2
Shared DB
CA

30. 30
Очереди сообщений
Отправитель Получатель
1. Создание 5. Обработка
2. Отправка
3. Доставка
4. ОтправкаКанал

31. 31
DB
1. Сервисы
сбора данных
1. Сервисы
сбора данных
Сервис1
1. Сервисы
сбора данных
1. Сервисы
сбора данных
Сервис2
1. Сервисы
сбора данных
1. Сервисы
сбора данных
Сервис3
1. Сервисы
сбора данных
1. Сервисы
сбора данных
...
Шина сообщений
Событие Событие Событие Событие

32. 32
Инструменты для очереди
Утилиты:
1. RabbitMQ
2. NServiceBus
3. ActiveMQ
Облачные инструменты:
1. IronMQ, SQS
2. Windows Azure Queues

33. 33
Пример на
реальном проекте

34. 34

35. 35

36. 36
1. Сервисы
сбора данных
2. Скачивание
HTML
3. Создание
сущностей
4. Анализ
данных
DB
+ Fulltext Search
Sphinx
Веб-приложение

37. 37
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
2. Скачивание
HTML
3. Создание
сущностей
4. Анализ
данных
DB
Fulltext Search
Sphinx
Веб-приложение
Шинасообщений(IronMQ)
AWS S3

38. 38
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
1. Сервисы
сбора данных
2. Скачивание
HTML
3. Создание
сущностей
4. Анализ
данных
DB
Веб-приложение
Шинасообщений(IronMQ)
AWS S3
Sphinx
Sphinx
Sphinx
Sphinx
RedisRedisRedis

39. 39
Полезные ссылки
1. Eventually Consistent – Revisited, Werner Vogels
2. If You Have Too Much Data, then 'Good Enough' Is Good
Enough, Pat Helland
3. Ошибки в системах баз данных, согласованность "в
конечном счете" и теорема CAP, Майкл Стоунбрейкер
4. CAP theorem, Wikipedia
5. Reporting Database, Martin Fowler
6. BASE: An Acid Alternative, Dan Pritchett

40. 40
Спасибо за внимание!
Буду рад ответить на ваши
вопросы лично или через:
blog.byndyu.ru
alexanderbyndyu
alexander.byndyu@gmail.com