邮件网关架构设计-v0.1.docVIP

邮件网关架构设计 版本　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. 传统方式session ID 11 7.2. RESTful风格推荐的方式 11 7.3. 额外的安全约束 12 8. RESTful客户端开发包 12 9. 可伸缩健壮的服务器 12 10. 附件下载 13 11. 邮件缓存 13 12. 表现层国际化 14 13. 数据迁移 14 14. 区分运营商 14 需求简述 遵从httpmail草案/html/draft-dusseault-httpmail-00。草案主要包括：下载邮件信息、列表方式显示多封邮件信息、浏览邮箱的信息格式定义。 httpmail草案没有涵盖的数据格式我们自行定义，包括黑、白名单，签名档等格式定义。定义的格式模仿草案，保持风格一致。 以RESTful风格发布服务。根据RESTful风格的webservice的要求对所有URL进行严格的定义，在HTTP头中统一接口和资源地址，保证URL是无状态的，方便进行缓存和提高系统的可靠性、可伸缩性。 良好的可伸缩性，避免采用session sticky。 统一部署。现有的Z邮局、全球邮、一大把等邮局将都使用同一个邮件网关，邮件网关将为多个邮件运营商提供服务。 架构总体描述 部署描述 邮件网关作为webmail系统的一部分来部署。一个简要的示意图如下： 该图表示了一个最典型的应用场景： 邮件网关以集群的方式对外提供服务，以RESTful风格发布web service。网关实现web邮件的业务功能，同时为多个领域的邮件运营商服务。 邮件web server负责页面的显示，由于邮件业务转给网关实现了，所以web server的功能比原来大大减少，现在就主要用于保存页面静态资源：html、css、js、图片等，提供给浏览器下载；同时，完成一些不网关不支持的功能，例如：web邮件的发送、与web聊天的集成。每个领域的邮件运营商拥有独立的web server，实现不同领域的页面效果个性化，和附加服务的个性化。 浏览器从web server下载资源，显示出页面效果，使用AJAX技术从邮件网关获取数据，展示给用户，用户输入也直接提交给网关；这个客户端对应两个服务端：画面效果从web server得到，数据和网关通讯。 邮件网关的客户端 邮件网关对外提供RESTful风格的web service，客户端分为以下几类： 浏览器+AJAX：最主要的一个客户端 富客户端：动力工作站这样的客户端 邮件web server：由于和网关分工清晰，原则上应该不需要和网关通讯；只有为保证兼容性的时候需要和网关通讯，例如：满足禁用javascript的浏览器的要求时，需要web server先从网关取得数据，生成带数据的页面后返回给浏览器。 域管理、运营管理：系统集成的客户端 邮件网关对1-3的客户提供邮件主要业务的接口，数据格式优先提供xml+atom的格式；根据1、2客户端的需要可以考虑额外提供json的数据格式。对4客户提供域管理、运营管理的业务接口, 数据格式提供xml的格式。 邮件网关的职责 邮件网关处于webmail系统的核心层，只实现和邮件业务有关的功能。和邮件系统共享一套存储系统（NAS、SQLite、Mysql等），不处理和用户界面有关的工作。用户界面由各领域的web server来生成各自特色的界面。 邮件网关由下而上分为3层： 数据访问层：负责数据的存储，对上层暴露接口，隐藏实现。公司有使用统一存储的考虑，将数据访问层单独封装成一层，有利于日后更换实现。 业务逻辑层：封装web邮件系统的业务逻辑，邮件MIME内容的拼装和解析。 REST层：对外发布RESTful风格的web service接口，对内负责资源到java 服务的映射；针对不同的客户端要求，把java对象进行格式转换成为xml+atom，遵从httpmail草案，json格式作为可选实现。 数据访问层 数据访问层的职责： 提供数据访问抽象 屏蔽各数据源差异 提供透明的缓存 实现方法 本系统涉及的数据源包含：NAS（