Почему EJB, Spring Framework, .NET Framework и т. Д. Могут масштабироваться? - PullRequest
1 голос
/ 18 февраля 2011

EJB, Spring Framework, .NET Framework и т. Д. - это разные фреймворки, но я верю, что у них есть некоторые общие проекты / архитектура / модель, которые позволяют им масштабироваться. Каковы эти общие проекты / архитектура? N-уровневая (Web / Presentation, Application, Database) архитектура? Или какие-то другие причины? Я спрашиваю об этом, как будто у меня есть устаревшая система, которую нельзя перенести на эти платформы, что мне нужно сделать, чтобы моя система могла масштабироваться?

Спасибо.

Ответы [ 2 ]

3 голосов
/ 18 февраля 2011

Масштабируемость - это очень широкий термин здесь.

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

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

Они также предоставляют множество удобных "инструментов" или функций, которые обычно легко комбинируются и используются вместе с минимальными усилиями. Простые в настройке серверы приложений или контейнеры, также обеспечивающие пулы соединений и управление транзакциями, мониторинг и т. Д. Обмен сообщениями. Таймеры. Объектно-реляционное отображение. Безопасность. И так далее.

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

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

Это очень широкое и поверхностное описание, каждая тема может занять целую книгу, чтобы подробно объяснить (и большинство из них делают).

0 голосов
/ 18 февраля 2011

Это больше об архитектуре, чем о используемой технологии. Большинство современных технологий обеспечивают масштабируемость.

Если вы хотите масштабировать горизонтально, вы должны иметь возможность создавать зоны без состояния, которые могут быть распределены между серверами, например, сервисами без сохранения WCF. И для таких состояний, как: webs или Workflow, вам нужна «точка соединения» для сохранения пользовательских сеансов или экземпляров рабочих процессов и так далее. Эта точка может иметь разные разновидности: распределенное кэширование или база данных. Но все это зависит от того, как вы балансируете.

Как видите, это очень большая проблема.

Надеюсь, это поможет.

...