我已经在控制台应用程序，Windows服务等中看到了自托管WCF服务的示例，示例代码等。
我的问题是，这将如何在生产中发挥作用？会有效吗？它会扩展吗？
我不确定，它是如何工作的，所以其他问题是，这是单线程吗？多线程？我需要管理多线程吗？应用程序域？
出于应用程序相关原因，我更喜欢使用命令行，Windows服务进行托管。
答案 0 :(得分：2)
我的问题是，
会有效吗？它会扩展吗？
是的，是的。但对于真正大规模的应用程序，您仍应考虑使用IIS（+ WAS）。
所以其他问题是，这是单线程吗？多线程？
这取决于配置。
答案 1 :(得分：2)
它会有效吗？
这取决于服务实现，它取决于它能够在特定时间范围内管理的最大请求数。效率是一个相对衡量标准：让我们假设您的服务能够处理20条消息/秒，如果您的要求是能够处理10条消息/秒，那么您的服务就是高效的。但如果要求是30，那就不是。
它会扩展吗？
再一次，它与托管无关。您的服务是无国籍的吗？如果没有，那么它们可能不会扩展很多，因为负载平衡是不可能的。
它是否可以管理？
可能不是： - 您需要让用户登录服务器才能运行该应用程序 - 它不会自动启动服务器 - 失败时无法自动重启 - 它不会主动创建服务实例 - 它不提供（没有自定义代码）检查服务健康状况的方法
单一实例？多线程？
如果您的服务不保持每个客户端的呼叫之间的状态，则将其配置为“每个呼叫一个实例而不是多线程” - ＆gt;没有并发性，高吞吐量
如果您的服务确实维护状态，则将其配置为“每个会话和多线程一个实例”以允许客户端执行并发调用。注意并发问题并保护资源。
如果您的服务不维护每个客户端的状态，但为所有呼叫保留了一些全局数据，请考虑“每个服务和多线程的单个实例”。请记住可能的并发问题。因此，您可以使用“每个呼叫一个实例”并将全局存储保留在服务之外。
答案 2 :(得分：1)
托管WCF端点的Windows服务适用于不经常被点击的小型服务;你不必乱用IIS（这可能是一个真正的痛苦IMO）。但是，只有一个侦听器正在侦听，因此建议不要同时从多个位置命中的服务（使用IIS;它设置一个可以处理许多同时请求的应用程序池）。这种模式适用于两台机器之间的一对一互操作;您可以在某个仓库中的“设置并忘记”框中设置服务主机，并调用它来执行简单但自定义的任务，如重新启动，日志转储等。
避免让任何用户应用程序（控制台或其他）托管服务端点，但初始概念验证测试除外。除了单一监听器的缺点之外，用户应用程序必须在登录用户的上下文中运行（而不是作为Windows启动的一部分“登录”的服务用户），并且必须具有自定义“keepalive”监测;有了服务，Windows可以被告知如果它崩溃就会重新启动它，而它不会让用户应用程序崩溃而不是为了防止该程序占用整个操作系统（并询问用户是否需要）报告崩溃）。