Содержание


Облачная служба биллинга

Модуль службы биллинга с поддержкой SOA для облачной среды

Comments

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри:

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

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

Компоненты модуля службы облачного биллинга

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

Рабочий модуль: форма вытекает из функций

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

  • служба биллинга составляет счета по правилам, извлекаемым из Репозитория правил биллинга;
  • эти счета хранятся в Репозитории счетов для последующего использования менеджером.

На рисунке 1 показана общая архитектура службы учета ресурсов и выставления счетов.

Рисунок 1. Архитектура модуля
Архитектура модуля
Архитектура модуля

Процесс составления счета не автоматизирован и должен быть инициирован менеджером. Вся функциональность службы реализована в виде Web-сервиса.

На рисунке 2 показан модуль с технологической точки зрения и иллюстрируются различные компоненты, а также взаимодействие между различными технологиями.

Рисунок 2. Модуль с технологической точки зрения
 Модуль с технологической точки зрения
Модуль с технологической точки зрения

Служба биллинга устанавливает связь с Web-сервером через PHP-интерфейс и получает подтверждающий документ из Репозитория учета ресурсов (Usage Record - UR).

Правила, синтаксис и язык биллинга

Вот простой пример правил биллинга:

  • 1 ЦП/ч (час эксплуатации) равен 1 жетону;
  • скидка 20% за ЦП/ч свыше 20 ч.

Однако какими бы простыми или сложными ни были правила расчетов, наступит время, когда менеджер ресурсов захочет их изменить. Учесть все варианты просто невозможно, а изменение исходного кода при каждом добавлении нового правила ― конечно, не выход.

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

Предположим, что нужно формализовать два правила, приведенных выше в качестве примера. Можно написать что-то вроде: пусть (cpu_h(x) - x часов ЦП, а token(x) - x жетонов; тогда

(1)# bill = token(cpu_h(x));
(2)# if 
         cpu_h(x) > 20
     then
         bill = bill*.8;

Эта запись учитывает оба правила; однако в ней кроются две важные проблемы:

  • она составлена не на естественном языке;
  • она не позволяет учесть все случаи.

Человек, который составляет правила биллинга, не обязательно должен быть программистом, и составление такой записи может оказаться затруднительным. Намного проще было бы выразить правила биллинга на естественном языке.

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

Существуют также различные языки, используемые для описания правил; у каждого из них свои преимущества и недостатки.

Естественный язык позволяет выражать правила на простом английском языке:
When the event is VM Assignment and the client's type is Platinum, then the cost per second is 0.0002 euros. (При событии VM Assignment для клиента типа Platinum тариф за одну секунду составляет 0,0002 евро.)

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

Описание тех же правил на языке предметной области (с использованием того же синтаксиса и семантики, что и в спецификации) выглядит следующим образом:
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE > 240 * 60 * 60 (секунд), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (евро, фунтов и т.п.)

Язык предметной области лучше структурирован и позволяет легче вносить изменения, чем естественный язык.

Механизм правил/умозаключений и его роль

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

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

  • ACEL от IBM (Autonomic Computing Expression Language - Язык автономных вычислительных выражений), разработанный в рамках проекта Autonomic Computing Policy Language (Язык автономных вычислительных правил) для описания условий применения правил к управляемой системе;
  • чтобы придерживаться отраслевых стандартов, нужно использовать в качестве интерфейса программирования Java™ Rule Engine API (JSR94).

Правила биллинга вводятся и редактируются посредством простого Web-интерфейса. Рассмотрим структуру механизма правил/умозаключений.

Рисунок 3. Механизм правил/умозаключений
Механизм правил/умозаключений
Механизм правил/умозаключений

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

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

Рабочий процесс и стратегия разрешения конфликтов

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

А теперь давайте перейдем к краткому обсуждению функциональных требований.

Функциональные требования к модулю биллинга

Здесь я кратко опишу функциональные требования, предъявляемые к модулю облачного биллинга.

Служба информирования о расценках

Облачная служба должна поддерживать информирование о расценках, чтобы пользователи могли справляться о них, прежде чем использовать ресурс. Например: «Сколько будет стоить запуск того-то и того-то в данном вычислительном узле?» Расценки не должен обязывать и должны действовать лишь в течение некоторого короткого периода времени.

Функция преобразования и правила

Облачная служба должна реализовывать функцию преобразования, которая конвертирует записи об использовании ресурсов в денежные знаки, основываясь на схеме преобразования, — например: "Стоимость 1 ЦП/час = 1 жетону", — и определять денежное выражение жетона в зависимости от экономической модели и спроса. Облачная служба должна позволять владельцу ресурса предоставлять его с настраиваемыми моделями преобразования, чтобы лучше соблюдать свои интересы.

Процесс идентификации клиента (лица)

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

Функции и правила схемы расчетов

Облачная служба должна поддерживать, как минимум, одну схему оплаты. Например, схему оплаты по факту, предоплаты (скажем, при бронировании машинного времени) или схему регулярных платежей.

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

EVENT = "VM Assignment", 
CLIENT_TYPE = "Platinum", 
RESOURCE_TYPE = "BLADE Type 4", 
RESOURCE_AGE < 240 * 60 * 60 (секунд), 
SERVICE_LEVEL = "Platinum", 
COST_PER_SECOND = 0.0002 (евро)  

EVENT = "ONE_OFF SERVICE 1", 
RESOURCE_TYPE = "BLADE Type 4", 
ONE_OFF_COST = 1

Нефункциональные, но важные требования

Для удовлетворения важных нефункциональных требований, предъявляемых к облачному модулю биллинга, он должен, как минимум, поддерживать:

  • безопасное выполнение своих операций;
  • проверку подлинности на основе ролей;
  • контрольный след для анализа деятельности.

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

Заключение

Этот детальный анализ модуля биллинга для облачной среды познакомил читателя с некоторыми соображениями, позволяющими ему обдумать свой собственный план разработки. Мы рассмотрели, как модуль вписывается в службу учета ресурсов и выставления счетов и в общую облачную инфраструктуру. Привели примеры правил биллинга, а также синтаксиса и языка и углубились в работу механизма правил/умозаключений. Кроме того, мы представили перечень функциональных требований, предъявляемых к модулю биллинга, и нефункциональных, но важных требований, которые также необходимо рассмотреть.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, SOA и web-сервисы
ArticleID=840903
ArticleTitle=Облачная служба биллинга
publish-date=10172012