我们有一个 TCP 套接字服务器，它从各种 IoT 设备检索数据，对其进行处理并将其输出到 Azure 数据库。目前，它托管在 Azure Linux VM 上。但是，将其放在函数应用程序或容器服务中会更经济高效吗？
答案1
转向容器的选项和创建无服务器功能架构的选项都应该比虚拟机更具成本效益。
功能
我想说，在绝大多数情况下，功能架构会便宜得多。但对于您的具体情况，这取决于您的 IoT 消息的频率。
使用函数时，您无需为全天候运行服务器支付固定费用。您的代码只会在每次调用函数时运行，并且您只需为每次运行函数时使用的资源付费。这在应用程序处于非活动状态时可以节省大量费用，因为在不使用期间完全不收取任何费用。
但在物联网情况下，如果您不间断地接收消息，您可能不会发现成本效益那么显著（但这仍然取决于数量）。
话虽如此，除了成本之外，还有其他利弊需要考虑：
- 优点
- 可扩展性- 借助这些功能，您将能够自动无缝地扩展应用程序计算组件，而无需担心虚拟机或容器实例或管理
- 弹力- 使用函数，您无需担心虚拟机或容器出现故障，也不需要编排解决方案，运行代码的云将在其后端处理所有问题。呈现在您眼前的只是一个可靠的函数即服务。
- 缺点
- 发展- 切换到功能架构并不像从虚拟机转移到容器那么简单，您不能只转移现有的解决方案，还需要投入一些开发时间来创建您需要的适当功能。
容器
容器是运行虚拟机的渐进式进步。容器通过在 Docker 引擎和主机操作系统上运行容器来提高效率，而不是像虚拟机那样为每个实例创建新的客户操作系统。容器/虚拟机差异的视觉链接
容器会更便宜，但当你需要转换大量虚拟机时，成本节省才会真正发挥作用。对于单个虚拟机，我不知道这会带来巨大的成本差异。
话虽如此，在这种情况下，除了成本之外，有用的好处是启动时间。由于不需要像虚拟机那样启动新的客户操作系统，容器的启动速度要快得多，这在扩展或恢复场景中尤其有用。
总结
函数有潜力变得更便宜，但这可能会因调用频率过高而降低。除了成本之外，它们仍然具有优势，但需要付出不小的努力才能实现。
容器会更便宜（特别是对于高虚拟机数量），但如果成本是你唯一的驱动因素，并且你只运行 1 个虚拟机，那么价格下降可能还不值得你花时间。