Scaling Up в е-коммерции

Роберт Шайер

Как съесть слона

Как можно съесть слона? По кусочкам. Пользователи и аналитики считают, что так же надо создавать масштабируемую веб-архитектуру: разделить системы на тщательно продуманные компоненты и при необходимости наращивать мощность, не затрагивая всю структуру.

"Проектировать надо с размахом, а делать понемногу", - говорит Ларри Киндер (Larry Kinder), старший вице-президент и начальник отдела ИТ нью-йоркской компании Cendant, предоставляющей финансовые и туристические услуги.

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

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

Скотт Митчелл (Scott Mitchell), начальник отдела технологий в HSN.com (онлайновый филиал Home Shopping Network), предпочитает рост "не вверх, а вширь": "Я лучше добавлю к кластеру еще один сервер, чем буду заменять существующий более дорогим".

В прошлом году компания увеличила число двухпроцессорных веб-серверов с 4 до 10, обслуживая два четырехканальных сервера баз данных на SQL Server 2000 от Микрософт.

Так как 10 серверов - почти предел для удобного распределения нагрузки и копирования данных, Митчелл намерен с ростом трафика создавать новые серверные фермы в других местах, что позволит ему "наращивать архитектуру бесконечно".

Некоторые ИТ-менеджеры решают вопрос расширения, разделяя системы на компоненты в зависимости от задач предприятия и наращивая архитектуру по принципу "pay-as-you-go".

Компонентное мышление

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

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

Киндер рассказывает, что в рамках работы с Avis Group Holdings Inc, которую Cendent приобрела в прошлом месяце, "понадобилось обеспечить клиентам доступ к данным и счетам в онлайне", не подключая веб-сервер к 50 унаследованным базам данных.

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

"Долгоиграющие" компоненты

Компания EBlast Ventures создала компонент многократного пользования - в форме обработчика (engine) каталогов.

Руководитель технического отдела Брюс Вайнер (Bruce Weiner) говорит: "В каталоге представлено детское мыло с игрушками, приложенными к каждому куску. Делая покупку, родители выбирают из всех сортов мыла и видов игрушек. Я не знаю, какое сочетание им понравится. С помощью инструментов WebLogic от BEA Systems я могу создать обработчик и показать все виды мыла и игрушек, а также возможные варианты их сочетаний. Родители просто сообщат мне, какое сочетание выбрали".

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

Правильно разработанные компоненты должны содержать достаточное количество деталей, чтобы быть полезными, и иметь достаточно общий характер для совместимости с разными приложениями.

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

Этапы сделки с оплатой по кредитной карте известны. Однако невозможно заранее знать, как тот или иной продукт будет оценен или показан в каталоге.

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

Окончание в следующем выпуске.

Продолжение в выпусках: #129