如果您要在C#(.net 4)中设计透明的SMTP代理,以满足以下初始要求
从广义上考虑这些因素,您的设计会如何？你会创建Listener,Sender和logger具体类或更抽象的东西吗？你会使用回调,线程或进程吗？为什么？
这是一个非平凡的应用程序.一些应该有用的想法:
SMTP可伸缩性
通常,扩展网络应用程序意味着能够扩展(如在更多机器中)而不是向上扩展(更昂贵的机器).这意味着能够让多个服务器能够处理SMTP请求.请注意,这可能需要在网络级别提供支持(可以将消息分发到"SMTP服务器场"的路由器).
是的,要进行SMTP扩展和执行,您可能希望使用多个线程(可能来自某种线程池).请注意,多线程套接字实现并非易事.
就流程而言,我认为每个SMTP服务器具有多个线程的一个进程(可能是Windows服务)是一个很好的方法.
数据库可伸缩性
请记住,数据库也可能是一个可伸缩性瓶颈.要设计大型负载,您还希望能够水平扩展数据层.这意味着能够写入多个数据库服务器.这导致能够从一组数据库服务器报告(这比一个报告要复杂得多).
SMTP可靠性
这是一个问题/要求吗？如果是这样,这是支持服务器场的另一个原因(好吧,如果我们有多个服务器用于可靠性,我们可以称之为集群)服务器而不是一个服务器.请注意,服务器场必须让集群知道它已经失败(通过某种心跳机制).
数据可靠性
为了使数据库可靠,您还必须进行一些群集.这既不便宜也不琐碎(但已经在许多数据库平台上进行了多次).
排队
处理服务器负载浪涌的一种方法是对消息进行排队.这样,服务器可以继续传递消息,但您不会等待可扩展模块链完成其处理.请注意,这会给系统增加另一层复杂性和失败点.
可扩展性
添加诸如数据库日志记录和附件扫描之类的功能的一种方法是添加"MessageInsepctors"或"MessageHandlers"链.您可能希望允许以特定顺序配置这些(例如,在记录之前进行病毒扫描,这样您就不会记录受感染的项目).
要考虑的另一个方面是哪些插件可以阻止邮件通过(例如病毒扫描程序)和插件,该插件可以在邮件通过后执行(日志记录).
在添加插件支持方面,您可以使用类似MEF(Managed Extensibility Framework)的东西.
重新发明轮子
将所有这些功能放到适当的位置需要相当长的开发时间.购买现成的解决方案可能更便宜/更快/更容易为您完成所有这些(此问题已经解决了很多次).
| 归档时间： |
|
| 查看次数： |
1111 次 |
| 最近记录： |