Облачная хостинг-платформа

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

1. Управлять структурой организации (подразделениями, региональными отделениями, головными офисами);
2. Интегрировать корпоративные AD и применять SSO (Single Sign-On);
3. Управлять пользователями и пользовательскими ролями;
4. Управлять уведомлениями и их шаблонами.

Базовая функциональность предоставляет следующие ключевые функции для ядра платформы, а также для всех интегрированных приложений:

1. Повышенная безопасность при разделении данных и их шифрование;
2. Повышенная стабильность и масштабирование;
3. Надежная подсистема уведомлений и гарантированная доставка сообщений;
4. Надежная аутентификация и сервис авторизации с SSO (Single Sign-On), основанный на наиболее современных подходах и с использованием сертификатов безопасности.

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

Вся облачная платформа разработана с применением сервисно-ориентированного подхода и состоит из нескольких отдельных сервисов. Все компоненты масштабируемы и отделены друг от друга. Azure в качестве хостинга платформы, по-умолчанию, предоставляет мощные инструменты для автоматической масштабируемости, а также обеспечивает высокий уровень SLA (Service Level Agreement) на базе облачных технологий. Таким образом, выбранная архитектора, технологии и подход обеспечивают высочайший уровень надежности и масштабируемости сервиса.

Компоненты, отвечающие за бизнес-логику, разработаны на базе WCF-сервисов. Компоненты публичной части могут быть реализованы на основе различных технологий и подходов (ASP.Net MVC, AngularJS и других), если они поддерживают интеграцию с WCF.

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

Платформа предоставляет набор базовых сервисов, которые являются общими для всех интегрируемых приложений:

1. SSO (технология единого входа);
2. Подсистема уведомлений;
3. Журналирование;
4. Платежный сервис;
5. Выставление счетов;
6. Автоматическое развертывание копий приложений.

Первая схема отображает общую структуру основных компонентов системы. Каждый сервисный узел является отдельным приложением, интегрированным в платформу. Он состоит из нескольких компонентов. Каждое приложение реализует специфическую бизнес-логику. Такое приложение, в свою очередь, может состоять из нескольких сервисов (например, MVC приложение в качестве фронт-энда и WCF в качестве бизнес-логики).

В то же время, каждый сервисный узел обладает собственным Агентом управления, который отвечает за взаимодействие с ядром платформы «Управляющей Консолью». Агент управления создается, когда регистрируется новый сервисный узел.

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

Взаимодействие между Управляющей Консолью и другими сервисами (сервисными узлами, Azure, DNS сервисом) является удаленным и асинхронным. Когда UI делает запрос, удаленный сервис, который должен выполнить запрос, может оказаться недоступным или занятым другой задачей. Некоторые запросы, особенно запросы на регистрацию Azure, могут занимать длительное время. Некоторые запросы являются серией запросов к различным удаленным сервисам.

Чтобы справляться с такими ситуациями мы используем асинхронную очередь запросов. UI делает запрос и внутренняя служба переводит все запросы в Команды, которые затем выстраиваются в очередь, реализованную при помощи SQL Server.

Фоновая служба, которая называется Менеджер Очереди, следит за очередью и выполняет команды, а также повторяет их, если сервис не был доступен, или записывает результаты операций в соответствующий журнал исполнения операций.

Также в системе существует дополнительный коммуникационный узел, который называется Журнал событий. Все операции и действия, возникающие в приложениях или на уровне платформы, в обязательном порядке заносятся в Журнал событий. Такими операциями являются:

1. Ошибки (с подробной отладочной информацией и деталями);
2. Предупреждения, т.е. сообщения о возможных ошибках, которые с большой долей вероятности нужно зафиксировать;
3. Активность пользователей, а именно создание ими новых пользовательских аккаунтов, подписание документов, запуск рабочих процессов;
4. Внутренние события приложений, которые вероятней всего необходимы для отладки (приложение выдаст такое событие, только в случае прямой инструкции сделать это).

Журнал событий используется для:

1. Формирования счетов;
2. Оценки состояния системы;
3. Мониторинга использования приложений;
4. Помощи Сервис-Инженерам в устранении каких-либо проблем;
5. Сбора статистической информации и формирования отчетов для руководства компаний.