谁能回答我 - 短信/电子邮件门服务如何运作？
一般来说，我需要 asp.net mvc 3 web 应用程序，它应该支持高负载的短信/电子邮件 api（例如，每秒 100-500 个 api 请求）。在这种情况下应该使用什么架构/算法？
我的，我认为是错误的，解决方案（请纠正我，如果它很糟糕）： 1）我的服务有许多 Http（或肥皂等）请求。像“www.example.com/sms-api/send?blabla”。2) 在数据库中插入每个请求 3) Win 服务以状态 = NotInProcess 迭代数据库中的所有行（例如）。4）在一个新线程中处理每个项目（它是否正常/正确？）并执行它（例如，发送电子邮件，记录/等待来自另一个服务的回答等）。
我知道，我的问题应该存在任何“最佳实践”，但我没有找到它......有人可以帮助我解决我的架构问题吗？
它可能比这更复杂一些，特别是处理故障以及您的全部要求是什么。我认为一旦你定义了它，架构可能会更清晰。您正在充当 SMS/电子邮件网关。这意味着无论您通过何种方式发送这些消息，都可能有其自身的故障。这对您的应用程序意味着什么？你自己会失败吗？是否要继续重试发送？
如果您的外部服务失败，并且您失败了，那么只需使用 WCF（或 ASP.NET MVC 4 和WebAPI）执行普通的 REST API 就足够了。
如果您想代表您的客户端不断重试发送消息，那么您可能需要查看类似Microsoft Azure Queues的内容，以及 WCF 中的 REST API（如上）。当客户端连接时，您将添加要发送到 Azure 队列的消息，并使用线程（或辅助角色）来监视新增内容。使用队列的好处是您可以在消息到来时对其进行处理，而且它是持久的。这意味着如果您的服务在尝试发送消息时出现故障，您不会丢失队列中的任何数据。它为您提供了更多的容错能力（假设您正确实施它）。
您可能还想看看的一件事是Quartz.NET。这将使您可以安排线程在特定的时间安排上重复执行。这对于缩放重试机制可能很有用。如果您的外部服务失败，请在 1 分钟后重试。如果再次失败，请在 15 分钟后重试（等）。
这取决于解决方案的要求。
性能：如果排除持久性，您可以节省很多性能点。因为写入数据库非常昂贵。从数据库读取也很昂贵。
可扩展性：将所有传入消息分派到其他主机。一开始，您可以将这些主机放在同一台服务器（Web）上，随着负载的增加，您可以在自己身边添加额外的服务器和主机，或者使用付费云服务并并行发送消息。您还可以将消息发送到持久性和其他所需的主机（我相信您需要身份验证、授权、计费等）
可用性：如果某些主机宕机怎么办？您需要在主机存活后恢复传入数据并继续调度。
可维护性：您应该能够轻松删除/替换/添加新主机、处理、更高/更低负载等。
假设所有这些，我认为非常适合您的问题的架构是 SOA（面向服务的架构）。它可以基于 MSMQ 或 RabbitMQ 作为传输和 NServiceBus 作为框架。在这里阅读更多：http: //particular.net/nservicebus