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

建立大容量基于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；而标准数据库由于实现方便、可扩展性强，其中在inte.net上最常用的为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服务器，复杂程度就大大降低，比较适合中小型站点使用。

原文转自：http://www.ltesting.net