Переход от монолитной архитектуры к распределенной

https://blog.byndyu.ru/2014/05/blog-post.html

Transcript

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
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 Пример на реальном проекте
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 Redis Redis Redis
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