Требование этой системы - предоставить портал для поддержки агентов, которые могут выдавать определенные команды аппаратным устройствам.Для выдачи команд портал будет взаимодействовать с конкретной аппаратной службой (развернутой отдельно) и выполнять действия.
Способ, которым эта система в настоящее время "проектируется", чтобы портал отправлял синхронный вызов основной службе и ждал ответа.Это произойдет всякий раз, когда клиент звонит для устранения неполадок устройства.
Моя проблема с этим дизайном
- Это не масштабируется.
- Портал и другие системы (имеется несколько аппаратных устройств) тесно связаны между собой, поэтому любые изменения, необходимые для базовой системы, также влияют на доступность поляра.
- Нет показателей, сколько разклиент звонит для устранения неполадок устройства.да, это может быть реализовано, но это потребует больше часов разработки.
Что я хочу предложить (и именно поэтому я создаю этот пост), что вместо создания тесно связанных между собой портальных и аппаратных сервисов, его следует создавать с помощью функции шага AWS, т. Е.
- Портал выдает запрос на выполнение действия X на аппаратном устройстве Y
- Службы аппаратного устройства (не само оборудование) опрашивают эту функцию шага и проверяют, есть ли для них доступная работа.Если они это сделают, они будут выполнять действие
- Портал будет опрашивать статус запроса и будет обновлять портал после завершения функции шага.
При таком подходе
- Система масштабируется с учетом того, что если мы получим пакет запросов, функция шага может соответственно масштабироваться (автоматическое масштабирование).
- Базовые аппаратные службы независимы, они могут вносить изменения в любое время и в любое время.
- Учитывая, что базовые сервисы опрашивают, может быть размещен мониторинг для автоматического масштабирования этих сервисов, если
# of queue workflow превышает определенный порог. - Функция метрики вокруг шага (сколько запросов ставится в очередь) будет служить для того, чтобы увидеть, сколько вопросов мы получаем от клиентов.
Итак, я хотел бы спросить вас, ребята
- Имеет ли смысл моя проблема с оригинальной системой и моим решением?
- Если ту же систему необходимо было реализовать в GCP, каковы альтернативы функции шага AWS
Примечание :
Невозможно использовать AWS IoT, поскольку это устаревшая система.Команда аппаратного обеспечения уже выяснила, как аппаратные сервисы взаимодействуют с устройствами.
В этом вопросе предположим, что нам не нужно беспокоиться о сбое оборудования / проблеме с сетью.
Вопрос в основном направлен на взаимодействие WebPortal с HardwareServices.