У тебя будут только Автономные Сервисы

Question

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

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

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

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

Мысли?

Answer 1

Смотрите этот пост на Принципы SOA.Также смотрите Фрактальная совокупность автономных сервисов.

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

Автономия не означает изолированности или абсолютной автономности.

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

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

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

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

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

---

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

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

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

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

Answer 2

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