Масштабируемость приложений
Производительность приложения
Количество строк кода при применении разных языков и средств программирования
Размер приложения
Повторное использование компонентов
Представив себе размер производственных приложений, вы поймете, почему их архитектура должна повторно использовать как можно больше компонентов. Повторное использование лежит в основе большинства приложений, поэтому не стоит считать его новой технологией или техническим прорывом, Оно применялось с самого возникновения программирования. Повторно применяемые объекты разделяют на следующие категории:
• сегменты исходного кода;
• библиотеки кода;
• библиотеки ресурсов;
• интерфейсы объектов;
• объекты, расширяемые объекты и т. д.
Принцип повторного использования не стоит ограничивать только исходным кодом. Он пригодится при стандартном процессе разработки сразу нескольких проектов или применении структур одного проекта в другом.
Размер современных производственных приложений, которые в массе своей очень велики, необходимо контролировать. Самый эффективный способ уменьшить размеры приложения — сократить объем кода. При этом важно различать объем кода, написанного человеком,
и общий объем кода. Применение современных средств разработки часто увеличивает число строк кода, а следовательно, и время выполнения. Однако современные компонентные модели разработки способны значительно уменьшить объем кода, который должны писать программисты, благодаря повторному использованию объектов и кода и применению высокоуровневых языков, объектно-ориентированных средств и механизмов автоматической генерации кода. По мере распространения языков программирования высокого уровня число строк кода, написанных человеком, сокращается.
сравнил объем кода, необходимый для реализации одной и той же программы на разных языках:«Эти значения показывают относительную выразительность различных языков, коммерческих компонентов и автоматических генераторов кода».
Результаты этого сравнения представлены в табл. 2.1.
Язык программирования Количество строк кода, созданного человеком
Ассемблер 1 000 000
С 400 000
Ada 83 220000
C++или Ada 95 175000
C++ 75 000
При создании архитектуры приложения нужно учитывать требования к его производительности и предпринять все возможное, чтобы эти требования соблюдались как в настоящем, так и в будущем. Для этого приложение следует протестировать, а в случае неудачи найти способы повышения производительности. Требования к производительности редко удается удовлетворить без дополнительной оптимизации приложения, поэтому их нужно принимать во внимание как до разработки приложения, так и в ее ходе, Для повышения производительности не нужно оптимизировать все компоненты системы — ведь пользователю важна эффективность
приложения, а не каждого компонента в отдельности. На производительность распределенных приложений влияет множество факторов: оборудование, соединения, конфигурация системы, топология приложения и т.д., не зависящих от методов кодирования компонентов и приложений, При этом всегда возможен компромисс между простотой разработки, развертывания, сопровождения и эффективностью приложения. Главное при повышении производительности — с минимальными затратами найти и устранить «узкие» места в работе
приложения. При анализе производительности, особенно на ранних стадиях разработки проекта, редко удается точно воссоздать условия, в которых он будет эксплуатироваться.
Поэтому часто единственная возможность оценить производительность в реальной среде — экстраполировать результаты тестирования. Чем точнее тестовая среда воспроизводит эксплуатационную, тем ниже вероятность ошибки экстраполяции, однако затраты на
адекватное моделирование реальной среды иногда превышают выгоды от снижения риска некорректности результатов тестирования. Для достижения требуемой производительности желательно выполнить только действительно необходимую работу. Таким образом, проверить эффективность приложения — значит уменьшить риск того, что приложение не сможет поддерживать требуемый уровень производительности, а не повышать этот уровень до предельных значений
Чтобы удовлетворить требования пользователей, архитектура приложения должна описывать не только размер программы, но и расположение оборудования, или топологию приложения. Топология определяет тип, количество и конфигурацию серверов, на которых будет выполняться приложение. Ключевой принцип создания масштабируемых надежных приложений— независимость от топологии.
Продукты, обладающие таким качеством, при увеличении нагрузки смогут работать на нескольких серверах без потери производительности. Кроме того, для повышения надежности системы приложение или его составляющие можно реплицировать в рамках кластера (кла-
стер— это группа компьютеров, логически работающих как один).
Выбор топологии определяется корпоративной политикой, существующей инфраструктурой, результатами тестирования производительности и ограничениями, связанными с реализацией.
в некоторых случаях необходимая производительность достигается на одном сервере, удовлетворяющем минимальным требованиям к производительности процессора, памяти и диска, но тестирование при этом показывает, что приложение будет работать эффективно только при масштабировании, то есть при добавлении в топологию новых серверов и распределения по ним нагрузки. Приложения можно масштабировать также, добавляя серверы бизнес-объектов и баз данных или разделяя доступ к информации. Довольно часто такое горизонтальное масштабирование — оптимальный путь повышения производительности решения, поскольку оно не требует изменения кода приложения. К тому же затраты на новое оборудование, как правило, меньше расходов на разработку и
тестирование, связанное с модификацией программного обеспечения, что особенно заметно в сравнении с полученным таким образом приростом производительности. Масштабирование увеличивает расходы на администрирование, но прибыль от роста эффективности системы окупает их.