我们的问题之一是我们的出站电子邮件服务器有时会很糟糕。用户会在我们的应用程序中触发一封电子邮件，而该应用程序可能需要大约30秒的时间才能真正发送。让我们更糟的是，承认我们甚至没有在后台线程上这样做，所以用户在这段时间内被完全屏蔽。SQL Server数据库邮件被提议作为这个问题的解决方案，因为它基本上实现了一个消息队列，并且在物理上比我们的第三方电子邮件主机更接近，响应速度更快。无可否认，它对我们来说也很容易实现，因为它只是用存储过程的执行来代替对SmtpClient.Send的一次调用。我们的大多数申请电子邮件都包含PDF、XLS等，我看到这些附件的大小高达20MB。
使用数据库邮件来处理我们所有的应用程序电子邮件对我来说很糟糕，但考虑到实现成本极低，我很难说服任何人放弃它。我们的生产数据库服务器太强大了，所以我也不确定它是否不能处理负载。有什么想法或更安全的替代方案吗？
你所要做的就是通过SMTP服务器运行它，如果你计划发送大量邮件，那么你不仅需要平衡服务器(如果你计划一次发送10万封以上的邮件，还需要平衡DNS服务器)的负载，还要确保你的出站电子邮件服务器在DNS中注册了正确的a记录，以防止反弹。
这是一个廉价的解决方案(减去负载均衡器的成本)。
是的，将内部局域网和互联网的服务器双重归属，并确保它是一个仅出站的服务器。从一台SMTP服务器开始，如果你一开始就遇到瓶颈，看看它是否与内存、磁盘、网络或负载有关。如果它与负载相关，那么可能是时候考虑负载平衡了。如果它与内存有关，就向它扔更多的内存。如果它与磁盘有关，则向它扔一个raid 0+1数组。如果它是与网络有关，则使用更大的管道。