97 этюдов для архитекторов программных систем
Шрифт:
Концепция многоязыкового программирования не нова; характерным примером из прошлого служат системы, в которых клиентская часть написана на Visual Basic и использует серверную часть на базе объектов СОМ, написанных на C++. По сути дела эта архитектура эффективно использовала сильные стороны каждого из упомянутых языков в зените их популярности.
Какие же перемены возродили интерес к многоязыковому программированию?
Новые технические стандарты в сочетании с постоянным ростом ресурсов — пропускной способности каналов и вычислительных мощностей — сделали возможным реальное использование текстовых протоколов. Те времена, когда эффективные распределенные системы были возможны лишь при использовании хитроумных двоичных протоколов, остались в прошлом. Возможность удаленного взаимодействия на текстовом
Благодаря этому новому поколению технологий у нас есть гораздо больше возможностей для гетерогенной разработки, чем когда-либо прежде, просто потому, что полезная информация теперь представляет собой отформатированный текст, который можно генерировать и обрабатывать универсальными средствами. Гетерогенная разработка позволяет для каждой конкретной задачи выбирать наиболее подходящий инструмент, а способность систем взаимодействовать на текстовом уровне сметает многие прежние преграды.
Теперь архитекторы могут объединять специализированные мощные инструменты, позволяющие вести речь уже не о способности применить подходящий язык, а о способности применить правильную парадигму. Языки программирования поддерживают различные парадигмы, некоторые из которых объектно-ориентированные, а другие функциональные или ориентированные на параллельное программирование. Для конкретных задач или предметных областей одни из этих парадигм подойдут идеально, а другие окажутся несоответствующими. Однако в наши дни эти нетрадиционные (и на первый взгляд разнородные) инструменты объединяются в элегантные гибридные решения гораздо легче, чем прежде.
Эффект этих изменений уже виден в комбинаторном увеличении сложности архитектурной топологии современных программных систем. Этот аспект — не столько отражение присущей им разнородности, сколько признак новых возможностей.
Наличие выбора не всегда полезно, но в данном случае оно является «меньшим из зол» в контексте современных программных архитектур. Наша отрасль имеет дело с очень серьезными задачами, [20] поэтому нам необходимы все возможности взаимодействия, которые только можно обеспечить, особенно если задействованные в настоящий момент платформы не очень хорошо подходят для решения этих задач. [21]
20
Надвигающаяся эпоха многоядерных процессоров вполне может оказаться самым серьезным вызовом, с которым когда-либо сталкивалось сообщество разработчиков.
21
См. статью «The Free Lunch is Over» Герба Саттера (Herb Sutter) по адресу www.gotw.ca/publications/concurrency-ddj.htm.
В наши дни работа архитектора стала еще более сложной из-за того, что границы технологий трещат под напором новых возможностей. Примите этот вызов, учитесь мыслить широко и обратите богатство возможностей в свою пользу: неоднородность побеждает.
Эдвард Гарсон (Edward Garson) стал страстным энтузиастом программирования еще с тех времен, когда учился программировать на Logo на компьютере Apple II. В настоящее время он работает архитектором программного обеспечения в Центре гибких методологий программирования в Zuhlke Engineering — одной из ведущих швейцарских технологических компаний.
Не забывайте о производительности
Крейг Рассел
Представьте себе автомобиль — просторный, удобный, экономичный, недорогой и утилизируемый на 98 %. Хотите такой? Конечно. Кто угодно захочет. Ах, да, единственная проблема: его максимальная скорость составляет 10 км/ч. Не передумали? Этот маленький
Многие архитекторы ставят производительность на последнее место в своих списках — возможно, потому, что компьютеры обрабатывают данные несопоставимо быстрее своих пользователей, и архитектору кажется, что скорость системы окажется приемлемой. А если современным системам не хватит быстродействия, обо всем позаботится закон Мура. Однако скорость работы оборудования — лишь один из аспектов системы.
Производительность иногда рассматривается просто как промежуток времени, который нужен системе, чтобы отреагировать на введенные пользователем данные. Но архитекторы систем должны учитывать разнообразные аспекты производительности, включая производительность труда аналитиков и программистов, реализующих дизайн, производительность общения пользователя с системой, а также быстродействие неинтерактивных компонентов.
Производительность труда людей, строящих систему, часто называется продуктивностью. Этот показатель весьма важен, поскольку он непосредственно отражается на затратах и графике проекта. Команда, сдающая проекты с большим опозданием и перерасходом средств, обречена на неприятные разговоры с руководством. Правильный выбор инструментов и готовых компонентов может радикально повлиять на то, как быстро система будет построена и начнет приносить прибыль.
Производительность взаимодействий с пользователем играет решающую роль в том, как пользователи примут систему. В этот аспект производительности вносят свой вклад многие факторы системной архитектуры. Самым очевидным примером, пожалуй, является время отклика, однако это далеко не единственный показатель. Не менее важны интуитивная понятность интерфейса и количество операций, которые должен выполнить пользователь, чтобы достичь своей цели; и то, и другое напрямую влияет на производительность.
Хорошая спецификация системы определяет не столько время отклика само по себе, сколько время выполнения задания. Оно определяется как промежуток времени, необходимый для решения задачи из конкретной предметной области, включая все взаимодействия пользователя с системой. Кроме времени отклика в эту характеристику входят время размышления оператора и время ввода данных оператором — величины, находящиеся вне сферы контроля системы. Однако включение этих метрик способствует качественному проектированию пользовательского интерфейса. Уделив внимание способу представления информации и количеству операций, необходимых для решения задачи, вы в конечном итоге улучшите производительность человека-оператора.
Производительность неинтерактивных компонентов не менее важна для успеха системы. Например, если на выполнение еженощно запускаемых пакетных заданий требуется более 24 часов, система становится неработоспособной. Производительность компонентов аварийного восстановления также относится к числу критических факторов. Сколько времени потребуется для восстановления работоспособности системы и продолжения нормальной работы, если одна из частей системы полностью вышла из строя?
Анализируя реализацию и рабочий режим успешной системы, архитекторы и проектировщики всегда должны обращать самое пристальное внимание на производительность.
Крейг Рассел (Craig Russell) — практикующий архитектор программного обеспечения, специализирующийся на персистентности объектов (object persistence) и распределенных системах. В настоящее время paботает ведущим специалистом в компании Sun Microsystems.
Проектирование в пустоте
Майкл Найгард
Система состоит из взаимозависимых программных элементов. Организационная структура этих программных элементов вместе с объединяющими их отношениями называется архитектурой. На диаграммах, изображающих такие системы, отдельные программные элементы и серверы часто упрощенно представлены в виде прямоугольников, соединенных стрелками.