97 этюдов для архитекторов программных систем

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

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

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

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

Крейг Рассел (Craig Russell) — практикующий архитектор программного обеспечения, специализирующийся на персистентности объектов (object persistence) и распределенных системах. В настоящее время paботает ведущим специалистом в компании Sun Microsystems.

Проектирование в пустоте

Майкл Найгард

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

Одна маленькая стрелка может означать: «Синхронный запрос/ответ в формате SOAP-XML через HTTP». Для одного элемента диаграммы получается слишком много информации. Места для полной записи обычно не хватает, поэтому мы помечаем стрелку надписью «XML через HTTP» (с точки зрения внутренней реализации) или «Поиск по коду товара» (с точки зрения внешних пользователей).

Стрелка, связывающая программы, выглядит как непосредственный контакт, но в действительности им не является. Пустота между прямоугольниками заполнена аппаратными и программными компонентами. В частности, здесь могут находиться:

• Сетевые карты

• Сетевые коммутаторы

• Брандмауэры

• Системы обнаружения и предотвращения вторжений (IDS/IPS)

• Брокеры или очереди сообщений

• Механизмы преобразования XML

• Серверы FTP

• Зонные таблицы

• Кольца SoNET

• Шлюзы MPLS

• Магистральные линии

• Океаны

• Рыболовные траулеры, повреждающие донные кабели

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

Однажды я видел стрелку с надписью «Исполнение». Один сервер был установлен в компании моего клиента, второй находился совершенно в другом месте. Эта жизненно важная для клиента стрелка запускала цепочку событий, которая больше напоминала игру «Мышеловка», нежели единый интерфейс. Сообщения передавались брокерам, сохраняющим их в файлах, которые периодически запускаемыми заданиями загружались на FTP… и т. д. Этот «интерфейс» включал в себя более 20 этапов.

Необходимо хорошо понимать, какая статическая и динамическая нагрузка ложится на каждую стрелку. Рядом с «SOAP-XML через HTTP» около стрелки стоило бы написать также: «С каждым запросом HTTP принимается одно обращение, с каждым ответом HTTP возвращается один ответ. Ожидается до 100 запросов в секунду, ответ в 99,999 % случаев должен выдаваться менее чем за 250 мс».

Но и это еще не все, что необходимо знать об этой стрелке: