Как использовать Azure Resouce Provider для получения платежей за мои услуги?
Это SDK поставщика ресурсов Windows Azure. Я пытался читать о концепциях и не могу точно понять, позволяет ли это мне делать то, что я хочу.
У меня есть веб-сервис, размещенный в Windows Azure. Пользователи получают пару "идентификатор пользователя-пароль", оплачивают услугу через PayPal, а затем могут отправлять веб-запросы на указанный URL-адрес, предоставляя свои пары "идентификатор пользователя-пароль", и служба будет удерживать средства в зависимости от количества их запросов. Когда они платят через PayPal, они покупают "право делать N запросов" - их баланс внутри сервиса увеличивается на "количество запросов", за которые они заплатили. Так что это сервис с оплатой за использование объема.
Теперь я хочу представить свой сервис в хранилище Azure с помощью SDK Resource Provider, взимая с пользователей плату за количество запросов, которые они направляют на мой сервис.
Концепции документа гласят
Затем пользователь создает подписку. Подписка - это именованный объект, например, 3-месячная бесплатная пробная версия или MyApp Production. Вы можете просматривать свои собственные подписки на портале учетной записи.
Затем пользователь создает один или несколько ресурсов, таких как веб-сайт или виртуальная машина. Веб-сайт и виртуальная машина - это два разных типа ресурса. Каждый Ресурс развернут только по одной Подписке.
Часть подписки более или менее понятна. Как насчет Resource объекты? Я имею в виду, что описание продолжает "такой как веб-сайт или виртуальная машина", но я хочу предложить не сайт и не виртуальную машину, это право ставить в очередь определенное количество запросов к URL-адресу моей службы.
Либо я не получаю чего-то простого, либо SDK поставщика ресурсов Azure просто не то, что я могу использовать.
Как предоставить свою службу тома с оплатой за использование в хранилище Azure с помощью Azure Resource Provider SDK?
2 ответа
Вся путаница заключается в том, как сформулирована документация. Это говорит
Затем пользователь создает подписку. Подписка - это именованный объект, например, 3-месячная бесплатная пробная версия или MyApp Production.
Это частично правда. Пользователь действительно создает подписку, но обычно это происходит задолго до того, как он совершает свою первую покупку в магазине Azure. Подписки - это вещь Azure, они не относятся только к Azure Store. RP видит идентификатор подписки (в настоящее время в форме представления строки GUID), и по идентификатору подписки RP может различать покупки, сделанные разными пользователями.
Тогда идет это
Затем пользователь создает один или несколько ресурсов, таких как веб-сайт или виртуальная машина. Веб-сайт и виртуальная машина - это два разных типа ресурса. Каждый Ресурс развернут только по одной Подписке.
Это просто очень далеко от истины.
Пользователь выбирает "предложение" из витрины магазина Azure (в основном список доступных служб), затем он выбирает "план" (тип предложения "платишь Х денег и получаешь Y услуги", X ноль для бесплатных планов) и он выбирает "имя ресурса". "Имя ресурса" зависит от пользователя - он выбирает его.
"Тип ресурса" - это уникальный символический идентификатор "предложения", который должен быть уникальным для всего хранилища Azure и выбирается разработчиком RP. Таким образом, такие примеры, как "Веб-сайты" или "Виртуальные машины", являются очень плохими и бесполезными - на самом деле вы захотите иметь "тип ресурса", такой как CompanyXMalingService так что, когда кто-то хочет предложить "почтовую услугу", он может предложить CompanyYMailingService и когда вы сами хотите предложить "услугу телефонии", вы можете использовать CompanyXTelephonyService и не сталкиваться с другими.
Теперь, если вы предлагаете что-то с моделью выставления счетов "N запросов в период", у вас может быть период "один месяц", поэтому это может быть только "N запросов в месяц", и ничего больше. Предположим, что ваше предложение "тип ресурса" CompanyXCoolRequests,
Тогда модель выглядит следующим образом: пользователь нажимает на ваше предложение, выбирает план (например, 1000 запросов в месяц) и просматривает, пока не будет выставлен счет. Тем временем магазин отправит запрос на ваш RP, сообщающий, что была совершена покупка по подписке с определенным идентификатором ресурса типа CompanyXCoolRequests и с некоторым именем ресурса, идентификатор плана будет внутри запроса. Ваш RP создает учетную запись внутри вашего сервиса и дебетует количество запросов там, он должен предоставить идентификатор пользователя и пароль (или любой другой материал, необходимый для использования вашего сервиса) - либо как "элементы вывода", которые отображаются, когда пользователь нажимает Кнопка "Информация о соединении" или через сервисную страницу, где пользователь перенаправляется, когда нажимает кнопку "Управление".
Теперь есть следующие варианты. Либо просто ничего не происходит в течение многих лет, и это означает, что покупка пользователя активна, и ему выставляются счета каждый месяц, месяц начинается с даты, когда он совершил покупку, и продолжается до той же даты следующего месяца. Вы должны предоставить ему 1000 запросов каждый месяц. Вы должны решить, что делать с остатком баланса (например, месяц заканчивается, а он использовал только 800 запросов) и что делать, когда он использует все до начала нового месяца. Пользователь также может "удалить" ваше предложение из своей подписки - ему больше не будет выставлен счет, и магазин отправит запрос на ваш RP, и вам придется удалить или заблокировать учетную запись, созданную ранее в вашем сервисе. Также возможно, что есть событие уровня подписки, такое как приостановка подписки - тогда вы должны временно заблокировать все ресурсы этой подписки и иметь возможность восстановить их все, когда подписка "возобновлена". И, наконец, пользователь может "обновить" его покупка путем перехода на более дорогой тарифный план - вам придется списывать лишние единицы на его "счет" внутри вашего сервиса.
В качестве подписки можно использовать идентификатор для торгового отношения "Пользователи" [представьте себе идентификатор, за который будет взиматься кредитная карта] Ресурс или аддон с другой стороны - это то, что идентифицирует экземпляр услуги, которую покупает пользователь.
В вашем случае давайте позвоним в ваш Сервис "SharpToothService" и пользователь сможет зайти в сервис и купить возможность отправить "n SharpTooths / month" за 9.99.
Острый зуб был бы ресурсом. & Имя пользователя и пароль будут элементами вывода [Результат предоставления и покупки ресурса]
[По мере того, как вы ладите, у вас могут возникнуть вопросы о планах]- План - это, например, то, что определяет проданные пакеты. Возможно, у вас есть Серебряный план на "100 Sharptooths за 9,99/ месяц": золотой на "500 Sharptooths за 19,99/ месяц" и т. Д.