Ни одна информационная система и ни один программный продукт, даже самые мощные и популярные ныне, не явились миру сразу во всём своём великолепии.
В самом начале любого проекта важно добиться базовой функциональности продукта, убедиться в том, что всё работает; работает как надо; и это востребовано пользователями.
Конечно, мы хорошо знаем о том, что модульная архитектура хороша своей гибкостью, надёжностью, возможностью горизонтального масштабирования. Но её строгая реализация требует дополнительных усилий и времени. Поэтому в самом начале разработки облака 1cloud мы, как и многие другие в подобной ситуации, выбрали более рациональный и целесообразный путь, реализовав простую традиционную трёхзвенную модель.
Один из недостатков такого подхода: определённые ограничения в масштабировании, а значит, и в возможности быстро нарастить производительность системы.
Для нас это обстоятельство не было очень критичным, потому что в качестве аппаратной основы нашего облака используется очень мощное оборудование, позволяющее изменять характеристики виртуальных серверов в очень широких пределах. То есть у нас имелся существенный запас мощности для вертикального масштабирования. Кроме того, на старте не было особо большой нагрузки.
В общем-то, даже с учётом приобретённого опыта в случае старта нового проекта мы повторили бы этап трёхзвенной архитектуры.
С момента запуска нашего облака оно весьма выросло: увеличилось число пользователей; добавились новые сервисы; появились партнёры, использующие нашу платформу для предоставления собственных услуг. Географически система также существенно расширилась: появились новые центры обработки данных (ЦОД). Стали ощущаться пределы масштабирования с помощью простого увеличения мощности отдельных серверов. Достаточно скоро мы почувствовали необходимость усилить модульность нашей системы.
Мы поделимся с вами своим опытом.
Сложности модулирования
Разделить реальную систему — не обязательно информационную — на подсистемы и модули часто бывает непросто. Слишком много разного рода переплетений возникает при решении прикладных задач.
Кроме того, мало вычленить конкретную функциональность в отдельный модуль, ещё нужно обеспечить его взаимодействие с другими частями системы. В каких-то случаях устоявшиеся или даже стандартные методики такого взаимодействия уже есть, в каких-то — нет, то есть их приходится придумывать самим.
При этом нужно понимать, что взаимодействие между модулями влечёт за собой определённые накладные расходы: времени или вычислительных ресурсов.
Если требуется горизонтальное масштабирование — то есть возможность изменять производительность системы в очень широких пределах — в ней нужно предусмотреть средства, обеспечивающие слаженную параллельную работу групп модулей и балансировку нагрузки между ними.
Цели
Несмотря на упомянутые издержки при разработке, во время эксплуатации системы модульная архитектура даёт много весьма значительных преимуществ. Мы их уже назвали: гибкость, надёжность, устойчивость, возможность масштабирования. Сейчас объясним, почему это стало для нас особенно важным.
В настоящее время в нашем облаке клиенты получают целый ряд услуг: аренды виртуальной инфраструктуры: серверов и сетей (IaaS); объектного хранилища данных (Object Storage); мониторинга хостов (Host Monitoring); бесплатного DNS-хостинга; получения SSL-сертификатов. И число наших услуг продолжит увеличиваться.
Сейчас они предоставляются в пяти географически разнесённых ЦОД’ах, и к нашему облаку будут присоединяться новые центры обработки данных.
Кроме того, нашими вычислительными ресурсами и технологической платформой пользуются не только наши прямые клиенты, но и клиенты наших партнёров.
Всё это складывается в большую и сложную систему, которой нужно надёжно и эффективно управлять.
Строительные единицы
Модули
В качестве основной архитектурной макроединицы нашей системы мы определили «модуль». В данном контексте под этим термином мы понимаем комплект программных компонентов, решающих обособленную прикладную или системную задачу.
К составу модуля мы отнесли и базу данных, предназначенную для его работы.
Как правило, модуль соответствует услуге, предоставляемой зарегистрированным пользователям, например, «Виртуальная инфраструктура» (IaaS), «Объектное хранилище» (Object Storage), «DNS-хостинг», «SSL-сертификаты». Такие модули мы называем прикладными.
Особым модулем следует считать «Панель управления», который служит пользовательским веб-интерфейсом, объединяет в себе другие прикладные модули и обеспечивает доступ к той или иной услуге.
Кроме прикладных модулей, имеются базовые (или системные), которые образуют ядро облачной платформы. Системные модули выполняют все внутренние задачи, например, создают, изменяют и удаляют виртуальные серверы, сети и других элементы виртуальной инфраструктуры. Кроме того, соответствующие системные модули обеспечивают тарификацию и биллинг услуг; рассылку сообщений по электронной почте, SMS и через мессенджеры; работу базы знаний и службы технической поддержки.
Для решения вспомогательных задач имеются дополнительные модули. Они не являются абсолютно необходимыми для выполнения базовых функций облака, но использование этих модулей позволяет либо упростить оказание услуги клиентам, либо повысить его эффективность.
Компоненты
Каждый модуль обеспечивает решение всего комплекса прикладных подзадач, которые могут возникать при оказании той или иной услуги. Для решения связанных подзадач предназначены составные части модуля, которые мы называем компонентами.
Практически у каждого модуля имеется прикладной интерфейс (API), по которому с модулем могут взаимодействовать сторонние информационные системы и приложения. Конечно, для этого им потребуется аутентифицироваться.
Большинство наших модулей имеет внутренние обработчики задач (Task Processor) и планировщики задач (Scheduler).
Во многих модулях имеется собственная или разделяемые с другими модулями база данных.
Для интеграции системы и межмодульного взаимодействия используются элементы, обеспечивающие отправку сообщений другим модулям и приём сообщений от них.
Модули, непосредственно связанные с оказанием коммерческих услуг, имеют компонент, отвечающий за регистрацию потребления ресурсов. В дальнейшем по этим данным производится расчёт стоимости предоставленных услуг.
Заключение
Модульная архитектура позволила нам сделать нашу платформу более эффективной, надёжной, устойчивой, масштабируемой.
Появилась возможность обновлять части системы, не затрагивая работу остальных.
Потенциально возможные сбои в работе одного модуля не затронут работу других.
P. S. Ещё немного наших статей:
