我目前在IIS上托管有一个DotNet Core服务，该服务通过TCP / IP网关连接到多个RS232设备。
该服务连续从Seral设备读取数据，解析日期，并存储解析后的值。该服务连接到多个品牌的RS232设备，每个品牌都有自己的消息协议。因此，我为每个品牌提供了用于连接和解析的类以及一个设置文件，该文件存储设备的名称，IP地址以及用于从该特定设备读取的类型。
IIS服务还具有SignalR集线器，客户端可以通过指定特定串行设备的名称来连接并订阅，以从该设备接收解析后的值。
随着我的项目的发展，我添加了更多要读取的串行设备，因此变得很难管理和调试。许多不同品牌使用相同的连接方案，因此我可以使用相同的基类，而只需在派生类中实现解析器功能。有些会连续传输数据，而另一些则需要轮询等。
有时，客户端停止接收数据，并且用户需要重新加载网页。这可能是由于我尝试通过在特定设备的最后一个连接的客户端断开连接时布置串行设备读取器对象来减少网络流量和内存使用而引起的。 （跟踪SignalR连接并不是很简单。）
因此，我正在考虑将解决方案移至docker，并为每个串行设备提供一个容器，我希望在尝试并开始重构解决方案之前获得一些输入。
这是解决我的问题的好方法吗？这种方法有明显的障碍吗？
我如何管理SerialDeviceReader的代码库，因为相同品牌的设备将具有相同的实现，只是ip地址不同，而其他设备则相差很大。
当前，SignalR集线器直接从串行设备对象读取存储的最新解析值。我应该在SignalR和设备容器之间放置诸如redis或MQTT之类的缓存服务吗？
在这种情况下确实需要SignalR还是Web客户端是否可以直接订阅redis和MQTT之类的缓存服务？
任何输入将不胜感激！