Вопрос архитектуры: как программно регулировать объемы вызывающего в сервис-ориентированной архитектуре?

Question

Это, по общему признанию, открытый вопрос.

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

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

Это очень ручное, частичное согласование.

Есть ли литература по различным подходам?Одна идея пришла мне в голову: владельцу сервиса потребовались бы «кредиты вызывающего абонента» (валюта или квитанции разрешения) со стороны каждого абонента.Эти кредиты будут выдаваться самой службой (или каким-либо дополнительным ServieCallAdministrationService. Да, ужасное имя).Таким образом, владелец услуги может лучше гарантировать качество обслуживания, ограничивая объем своего обслуживания?

Другими словами: кто должен «владеть» этой проблемой управления общим объемом вызовов службы?Сам сервис?Вызывающие?Что-то еще?

Answer 1

Лучший способ решить эту проблему (на мой взгляд) - использовать транспортный уровень, ориентированный на сообщения (JMS, WebsphereMQ, MQMQ ...)

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

В любом случае - поставщик услуг несет ответственность за предоставление согласованного SLA

Answer 2

Есть и другие способы управления этим.Первый: вы используете один компонент перед своей службой, где вы можете определить политику, как часто один вызывающий абонент может вызывать эти службы (встроенные функции в IBM Datapowerbox или Oracle Web Service Manager)Второй: сам клиент (если известен) может установить ограничение на отправку в своем клиенте.Это может быть предопределено с клиентом в одном SLA.

Answer 3

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

У Redis есть срок действия ключа, поэтому вы можете истечь ключ через x минут, и вызовы службы будут работать как обычно.

"api-call-getUser:" + customerId