Проблемы распределения и масштабирования

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

♦ Масштабирование «вверх» (вертикальное масштабирование) подразуме­вает введение новых вычислительных и системных ресурсов ~ например, расширение памяти на отдельной машине. Эта разновидность масштабиро­вания применима в том случае, если во внутренней архитектуре сервера приложений нет «врожденных» узких мест. Если это так, то при введении дополнительных системных ресурсов и повышении мощности процессора программное обеспечение сервера приложений должно полностью освоить новые ресурсы и тем самым повысить пропускную способность системы.

♦ Масштабирование «вширь» (горизонтальное масштабирование) компенсиру­ет неизменность производительности существующей машины распределе­нием сервера приложений между несколькими машинами. При предостав­лении приложению дополнительных машин суммарные системные ресурсы и производительность повышаются.

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

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

♦ Дополнительное резервирование. Если на одной машине произойдет отказ, ее функции возьмут на себя другие. Среди причин отказов — нарушение электроснабжения, сетевые сбои, аварийные отказы операционной систе­мы, отказы сервера приложений и даже ошибки в прикладном коде.

♦ Экономическая эффективность. Соотношение «цена/производительность» для сети машин с относительно небольшой производительностью иногда превосходит соответствующий показатель для одной высокопроизводитель­ной машины.

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

Распределенные транзакции

Многие EJB-серверы способны координировать транзакции с участием несколь­ких объектов из разных процессов в распределенной системе. При конструирова­нии корпоративных систем возможность обработки распределенных транзакций посредством двухэтапного протокола фиксации зачастую играет очень важную роль.

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

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

Опыт применения разных peaлизaцийJ2EE и механизмов управления объект­ной технологией свидетельствует о высокой вариативности показателей произ­водительности управления распределенными транзакциями. Таким образом, ар­хитекторы приложений должны хорошо ориентироваться во всех вариантах конфигурации и размещения, возможных в рамках данной службы транзакций.

Организация пула ресурсов

В распределенной системе следует уделять особое внимание управлению ресур­сами приложения — в частности, соединениями с базами данных и сокетами.

Методика организации пула ресурсов основывается на том обстоятельстве, что постоянный монопольный доступ к ресурсам требуется далеко не всем клиентам. В контексте EJB не каждому bean требуется монопольное соединение с базой данных. Значительно более эффективной представляется такая конфигурация системы, при которой соединения с базой данных организуются в рамках пула и многократно распределяются между различными клиентскими транзакциями.

В случае применения пула соединений с базой данных конечных соединений оказывается значительно меньше, чем в размещенной системе EJB-компонентов. Поскольку создание соединений с базой данных и управление ими — операции весьма дорогостоящие, такая архитектура повышает общую масштабируемость приложения. Более того, за счет того что необходимость постоянного восстанов­ления соединений отсутствует, повышается производительность приложения.

Методика организации пула применима и к другим ресурсам — в частности, к сокетным соединениям и потокам. Организация пула компонентов предполага­ет, что выделять для каждого клиента специализированный ресурс не требуется. Среди стандартных настраиваемых параметров — контейнерные потоки, экземп­ляры сеансовых beans, емкость кэша bean-сущности и размер пула соединений с базой данных. Путем продуманной настройки этих параметров сокращается вре­мя отклика и повышается общая пропускная способность системы.