При разработке и развертывании e-commerce решений на базе современных платформ зачастую бывает недостаточно просто спроектировать архитектуру системы и провести работы по ее вводу в эксплуатацию в соответствии с разработанным проектом. На практике возникает многоступенчатый, многократно повторяющийся процесс «проектирование → разработка/доработка → тестирование → развертывание». На каждой стадии этого процесса приходится работать с какими-то промежуточными конфигурациями и архитектурами, которые имеют свои особенности и не могут быть идентичными. Так что и вся архитектура (и инфраструктура) системы начинает дробиться на версии в соответствии с условиями применения.
Обычно, говоря об архитектуре, принято обсуждать именно рабочие конфигурации, которые будут использованы на «боевых» серверах в реальных условиях эксплуатации. Но процесс разработки и внедрения допускает, что у вашей системы будут и другие конфигурации, разворачиваемые на другой инфраструктуре для целей разработки и тестирования. Развитые e-commerce платформы enterprise-класса заранее предусматривают наличие таких специальных конфигураций и содержат специальный функционал, который облегчает переключение между разными версиями и конфигурациями при тестировании и развертывании изменений.
В общем случае для систем разного класса могут понадобиться следующие конфигурации (варианты построения архитектуры системы):
- для целей разработки (Development);
- для целей отладки и тестирования (Staging, User Acceptance Testing, Authoring, Quality Assurance и/или Pre-production);
- для целей зеркалирования и резервирования (Fault Tolerant, Standby или Disaster Recovery);
- основная конфигурация (Production или Live).
Дополнительно для целей переноса данных из одной конфигурации в другую могут применяться специальные инструменты, сервера и/или конфигурации, которые принято называть Delivery, Deployment или Publishing (environment, server, tools, configuration ...).
Отличия указанных конфигураций состоят не только в деталях настройки тех или иных компонентов, но и в самой архитектуре и поддерживающей инфраструктуре, на которой должны развертываться данные конфигурации. Действительно, нет необходимости развертывать высокопроизводительные кластеры для разработки и отладки кода – в этом случае достаточно упрощенной архитектуры. Так что «песочница» (staging) даже для очень масштабного решения может строиться на базе единственной виртуальной машины, удовлетворяющей минимальным требованиям инфраструктурного ПО. В это же время основная (production) конфигурация будет содержать множество серверов, объединенных в кластеры.
Пример развертывания Oracle Commerce в трех связанных конфигурациях
(Development, UAT/Staging, Production)
Вспоминая о сложной многозвенной архитектуре e-commerce решений, следует заметить, что наличие разных конфигураций может распространяться как на всю систему в целом, так и на разные ее звенья и компоненты. Например, совершенно отдельно имеет смысл рассматривать архитектуру системы хранения данных и архитектуру поисковой машины. Для первой часто имеет смысл уделить особое внимание зеркалированию и резервированию, а для второй важнее полноценная «песочница». Так что на практике приходится выстраивать сложные наборы связанных архитектур, которые оптимальным образом соответствуют потребностям проекта и «пролазят» в доступный бюджет.
Как уже говорилось выше, в платформах enterprise-класса (IBM WebSphere Commerce, Oracle Commerce, SAP hybris) на уровне функциональных возможностей и архитектуры заложены средства поддержки и взаимодействия различных конфигураций. Более того, можно заметить, что такие средства развиты довольно сильно, так как помогают вендорам продавать еще больше лицензий даже там, где это не очень и нужно. В некоторых случаях, впрочем, развитые возможности не бывают лишними. Например, Oracle Commerce имеет функцию, которая позволяет иметь две версии рабочей схемы данных и мгновенно переключаться между ними. Это здорово упрощает процедуру развертывания изменений, которая запускается и проверяется в отдельной схеме и не требует даже временной остановки системы, использующей в это время другую схему данных.
В противовес системам enterprise-класса, платформы 1С-Битрикс: Управление сайтом, Magento и VirtueMart не содержат в своем составе каких-либо средств для поддержки множественности конфигураций. Разработчики должны использовать функциональные возможности инфраструктурного ПО для реализации таких схем.