Каким образом делается взаимодействие с hardware в микросервисной архитектуре и Docker-контейнерах?
В сложных системах очень часто возникают ситуации, когда необходимо интегрироваться с каким-то внешнием железом, как-то: банковские терминалы, сканеры, принтеры, телефония, POS и т.п.
Каким образом такое взаимодействие обеспечеивается в микросервисной архитектуре на базе .NET при хостинге в Docker-контейнерах?
К примеру, при комплектации заказа нужно печатать документы. .NET Core не поддерживает System.Printing и System.Drawing.Printing. Можно использовать .NET Framework, но Windows-контейнеры Docker не поддерживают spooler service!
Другой пример: для общения с банковским терминалом нужна возможность взаимодействия с COM / USB портами, но Windows-контейнеры опять же этого не имеют.
Как обычно поступают в таких случаях? Хостят всё, кроме hardware-specific кода в контейнерах, а сервисы, взаимодействующие с железом, деплоят на сам хост?
COM, USB, принтеры и какие-то специфичные железяки для терминалов - та часть, где код должен быть по определению железо-зависимым. Контейнеры же про диаметрально противоположное, про абстракцию от железа и окружения. Т.е. писать софт для специфичной железяки и запускать его в контейнере, это как в истории про микроскоп и гвозди.
Вы сделали правильный вывод. Нужно выносить в контейнеры только логику независящую от какого-либо железа или оборудования. А сервисы, взаимодействующие с железом, разворачивать там где и железо.
Можно извернуться и сделать форвардинг COM\USB портов по TCP. Но это все будет работать нестабильно и через жопу.
Все что относится к клиенту, должно работать на клиенте. Печать - ответственность только клиента, бэк в контейнере вообще ничего не должен об этом знать, только генерировать документы если надо.
Работа внешним оборудованием тоже отвественность клиента. Если оборудование надо зашарить, то на клиенте подымается сервис.
Спасибо за ответ, да, о таком я и думал.
Но здесь появляется лишний оверхед на то, что документ надо куда-то залить, откуда клиент его скачает.
Кроме того, бывают случаи, когда принтер, например, подключен как сетевой к серверу, и печатает сервер (потому что ставить по миниПК для хостинга клиента на каждую точку, где нужно какие-нибудь наклейки со штрихкодами печатать, неудобно и дорого).
dropsonic, а зачем сохранять документ? что мешает сращу отдать документ клиенту в виде потока?
В случае сетеворого принтера как раз подымал сервис на ближайше машине и дергал его с бэка. Наверняка уже полно решений на .net core для отправки на печать на сетевые принтеры напрямую с бэка.
Артем Воронов, .NET Core до сих пор не поддерживает работу с принтерами. Все известные мне существующие решения используют внешние приложения для печати (lpr, MS Office и т.д.). Как вариант — вынести эту часть в сервис на .NET Framework и хостить на Windows.
"На ближайшей машине" — это +1 машина в некоторых случаях.
