cacto
17af76c159
Тикер офлайн-детекции (internal/healthcheck) переехал из device-control-service в новый самостоятельный Go-сервис — как и планировалось с самого начала (см. изначальный README-заглушку). Детекция online остаётся в device-control-service: она происходит как побочный эффект уже имеющейся там MQTT-подписки на devices/+/telemetry и devices/+/ack, заводить для этого отдельный сервис с дублирующей MQTT-подпиской избыточно. health-check-service — свой Go-модуль (без зависимости от proto/, сборка из собственного контекста), читает только узкое read+offline-подмножество Device Shadow keyspace в Redis (devices:known, status, last_seen) — полный Shadow API с записью desired/reported state остаётся только в device-control-service. Метрика device_control_health_transitions_total переименована в device_health_transitions_total и теперь публикуется с этим именем из ДВУХ сервисов (device-control-service — direction=online, health-check-service — direction=offline): Prometheus агрегирует одноимённые метрики с разных таргетов прозрачно, поэтому Grafana- дашборд адаптирован простой сменой имени метрики в запросе, без переделки панели. Проверено вживую через docker compose: реальный online→offline переход (публикация тестовой телеметрии + ожидание таймаута) корректно долетает до Redis и RabbitMQ (device.status_changed), Prometheus видит новый scrape-таргет как up.
device-control-service (Go)
Статус: реализован (MVP).
Зона ответственности:
- Предоставляет gRPC API (см.
proto/device_control/device_control.proto:TurnOn,TurnOff,SetLevel→CommandResult) для отправки команд устройствам — вызывается из rule-engine-service (действия по срабатыванию правил). - Тот же функционал доступен и по HTTP/JSON (
internal/httpapi,POST /devices/{device_id}/turn-on|turn-off|set-level) — для Laravel (ручное управление из UI), см. «Архитектурные решения» почему не gRPC. - Публикует команду в MQTT-топик устройства (
devices/{device_id}/commands) и слушает подтверждения (devices/{device_id}/ack). - Поддерживает паттерн Device Shadow в Redis:
desired_state(чего хочет пользователь) противreported_state(что подтвердило устройство), плюсstatusиlast_seen. - Переводит устройство в
onlineи публикуетdevice.status_changedв RabbitMQ при получении телеметрии/ack (см. «Архитектурные решения»). Обратный переход,offlineпо таймаутуlast_seen, — зона ответственности отдельного health-check-service (см. его README).
Не входит в зону ответственности: решение о том, когда отправлять команду на основе показаний датчиков — это логика rule-engine-service. Этот сервис только исполняет команды и отслеживает состояние для той команды, что ему дали.
Архитектурные решения
- gRPC — не ждёт подтверждения устройства.
CommandResult.successозначает «desired_state обновлён и команда опубликована в MQTT», а не «устройство подтвердило выполнение». Это соответствует Device Shadow: мгновенный отклик в UI, даже если устройство офлайн или ответит с задержкой.reported_stateобновляется позже, асинхронно, по приходу ack. - last_seen обновляется и по телеметрии, и по ack. Сервис подписан на
devices/+/telemetryтолько ради отметки «устройство живо» (сами данные телеметрии парсит и хранит ingest-service) — иначе датчики без исходящих команд (и, соответственно, без ack) никогда не считались бы online. - Нет зависимости от PostgreSQL. Список известных устройств — это Redis
Set (
devices:known), который пополняется по мере поступления телеметрии/ack, а не выгружается из таблицыdevices. Это удерживает сервис в границах MQTT+Redis+RabbitMQ+gRPC, как и в диаграмме архитектуры корневого README. - HTTP рядом с gRPC, а не вместо. ТЗ подразумевало gRPC-вызов и от
Laravel тоже, но
grpc/grpcпод PHP требует PECL-расширение, которое в Alpine компилируется мучительно долго (C-код, 10-20+ минут) и утяжеляет образ.internal/httpapi— тонкий транспорт поверх ТОГО ЖЕserver.Server(никакой логики не дублируется, просто JSON вместо Protobuf): диаграмма архитектуры в ТЗ и так допускала «HTTP/очередь» для Laravel→device-control. gRPC-контракт между Go-сервисами (rule-engine) не тронут.
Метрики
GET /metrics на том же порту, что и команды (DEVICE_CONTROL_HTTP_PORT)
— не открывали отдельный порт ради этого. Счётчики/latency команд
(TurnOn/TurnOff/SetLevel по action+outcome), MQTT-событий (telemetry/ack),
переходов в online (device_health_transitions_total{direction="online"}
— та же метрика по имени, что публикует health-check-service для
direction="offline", см. его README).
Запуск
cd services/device-control-service
go test ./...
go build ./cmd/device-control-service
Конфигурация — через переменные окружения (секция device-control-service в
корневом .env.example). proto/ — отдельный Go-модуль, подключается через
replace в go.mod на относительный путь ../../proto.