Вопрос проектирования систем: управление подключением к БД на уровне n с балансировкой нагрузки - PullRequest
Новая
       18

Вопрос проектирования систем: управление подключением к БД на уровне n с балансировкой нагрузки

2 голосов
/ 27 августа 2009

Меня интересует наилучший подход к разработке диспетчера соединений с БД для n-уровневой системы с балансировкой нагрузки.

Классический n-ярус выглядит так: 

Client -> BusinessServer -> DBServer

Решение балансировки нагрузки, как я вижу, будет выглядеть так: 

                    +--> ...            +--+
                    +--> BusinessServer +--+--> SessionServer --+
Client -> Gateway --+--> BusinessServer +--|                    +--> DBServer
                    +--> BusinessServer +--+--------------------+
                    +--> ...            +--+

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

Сервер сеансов, вероятно, должен находиться за пределами массива балансировки нагрузки, поскольку он управляет состоянием, которое не должно дублироваться.

За исключением каких-либо серьезных ошибок в проектировании, каков наилучший способ реализации управления подключением к БД?

Я предложил несколько вариантов, но могут быть и другие, о которых я не знаю:

  1. Ввести новый компонент Broker между DBServer и другими компонентами и позволить ему обрабатывать соединения с БД.

    • Положительным моментом является то, что все соединения могут управляться из одной точки, что очень удобно.
    • Недостатком является то, что теперь в системе есть дополнительная «единая точка отказа». Другие компоненты должны проходить через него для каждого запроса, который каким-либо образом связан с БД, что также делает это узким местом.

  2. Переместите управление соединениями с БД в компоненты BusinessServer и SessionServer и разрешите каждому обрабатывать свои собственные соединения с БД.

    • Положительным моментом является то, что не существует дополнительных "единой точки отказа" или узких мест.
    • Недостатком является то, что нет никакого контроля над возможными конфликтами и взаимоблокировками, кроме того, что может предоставить сам DBServer.

Что еще можно сделать?

FWIW: технология - это .NET, но не используются стеки, специфичные для поставщика (например, нет WCF, MSMQ и т. П.)

1 Ответ

0 голосов
/ 19 апреля 2010

В конце концов, я выбрал гибридный дизайн, упомянутый в вопросе. Я превратил Broker и SessionServer в динамические компоненты, каждый из которых затем можно настроить для запуска либо in-proc с BusinessServer, либо out-of-proc, что охватывает все возможные комбинации.

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

...