邮件网关架构设计v01.docx
- 文档编号:10185902
- 上传时间:2023-02-09
- 格式:DOCX
- 页数:15
- 大小:114.08KB
邮件网关架构设计v01.docx
《邮件网关架构设计v01.docx》由会员分享,可在线阅读,更多相关《邮件网关架构设计v01.docx(15页珍藏版)》请在冰豆网上搜索。
邮件网关架构设计v01
邮件网关架构设计
版本 0.1
历史记录
作者
日期
版本
原因
吴海波、程云
2009-5-8
0.1
创建文档
目录
1.需求简述4
2.架构总体描述4
2.1.部署描述4
2.2.邮件网关的客户端6
2.3.邮件网关的职责6
3.数据访问层8
3.1.数据访问层的职责:
8
3.2.实现方法8
3.3.数据访问层特点8
3.4.缓存8
3.5.邮件解码9
3.6.SQLite数据访问9
4.业务逻辑层9
5.REST层9
5.1.REST层的职责:
9
5.2.实现方法10
6.Session的处理10
7.用户登录、身份认证11
7.1.传统方式sessionID11
7.2.RESTful风格推荐的方式11
7.3.额外的安全约束12
8.RESTful客户端开发包12
9.可伸缩健壮的服务器12
10.附件下载13
11.邮件缓存13
12.表现层国际化14
13.数据迁移14
14.区分运营商14
1.需求简述
1.遵从httpmail草案http:
//tools.ietf.org/html/draft-dusseault-httpmail-00。
草案主要包括:
下载邮件信息、列表方式显示多封邮件信息、浏览邮箱的信息格式定义。
2.httpmail草案没有涵盖的数据格式我们自行定义,包括黑、白名单,签名档等格式定义。
定义的格式模仿草案,保持风格一致。
3.以RESTful风格发布服务。
根据RESTful风格的webservice的要求对所有URL进行严格的定义,在HTTP头中统一接口和资源地址,保证URL是无状态的,方便进行缓存和提高系统的可靠性、可伸缩性。
4.良好的可伸缩性,避免采用sessionsticky。
5.统一部署。
现有的Z邮局、全球邮、一大把等邮局将都使用同一个邮件网关,邮件网关将为多个邮件运营商提供服务。
2.架构总体描述
2.1.部署描述
邮件网关作为webmail系统的一部分来部署。
一个简要的示意图如下:
该图表示了一个最典型的应用场景:
1.邮件网关以集群的方式对外提供服务,以RESTful风格发布webservice。
网关实现web邮件的业务功能,同时为多个领域的邮件运营商服务。
2.邮件webserver负责页面的显示,由于邮件业务转给网关实现了,所以webserver的功能比原来大大减少,现在就主要用于保存页面静态资源:
html、css、js、图片等,提供给浏览器下载;同时,完成一些不网关不支持的功能,例如:
web邮件的发送、与web聊天的集成。
每个领域的邮件运营商拥有独立的webserver,实现不同领域的页面效果个性化,和附加服务的个性化。
3.浏览器从webserver下载资源,显示出页面效果,使用AJAX技术从邮件网关获取数据,展示给用户,用户输入也直接提交给网关;这个客户端对应两个服务端:
画面效果从webserver得到,数据和网关通讯。
2.2.邮件网关的客户端
邮件网关对外提供RESTful风格的webservice,客户端分为以下几类:
1.浏览器+AJAX:
最主要的一个客户端
2.富客户端:
动力工作站这样的客户端
3.邮件webserver:
由于和网关分工清晰,原则上应该不需要和网关通讯;只有为保证兼容性的时候需要和网关通讯,例如:
满足禁用javascript的浏览器的要求时,需要webserver先从网关取得数据,生成带数据的页面后返回给浏览器。
4.域管理、运营管理:
系统集成的客户端
邮件网关对1-3的客户提供邮件主要业务的接口,数据格式优先提供xml+atom的格式;根据1、2客户端的需要可以考虑额外提供json的数据格式。
对4客户提供域管理、运营管理的业务接口,数据格式提供xml的格式。
2.3.邮件网关的职责
邮件网关处于webmail系统的核心层,只实现和邮件业务有关的功能。
和邮件系统共享一套存储系统(NAS、SQLite、Mysql等),不处理和用户界面有关的工作。
用户界面由各领域的webserver来生成各自特色的界面。
邮件网关由下而上分为3层:
1.数据访问层:
负责数据的存储,对上层暴露接口,隐藏实现。
公司有使用统一存储的考虑,将数据访问层单独封装成一层,有利于日后更换实现。
2.业务逻辑层:
封装web邮件系统的业务逻辑,邮件MIME内容的拼装和解析。
3.REST层:
对外发布RESTful风格的webservice接口,对内负责资源到java服务的映射;针对不同的客户端要求,把java对象进行格式转换成为xml+atom,遵从httpmail草案,json格式作为可选实现。
3.数据访问层
3.1.数据访问层的职责:
1、提供数据访问抽象
2、屏蔽各数据源差异
3、提供透明的缓存
3.2.实现方法
本系统涉及的数据源包含:
NAS(用于存储邮件及解码后的缓存),SQLite(存储用户个人个人设定),MySql+Memcache(存储系统全局信息,如用户帐号信息等)。
数据访问层提供一个底层数据访问的抽象层。
数据访问层使用WebX1.5实现。
无论是基于NAS,还是基于SQLite,MySql数据库,数据访问层提供统一接口,屏蔽各种数据访问的差异。
数据访问层分为抽象(interface)和实现(class)。
实现部分(implementation),基于NAS的,使用文件系统访问实现。
基于SQLite,MySql的应以Hibernate实现(亦可以考虑Jdbc实现)。
3.3.数据访问层特点
数据访问层需要实现对数据访问的封装,具有以下一些特点:
1.可替换,封装底层实现。
如Hibernate实现可以被替换成Jdbc实现,而之上的服务层不需要做代码修改。
2.屏蔽各数据源的差异,为Service层提供统一的访问抽象。
3.提供透明的缓存服务
3.4.缓存
数据访问层的缓存对Service层是透明的。
即Service层无需了解数据是从数据源得到的还是从缓存得到的。
从系统数据源区分,有两个地方需要用到缓存。
一个是Mysql数据库,使用memcache作为缓存;另一个是NAS邮件存储。
1.Mysql数据库的缓存
可以直接使用WebX提供的memcache组件。
2.NAS系统缓存
由于邮件是以文本格式存在NAS系统中,所以读取一封邮件时需要对邮件解码。
由于解码过程较复杂,如果对一封邮件反复解码将无端增加服务器压力,所以这个解码后的邮件需要缓存,以备今后重复使用。
3.5.邮件解码
一封邮件是以文本格式存在NAS系统中。
一封典型的邮件有标题、收发件人等信息,还有正文信息,所带附件等。
这些信息都以Base64格式编码为一个文本格式的文件。
邮件解码就要求把这个文本文件解析为一个Java对象,同时应该把附件解码,作为缓存保存到NAS系统中。
并且,根据系统对附件下载的规则,得到附件的下载地址。
这样我们解码后的Java对象,就包含:
标题、收发件人、正文、附件下载地址等信息。
3.6.SQLite数据访问
需要注意的地方是,WebX的数据访问实现,默认方式是假定数据源是固定不变的。
也即数据访问Dao实现,要求Dao对象线程安全。
而在本系统中,SQLite是有多个,根据用户不同访问的SQLite不同,这样,我们就不能简单使用IOC注入的方式了。
这需要对WebX数据访问实现做扩展。
使数据访问可以在每个线程中使用独立的Dao对象。
4.业务逻辑层
本层包含WebMailGateway的业务逻辑。
5.REST层
资源是RESTful引入的概念,webservice对外的暴露的就是资源。
其它两层和一般的java开发没有区别,实现RESTful的功能都在本层完成。
5.1.REST层的职责:
●HTTP、HTTPS通讯
●处理URL到资源的路由映射
●实现RESTful风格的接口
●客户端输入数据转换成java对象
●调用业务逻辑层的接口,来完成业务操作
●返回的结果java对象转换成xml+atom或者json等数据
5.2.实现方法
采用Restlet框架(http:
//www.restlet.org)作为实现RESTful的框架。
Restlet框架完全抛弃了ServletAPI,作为替代,自己实现了一套API。
能够支持复杂的REST架构设计。
本层对应的职责用如下方法实现:
●HTTP、HTTPS通讯:
配置Restlet的Connector,可以选择多种实现:
Internal、Grizzly、Jetty、Simple等
●处理URL到资源的路由映射:
设置Restlet的Routers,URL的定义规则可以自由控制,可以定义出优雅简洁的RESTful风格的接口
●实现RESTful风格的接口:
继承Resource 类,实现对应的方法。
本层应用程序的代码主要编写在这里
●客户端输入数据转换成java对象:
如果是简单变量就直接取出;复杂的webform数据,则用webx的populator工具进行转换
●调用业务逻辑层的接口,来完成业务操作:
在Resource 类中完成这步调用,与springframework集成,把service实例注入给Resource ,类似于strutsaction中调用service,
●返回的结果的java对象转换成xml+atom:
使用org.restlet.ext.atom,格式定义遵从httpmail草案
●返回的结果的java对象转换成json:
使用org.restlet.ext.json
Restlet框架沿用了filter的概念,web开发中常用filter实现用户身份认证、访问控制的方式,在Restlet中依然可以继续使用。
6.Session的处理
Restlet框架完全不支持服务器端的HTTPSession,强制完全基于无状态服务器模型来做开发。
对于基于浏览器的应用来说,开发难度较高,因为不少应用都需要Session的支持。
对于Session的使用我们采用两个原则:
●尽量不使用session。
调整一下开发习惯。
客户端的状态保存在客户端。
例如:
用户查看分页列表,当前正在浏览的页码信息,应该保存在客户端,每次提交请求时发送给服务端。
服务端的状态就是资源的状态,在服务端用持久化方法保存。
有些状态既可以理解为客户端状态也可以理解为服务端状态,而且在客户端实现难度较大,可以定义为服务端的资源来实现。
例如:
电子商城的购物车,用javascript实现纯客户端物品的添加删除的编程难度较大。
这时可以定义成一个资源保存在服务端,不使用session来保存。
●如果为了简化开发等原因,不得已使用session,也要避免sessionsticky。
Session要保存在邮件网关都可以共享访问到的位置,例如:
NAS中。
这种情况下session的实现:
包括存取、超时处理等需要我们自己编程完成。
7.用户登录、身份认证
邮件网关用户身份认证功能作为一个可插拔的模块实现。
用restlet框架的filter机制插入到系统中。
首先实现本地身份认证,日后再完成SSO要求的身份认证。
保证用户身份认证对于业务接口实现透明,可以方便更换或添加不同的身份认证方案。
7.1.传统方式sessionID
用户登录、身份认证的功能最常见的实现就是:
客户端提交给服务端用户名、密码,服务端检查用户的身份,发放给客户端一个sessionID。
客户端在随后的每个请求中,都使用cookies来携带sessionID,服务端根据sessionID来确定用户的身份。
这一套机制在Restlet中依然可以采用。
Restlet用Cookie和CookieSetting支持cookies的使用。
依照上一节描述的,session的机制需要我们自己来实现。
这种方式适用于基于浏览器的应用,和我们熟悉的方式保持一致。
另外,在URL中后缀sessionID的方式,建议不要采用。
因为这种方式,把所有资源的标识都和session相关了,不能准确标识资源,不利用缓存的实现。
例如:
一个用户(test@)收件箱资源的URL可能是:
。
如果加入sessionID,用户第一次登录可能是如下的形式:
用户第二次登录可能就变成如下的形式:
同一个用户的收件箱加入sessionID就拥有不同的URL。
客户端没有办法有效实现缓存。
如果webservice用于系统集成,客户端如果不是浏览器时,sessionID的方式反而不方便了。
这种情况下客户端没有cookies的概念,就需要我们采用RESTful风格推荐的方式。
7.2.RESTful风格推荐的方式
如何在Restlet框架中不使用session来实现该功能呢?
可以使用rfc2617中定义的两种方案:
基本方案(BasicAuthenticationScheme)、摘要访问方案(DigestAccessAuthenticationScheme)。
这两种方案要求客户端的每一次请求都进行认证,这样服务端就不用记忆用户的sessionID。
Restlet框架已经实现了:
rfc2617基本方案和亚马逊WS方案(AmazonWebServicesscheme)。
我们可以使用Restlet框架的Guard 类(一种filter)来加入用户身份认证。
rfc2617基本方案实现简单,建议优先采用。
由于是明文发送用户名和密码,所以安全性不高。
安全性和普遍采用的form发送一样,适用与对安全要求不高的场合。
对于安全要求较高的场合,建议结合SSL提高安全性。
rfc2617摘要访问方案由于密码不在网络传递,所以安全性高于基本方案。
但是实现较为复杂,而且这个方法有个致命问题,要求用户密码明文保存在服务端,会成为数据迁移的巨大障碍。
并且摘要访问方案的安全性也不如“基本方案+SSL”,建议不予采用。
7.3.额外的安全约束
服务器之间通讯时,除了上述的用户认证方法外,还可以加入IP地址限制的额外访问控制,只允许受信任的IP地址段访问系统集成的接口。
8.RESTful客户端开发包
为方便客户端开发,系统应提供客户端开发包。
WebMailGateway提供REST风格的WebService,客户端通过WebService方式调用。
假设一个场景,客户端是Java程序,需要通过http请求得到一个xml格式的响应,然后解析xml得到一个Java对象。
如果能提供客户端开发包,则,客户端只需调用相应的API即可。
这样方便客户端开发。
且,在系统开发中,我们也需要做测试,如果有相应的开发包,也可方便的实现测试。
如果有相应的客户端开发包,在项目集成时,就不必从底层实现开始,直接使用提供的客户端API即可。
根据服务器端的响应格式有Xml+ATOM和JSon两种。
客户端API应针对这两种格式提供API。
考虑客户端场景,应该提供基于Java,JavaScript语言的两种客户端开发包。
9.可伸缩健壮的服务器
除了默认的实现,Restlet提供Grizzlyconnector和Grizzly(GlassFish的HTTP引擎)集成,来实现http、https的通讯协议,使用JavaNIO来构建一个扩展性能很高的服务器。
邮件网关可优先采用Grizzly替代Restlet默认的实现。
具体的配置方法和使用效果需要测试验证。
10.附件下载
Webmail的邮件附件在下载前会以文件的形式存储在服务端的NAS中,用户通过http协议进行下载。
附件的下载有如下需求:
进行访问控制,用户只能下载属于自己的附件;
下载效率要高,对服务器内存不要造成过大的压力。
传统的Web服务器在处理文件下载的时候,总是先读入文件内容到应用程序内存,然后再把内存当中的内容发送给客户端浏览器。
这种方式在应付大负载网站有些力不从心。
sendfile是现代操作系统支持的一种高性能网络IO方式,操作系统内核的sendfile调用可以将文件内容直接推送到网卡的buffer当中,从而避免了Web服务器读写文件的开销,实现了“零拷贝”模式。
grizzly-sendfile(
grizzly-sendfile能否和restlet顺利集成,使用效果是否高效稳定,还需要我们测试验证。
11.邮件缓存
用户在web客户端查看一封邮件,邮件网关需要进行邮件MIME内容的拼装和解析,才能把邮件的内容发送给用户。
这步“MIME内容的拼装和解析”比较耗费资源,希望可以不用重复执行,使用缓存,提高用户下次访问的速度。
《邮件3.0.pdf》中提出了一个基于session的缓存方案。
这里针对RESTful的特点,对这个缓存方案进行一些修正。
首先充分利用客户端的缓存。
RESTful的特色就是充分利用HTTP协议内建的缓存机制。
一封已发送或已接受的邮件可以看作是一个静态的资源。
因为除了草稿邮件,邮件是没有修改机制的。
这样特别有利于HTTP协议的客户端缓存。
●邮件的正文:
可以设定很长的有效期,让客户端(浏览器)长时间缓存该邮件,一旦查看了这封邮件,可以不再向去服务端发出请求,直接使用客户端的缓存,速度奇快,可以跨越用户多次登录,只要使用同一个客户端多次session都可能使用客户端的缓存。
●用户收件箱:
收件箱中邮件标题列表是动态变化的,也可以使用客户端缓存。
服务器在HTTPResponse中加入Last-Modified或Etag,客户端再次请求资源时会把这些信息附带上,服务器可以根据这些信息判断邮件标题列表是否有变化,如果没有变化,就不用重新发送内容,指示客户端放心使用缓存。
这样也节省了网络数据的传输,带来良好的用户体验。
服务端也使用缓存,但不和session绑定。
一个资源(邮件正文、附件、图片)只有一份缓存,不同别名的用户使用一个用户ID登录时共享一份缓存。
缓存的过期时间不是session过期的时间。
可以考虑和资源本身相关的算法:
记录下每个资源最后一次被访问的时间戳,长时间没有被访问的资源可以被缓存清理软件删除。
12.表现层国际化
在需求中提到,WebMailGateway的客户端有国际化显示的需求。
国际化应该在客户端做。
WebMailGateway不提供直接国际化的数据。
因为国际化数据在表现上可能是多种多样的。
比如,对于一个状态的描述,可能是文字,也可能是图片,具体表现为什么内容,应由客户端决定,客户端的改变,也不影响服务端即WebMailGateway.这样可以避免当客户端表现形式有变化时需要WebMailGateway作出相应的改变。
在集成或使用WebMailGateway时,客户端应该了解各数据项是什么含义,并自行决定表现形式。
可以由WebX提供国际化显示的功能,供Java客户端集成时使用。
13.数据迁移
现有运营的系统,如果要做迁移,应该制定详细的迁移计划。
由于现有系统用户数量庞大,数据量庞大,应该分批迁移。
在保证现有系统不停机、服务不暂停的情况下,分批迁移。
可以考虑每次迁移数个域,每次迁移都在深夜进行。
这样可以最大程度避免我们系统自身升级给用户带来的不便。
14.区分运营商
需求中提到的,统一部署和统一运营的要求。
需要在WebMailGateway提供的接口中区分不同的运营商。
系统提供的接口使用者分为这样三类:
1.邮件用户。
2.域管理员。
3.运营管理员。
对于邮件用户和域管理员,只要他们的账户确定,就能确定他们的域,域确定了,就能确定他们所属运营商。
所以无需在接口上区分他们的运营商。
运营管理员则需要在接口上标明所属运营商。
所以在提供的接口中,属于运营管理的接口,需要提供运营商标识。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 邮件 网关 架构 设计 v01
![提示](https://static.bdocx.com/images/bang_tan.gif)