闪电邮的前世

经过大约一年半的准备和磨合,当初构想的 Lightning Mail Platform 终于开始慢慢成形,为了赶时髦,我决定把它定义为 2.0,之前的那套系统,姑且称之为 1.0 吧。

在我刚刚进入邮件中心的时候,很是被系统的架构震惊了一下(主要是 CGI vs JavaApp 的巨大差异),以前一直觉得 sohu 的技术不咋的,突然发现这个框架还是很有水平,印象比较深刻的有

  1. apache 和后端 resin 的连接上,mod_caucho 自己作了 patch,提升了吞吐量,以及增加了一个简单的任务管理机制。得承认在 eyou 时候比较土,几乎没有想过 apache 也是可以动手脚的
  2. User Lookup DB 是基于 BDB 3.x 开发的。定义了一套同步机制,搞了个 Master-Slave 结构。别的不说,稳定性是比 OpenLDAP 强太多了
  3. 还是 Lookup DB 的服务进程,内嵌了 spidermonkey 引擎,用来作命令解释器。又是让我耳目一新
  4. 漏桶。想象有一个打开底部水龙头的桶,能够以恒定的速度向外流水;调用者时不时的向里加点水,返回结果是桶是否已满。以前作反垃圾邮件的时候也实现了这样的功能,不过是一个内部数据结构,还从没有考虑过抽象出一个独立服务。
  5. 反垃圾邮件包括了一个自动发现相似信件的模块。

其他的子系统还包括:

  1. 邮件桶。上面跑着resin应用服务器,这是和 eyou.com 本质的不同。一个是HTTP代理+应用服务器;一个是CGI+RemoteFS。
  2. 提供客户端连接的SMTP服务器独立分离(不同于MX),被称之为 SMTPOE。这种模式相比较亿邮那样集成在一处的,可伸缩性更好一些
  3. 由于Java没有管道机制,不能简单的调用 sendmail 发信。因此内部设定了一组 smtp server,供web用户发信使用。称之为 websmtp

我猜想以前邮件中心大概有2-3个技术牛人,可惜没有能持之以恒的做下来。

Topic: 技术

评论

呵呵,不错的架构呀

对User Lookup DB 的MASTER与SLAVE的同步机制比较感兴趣.

我们现在已经转移到 BDB 4.7,利用它内置的同步框架实现的 Master-Slave

哦,会不会有主/从数据不同步的问题呢?

基本上,个人要写一个比 BDB 更好的同步协议,我想很难。我们已经跑了2-3个月了,感觉没啥问题

bdb是java edition还是c的?

当然是 C 的... BDB同步框架的 java 支持刚刚发布还不到1个月吧

对于sohu的邮箱,真是感慨啊.

我02年的常有邮箱都是sohu的,很好用,当然是相对当时的情况.周围的同学和朋友用sohu的也很多.

03年我工作了,常用邮箱是公司的邮箱,05年我辞职了,再回头来用sohu的邮箱,大吃一惊,发现已经烂的让人气愤,界面看似更时髦,但是操作体验狗血的厉害,乱码多多,还远不如我02年体验.更让人抓狂的是:每天收到的垃圾邮件从来不少于15封,还都是外国的英文邮件...

从此远离sohu了...

昨天看了个国外讲"工业设计"的视频,其中说到:好的设计是让用户既感受不到产品本身是被设计过的,但是又能体会到背后设计师的用心和诚意.

当时那邮箱给我的感觉就是:设计师是来玩我们的,是来毁搜狐的.

叽歪了这么多,见笑了,作为sohu老用户,还有很有感情的.

呵呵,我只说技术;产品好不好,用户最有发言权,轮不到我来多嘴..