Производительность .NET ESB

Question

Я начинаю разрабатывать новую версию одного из телекоммуникационных продуктов моей компании, и для обеспечения балансировки нагрузки и масштабируемости я рассматривал какую-то разновидность (.NET с открытым исходным кодом) ESB.Я надеюсь повысить пропускную способность системы, избегая реляционных баз данных и используя (возможно) нетранзакционные очереди, поступающие в распределенные кэши в памяти (например, Velocity или memcached).

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

Я только играл с NServiceBus, так что я не знаю, подходит ли он (или его братья) в качестве основы для приложений без поддержки SQL в реальном времени.Как вы думаете?

Как мне судить об этих продуктах?Стоит ли вместо этого покупать коммерческое приложение, избегать ESB, как чума, или использовать какой-то другой подход?

Answer 1

Андрей

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

Когда вы говорите в режиме реального времени, очевидно, что вы не говорите о сложном режиме реального времени здесь - как вы все еще в Windows, и даже тогда не программируете на C / C ++. Другими словами, похоже, что главная цель - пропускная способность, а не низкая задержка. Я думаю, вы найдете, что ESB могут работать очень хорошо для вас.