Высокая масштабируемость в доменно-управляемом дизайне - PullRequest
0 голосов
/ 13 июня 2011

Я использую DDD для сервис-ориентированного приложения, предназначенного для передачи большого объема сообщений между большим количеством веб-клиентов (т. Е. Браузеров).

Поскольку в контексте требуемой функциональностипотребность в передаче перевешивает потребность в хранилище, мне нравится идея полагаться в первую очередь на оперативную память и минимизировать использование базы данных.

Однако мне неясно, как сконструировать это с точки зрения масштабируемости.Веб-ферма обеспечивает высокую доступность конечных точек служб и обработку логики домена.Но независимо от того, сколько у меня серверов, кажется, что все они должны иметь общий репозиторий, чтобы их данные были согласованными.

Как мне построить этот репозиторий, чтобы он был максимально масштабируемым?Как его можно распределить по массиву физических машин таким образом, чтобы все машины были согласованы и каждому было наплевать, если другой выйдет из строя?

Также, поскольку иногда требуется прикосновение к базе данных (например,когда клиент пропадает и сообщения, предназначенные для него, должны быть сохранены до его возвращения), как мне организовать мой код на основе памяти и уровень доступа к данным?Они оба считаются "хранилищем"?

Ответы [ 2 ]

2 голосов
/ 13 июня 2011

Есть несколько способов решить эту проблему.Ни один ответ не может охватить все это ...

Один из способов обеспечить масштабируемость - просто масштабировать аппаратное обеспечение .Напишите, что ваши веб-службы не имеют состояния, чтобы вы могли запустить веб-ферму (все с одинаковыми службами, указывающими на одну и ту же БД) и превратить вашу БД в кластер.Кластерные базы данных работают на нескольких серверах и работают в одном хранилище.Однако этот сценарий может стать сложным и дорогим довольно быстро.

Некоторые интересные ссылки:

Другой метод - посмотреть на архитектуру .CQRS - это общая архитектурная модель, обеспечивающая масштабируемость.Например, эта архитектурная модель - ее название расшифровывается как разделение ответственности команд / запросов - создает различные базы данных для чтения и записи.Это кажется противоречивым, но если вы изучаете это, оно становится естественным, и вы удивляетесь, почему вы никогда не думали об этом раньше.Проще говоря, большинство приложений читают намного больше, чем пишут, а написание, как правило, намного сложнее, чем чтение (требует проверки бизнес-правил и т. Д.), Так почему бы не разделить их?Вы можете использовать свою дорогостоящую транзакционную базу данных для записи, а затем свою дешевую, возможно, не основанную на SQL или открытую базу данных на нескольких серверах чтения.Затем ваша модель чтения оптимизируется для экранов вашего приложения, в то время как модель записи оптимизирована исключительно для записи и фактически представляет собой набор репозиториев на основе DDD.

Здесь просто недостаточно места дляподробно рассмотрим эту опцию, но CQRS - это хороший способ достижения масштабируемости и даже простоты разработки, если у вас есть инфраструктура CQRS.У CQRS есть много других преимуществ, таких как простота аудита (если вы комбинируете его с техникой «источников событий», которая распространена в средах на основе CQRS).

Некоторые интересные ссылки:

0 голосов
/ 13 июня 2011

Вы готовы к чтению? Есть много вариантов, но я считаю, что вы должны начать с изучения преимуществ современных распределенных баз данных NoSQL и получать удовольствие от изучения опыта, накопленного в facebook, linkedin и других друзьях. Начните здесь:

...