Ты будешь иметь только автономные услуги

Question

Один из принципов SOA: «Сервисы автономны». У меня есть 2 услуги. Служба A зависит от Службы B. Служба A не может обслуживать клиентов, если Служба B не запущена и не работает. Я нарушаю принцип здесь?

Или, если автономный должен означать «разъединенный», удовлетворяю ли я принципу, если у меня есть отказоустойчивый (скажем, другой экземпляр службы B, работающий в другом месте, к которому подключен, если основной экземпляр не работает.)? Это может удовлетворить мои требования к доступности, но я не уверен, как это может уменьшить мою зависимость. Да, отказоустойчивым может быть даже Сервис C от третьей стороны, и в этом случае я улучшаю свою автономию.

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

Будет ли ошибкой, если я буду рассматривать сервисы как компоненты с обменом сообщениями? :)

Мысли

Answer 1

Смотрите этот пост на SOA Tenets . Также см. Фрактальное созвездие автономных служб .

«Службы должны развертываться, управляться и иметь версии независимо от других служб и / или приложений, которые зависят от них».

Автономия не означает изолированность или совершенно автономность.

Вместо этого у вас может быть «созвездие» из двух служб. Да, они зависят друг от друга. Нет, A не ломается, когда B перемещается или модернизируется. А также не ломается, когда внутренние компоненты B не изменяются.

Точно так же - с точки зрения B - и обновление до внутренних компонентов A не отражается на изменениях в интерфейсе B и внутренних устройствах.

API развиваются независимо. Схема, сообщения и реализации являются независимыми. Они просто относятся друг к другу.

«Служба A не может обслуживать клиентов, если служба B не запущена и работает» - не беспокойтесь. Служба А также не может обслуживать клиентов, если она не работает. Сервис не работает. Не имеет значения, является ли это B (от которого зависит A) или A. Зависимость не имеет ничего общего с надежностью или доступностью A или B.

Да, сервисы имеют четко определенные и независимые интерфейсы. Реализация A зависит от B, а интерфейс - нет.

---

Редактировать.

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

Не вижу смысла. Если A зависит от B, и алгоритм B меняется, копия A данных B - хорошо - старая. Зависит от обычно означает живые, рабочие отношения до транзакции.

Проблема в том, что B может быть медленным, что делает A медленным, что делает приложение, которое использует A медленным. Это облом Но это не вызов для нарушения правил автономии и сохранения A в секретном кэше старых данных из B.

Answer 2

Ваша автономность только улучшена благодаря резервному сервису. Что если оба сервиса B и C выйдут из строя? Тогда ваш сервис падает. Вы можете еще больше повысить свою автономность (и производительность), кэшируя результаты внешних служб. Таким образом, если B и C отключатся, вы все равно сможете обслуживать некоторых своих клиентов с кэшированными результатами. Пока вы полагаетесь на сторонние сервисы, вы никогда не достигнете 100% автономии.