(Интернет) Вопрос о зависимости сервиса

Question

Скажем, например, у нас есть система электронной коммерции SIMPLE с двумя отдельными системами: системой управления запасами (IMS) и системой управления заказами (OMS). Предположим, что IMS предоставляет информацию об инвентаризации (getItem, getItemQuantities и т. Д.), А OMS предоставляет службы заказа (startOrder, addItemToOrder, finalizeOrder и т. Д.)

Эти две системы реализованы как веб-сервисы с использованием разных бэкэндов. В OMS предположим упрощенную модель, такую ​​как:

public class Order {
    private int orderId;
    private List LineItem;
    ...
}

public class LineItem {
    private int orderId;
    private int itemId;
    private int quantity;
    private int subTotal;
    ....
}

В IMS предположим модель, подобную:

public class Category {
    private int catId;
    private List Item;
    ...
}

public class Item {
    private int itemId;
    .... (other attributes)
}

Вы можете легко найти простую структуру таблицы БД для реализации вышеизложенного.

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

1. Проверка orderId (необязательно, может передавать эту ответственность в базу данных).
2. Вызов в IMS для подтверждения переданного itemId существует (требуется из-за diff DB)
3. Вызов в IMS для проверки запасов по переданному количеству (требуется из-за различий в базе данных)
4. Вставка новой записи в таблицу (обязательно)

Имеет ли это смысл с точки зрения производительности? Можете ли вы придумать лучший способ?

---

[EDIT]: В качестве продолжения, в случае, когда пользователь запрашивает OMS для деталей заказа, он может только вернуть orderId и список orderLineItems, каждый из которых содержит itemId, количество и подытог. Клиенту на самом деле также нужны имя и описание товара. Ответственность за получение имени / описания клиенту (через IMS) или OMS несет за это ответственность?

Answer 1

Забудьте на мгновение SOA.

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

Вам необходимо рассмотреть не только проверку инвентаря, но и его уменьшение, и, по-видимому, это правильно, только если добавление строки заказа работает.

Как вы собираетесь обеспечить такую ​​последовательность? Мы можем разработать всевозможные подходы (транзакции 2PC, или резервирование записей, или компенсационные транзакции, или оптимистическую работу с пакетными сверками), но, на мой взгляд, SOA или нет, веб-сервисы или нет, нам все еще нужно решать эти проблемы.

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

Лучше всего придумать несколько коротких замыканий. Например, мы на самом деле не проверяем запас при добавлении строки заказа. (Вероятно, пользовательский интерфейс уже отображал инвентарь, поэтому сравнительно недавняя проверка уже была сделана) Поэтому вместо этого мы проверяем инвентарь, когда заказ наконец-то размещен, и затем сообщаем пользователю, что «не смог сделать это» или «вам может потребоваться подождать». неделю или две для некоторых битов, вы хотите продолжить ".

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

Answer 2

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

Answer 3

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

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

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

Один ESB, с которым я экспериментирую, это: https://open -esb.dev.java.net /

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

Это очень полезно, если ваше приложение распространяется.

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

При добавлении в ESB наблюдается снижение производительности, но есть и такие преимущества, как более слабая связь, которая может восполнить это, поскольку теперь вы защищены от любых изменений вне wsdl для веб-службы ESB.

Answer 4

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

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

Для возможного решения кэширования взгляните на memcached .

Answer 5

С точки зрения производительности я бы сделал это

Сервис проверки идентификатора заказа.

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

Сервис для вставки новой записи в таблицу.

мы сократили сервисный вызов, объединив 2 и 3.

Answer 6

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