网站首页/技术开发列表/内容

[转]创建大容量基于Web的Email系统

技术开发2022-06-27阅读
建立大容量基于Web的Email系统

王波

  最近几年来,基于Web的免费Email系统非常流行。当前,几个著名的免费Email网站基本上已经成为大多数人的选择,建立单纯提供免费Email服务的站点不再像以前那样受到热烈欢迎,但是提供Web界面的Email服务已经成为了一个商业站点为其注册成员提供的基本服务之一。

  一个Email系统可以分为服务器端和客户端,Web界面的Email系统则是将Email客户放在了Web服务器端,因此Email系统所需要实现的是一个Web界面的Email客户。然而,由于这个Email系统要求用户数量较大,因此对于Email服务器也有特定的要求。


  ◆操作系统和用户数据库


  由于提供大容量Email系统对操作系统和数据库的要求非常高,因此,选择合适的操作系统和数据库就是最基本的问题。

    由于提供web和email服务要求稳定性和性能特别高,因此一般都使用unix作为服务器的操作系统,例如hotmail使用freebsd和solaris,国内163等站点也是采用bsd系列。然而, unix的标准email系统也不合适用于这种大容量服务。有的unix系统,例如当前版本的linux,其用户标识只有16位,因此用户数量最多只能有64k,即使unix系统本身支持32位的用户标识,考虑到性能因素,单台服务器支持的用户数量也不要超过10万。  为了具有支持更多用户的可扩展性,一般采用多台服务器同时提供服务,虽然此时仍然可以使用标准unix用户作为email用户,但考虑到安全性、性能以及可管理性,一般采用非unix系统用户来作为email用户。而保存用户数据通常采用支持网络访问的数据库形式,一般常用的有ldap、标准数据库、以及email系统自己实现的用户数据库。其中,ldap由于是提供目录服务的标准,因此应该为最佳的选择,其常用的开放源代码实现为openldap;而标准数据库由于实现方便、可扩展性强,其中在internet上最常用的为mysql;此外,也有使用其他方式实现的。
  ◆邮件的保存


  对于大容量Email系统来说,最关键的技术就是如何处理邮件存储问题,采用何种方式提高存储效率,将决定Email系统的成功与否。

  

  由于用户数量较大,如何保存用户的邮件就是一个非常重要的问题。传统Unix使用一个单一目录来保存所有用户的邮件,在用户数量较多时就极大地降低了文件系统的性能。只有使用多级目录,每个目录下的文件数量有限,才能降低打开文件时的系统消耗,或者不再使用简单的文件来保存邮件,而采用某一种封装形式。完全采取数据库形式来保存邮件,由于用户邮件操作多为文件操作,且大小变化较大,因此会造成性能和存储空间上较大的浪费。

  由于用户数量巨大,并且也要求能被多台服务器同时访问,必须采用存储空间较大的服务器或服务器集群来保存,通过光纤通道或者网络文件系统NFS来共享存储空间,使得每个用户的邮件存储路径对于每个服务器都是一致的。光纤通道是一种非常昂贵的解决方法,更为常用的是使用NFS,可以使用专用的NFS服务器,如NetApp,或者使用带有RAID能力的PC Unix服务器。

  当使用NFS共享存储空间的时候,必须注意一个非常重要的问题:由于NFS缺乏文件锁定机制,在使用传统的用户邮件存储格式mailbox时,由于所有的邮件都保存在同一个文件中,因此进行邮件操作就必须加锁,以保证没有访问冲突,这就使得它不适合NFS存储方式。为了解决这个问题,qmail提出了Maildir存储方式,每个邮件作为单独的一个文件保存在用户个人的邮件目录下,就避免了加锁。因此,常见的免费邮件服务器,一般都采用Maildir方式来保存用户的邮件。

  如果不打算使用共享文件系统的方式来保存用户的邮件,而打算让每个服务器只访问其自己硬盘存储空间上的用户邮件,那么Email服务器和客户端都需要进行定制,使它们能通过用户名来找到用户属于的真正服务器,将访问任务交给这个服务器完成。这种方法的缺点除了所需要的改动较大、系统结构复杂之外,还由于服务器是按用户进行分割的,不利于分担负载。其优点也是由于它不通过网络访问其他服务器,因此可以采用任意的邮件存储格式,包括采用强大的cyrus系统来保存邮件和提供服务。


  ◆邮件服务器软件


  采用什么样的Email服务器软件也将最终影响系统的性能,自己做一套Email服务器可能会得不偿失,现在有两个选择:Sendmail和Qmail。




  标准的Email软件,例如sendmail,虽然也提供了一些包括aliases等方法,来支持非Unix系统用户,但是这些能力对于实现这种Email系统是不够的。为了支持这些Email用户,必须使用自己的Email服务器软件。但是由于现有的Email软件都相当成熟,而且也都是开放源代码的软件,所以惯常的做法都是修改原有的Email软件,如sendmail、qmail等,使其支持特定的Email用户。完全重写一个Email服务软件,从成熟性、稳定性来看并不可取。

  不管从性能上还是安全性上考虑,sendmail并不是理想的选择,而由于qmail本身就支持Maildir,因此就成为了常用的Email软件的基础开发平台。但是需要注意的是,qmail使用GPL许可进行保护,因此基于qmail进行的任何改动,原则上必须公开源代码,这对开发商业应用有一定障碍。当然可以通过不改动qmail,而改动相关的系统库函数,或者采用外挂的方式来绕过这个问题。另一个可选的基础Email软件是postfix,其本身就具备与LDAP、MySQL的接口,几乎不需要改动就能作为邮件系统的一部分。


  ◆Web客户端


  利用什么样的脚本来进行Web Email的客户端编程并无标准,但是如果采用开放资源将会省去很多麻烦。

  

  Web界面Email系统的另一个重要的部分就是Web客户端,这一部分的功能将如同个人计算机中的OutLook,负责给用户提供访问自己邮件的能力。由于Web访问本身是无连接的,因此必须保证用户的安全性。基本上,安全性可以通过登录后建立的会话标识、临时目录,并在程序中进行验证来保证。

  Web客户端必须以统一的方式来访问服务器,它可以通过直接文件访问的方式来获得用户的邮件,或者通过POP3、IMAP等标准协议来访问。对于使用网络文件系统来共享用户邮件的系统,通过直接文件访问的方法最为直接和便利,也不需要额外的消耗。而通过POP3、IMAP协议来访问服务器,其直接的好处就是Web客户端和Email服务器相分离,提高了系统安全性。

  当前,已经有一些相当成熟的开放源代码的Web客户端软件,其中IMP是采用PHP来实现的,通过IMAP协议访问服务器的Web邮件客户端软件;而WING则是采用Perl来实现的另一个Web客户端软件。这些开放源代码软件都相当不错,然而,将这些软件与自己的系统相集成,还会需要进行一定改动。此外,还应该遵循其许可要求,将改动的代码对外公开。


  ◆实现负载均衡


  系统的负载均衡将是长期的问题,它决定了该系统的可扩展性。

  

  由于需要提供给大量的用户进行访问,因此单台服务器不能满足这个需要,而必须要使用多服务器的方式。除了按照功能性进行分割之外,如Web服务器、Email服务器以及文件服务器相分离,还需要对一些资源紧张的服务使用多服务器进行负载均衡。虽然当前一些商业厂家也提出了一些服务器集群的方案,但常用的简单而有效的方法还是DNS循环解析、Web服务器重定位和NAT负载均衡等几种。

  DNS循环解析是为同一个名字分配多个IP地址,它用在Yahoo等相当大的站点上,实际效果也相当不错。而Web服务器重定位则是由Web服务器随机产生位于不同服务器上的真实页面URL,使不同的浏览器载入不同服务器上的页面,使用它只能实现Web客户端的负载均衡。而NAT负载均衡则利用第四层交换机,使同样的请求转向不同的服务器,除了昂贵的交换机之外,也有一些软件能完成NAT功能。本人曾对FreeBSD的natd进行了改动,使其能支持负载均衡,这对于因为交换机价格问题而不得不降低性能要求的使用者来讲,也是一种选择。


  ◆实例分析


  国内有很多Web Email系统,网易、21CN和新浪Email是其中的代表。

  

  当前在国内最流行的Web界面Email系统为网易公司的系统,它是采用qmail作为基本服务器软件,再加以改动的系统。它采用NFS网络文件系统作为用户邮件存储空间,使用Maildir作为邮件存储格式,提供多级目录以支持大量用户。其Web客户端为他们自己实现的,通过直接访问用户邮件的方式为用户提供服务。不考虑其软件的小问题,这种实现方式是非常流行且成熟的方式,大部分免费邮件服务系统都是采用的这种模式。

  另一种方式是尽量利用已有的开放源代码软件,一种可行的方案是使用Postfix、OpenLDAP、cyrus和IMP来实现大容量Email系统。其中,主邮件服务器使用Postfix查询LDAP服务器,决定用户的真实邮箱地址,然后转发到真实邮件主机上,该主机通过LDAP查询确认,将邮件放入cyrus服务器中,而IMP通过登录cyrus,使用IMAP访问用户邮件。当用户增多,一台cyrus服务器不够时,可以将新添加的用户放置到新增加的服务器上,只需要在LDAP服务器设置相应的属性就可以了。在这种方式下,由于用户是严格按服务器分割造成了管理等困难之外,这种结构本身较为复杂。然而,如果用户数量不是很多,就不需要使用多台cyrus服务器和LDAP服务器,复杂程度就大大降低,比较适合中小型站点使用。

……

相关阅读