$30 off During Our Annual Pro Sale. View Details »

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

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

Alexander Byndyu

April 21, 2014
Tweet

More Decks by Alexander Byndyu

Other Decks in Technology

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

  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 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