百万级 J2EE Push Mail 项目后记

《百万级 J2EE Push Mail 项目后记》由会员分享，可在线阅读，更多相关《百万级 J2EE Push Mail 项目后记（3页珍藏版）》请在金锄头文库上搜索。

1、昨天一个新同事向我问起了 Push Mail 的解决方案的整体架构和思路，滔滔不 绝的讲完以后，勾起了我不少的回忆。那是在 3 年前发生的事情，当时这个客当时这个客 户户( (美国人美国人) )的需求就是一句话：的需求就是一句话：“我要做一个我要做一个 PushPush MailMail 全套解决方案全套解决方案。” 就 是这句话我们写了厚厚的一份英文需求文档。从需求分析到最后交付我们将尽 用了 2 年左右的时间，从 系统架构、程序发开、再到系统重构、这样的经历依 然 历历在目。项目当时就我们 5 个人在做，可以说这 5 个人都是百里挑一的人选，但我们需 要面对以下挑战： 1、虽然都是搞 J2

2、EE 的老手，都没有接触过 Push Mail 这样的国外项目，所以 对业务的精髓不能完全吃透，导致理解需求比较吃力。 2、在 3 个月内完成演示版本，证明业务可行性；9 个月内构建完全产品化的系 统。 3、系统需要支持大并发，海量数据，系统必须达到很高性能指标。 4、提供 7X24 及时服务，在第一时间解决任何技术问题。(有时差，客户在睡觉 我们在工作，客户在工作，我们不能睡觉还在工作。) 5、对 J2EE 以外的技术只有 1-2 人了解。比如：分布式计算、应用服务器,数据 库集群技术 和 大型系统的数据、文件 存储方案。但是再我们所有成员的不断努力下，这些困难都被我们一一解决。项目里面牵涉

3、打了 J2EE 领域多项技术，也算是一个难点吧，因为下列技术跨 度都比较大，例如： 1、Servlet (协议请求、回送) 2、XML (协议解析) 3、JavaMail (邮件收发) 4、EJB (分布式计算) 5、ibatis(数据库操作) 6、JMS/MDB (采用分布架构中的内部通讯方式) 7、多线程和线程池 (多任务提取邮件) 8、还有很多 J2EE 规范以外的技术， 例如：httpclient 网页抓取、html 解 析、Office 附件处理、图片压缩 、加密/解密 等等。客户全部选择了将服务器部署在 Amazon 云环境上，大约总共有 40 几台。其中 数据库采用了 MySQL

4、 服务器，我们运用分库+同步技术来解决大规模 存储和查 询，应用服务器我们采用了 Jboss。 MQ 服务器采用的是 Jboss 的 MQ。前端采 用 Apache 和 CDN 做请求压力分载。操作系统采用 64 位的 Ubuntu 8。这个 Push Mail 项目留给我最深的影响就是给我们团队来了丰厚的利润，客户 他是一个美籍印度佬，就是我们常说的那种有钱人，做事爽快、干脆，也是全 球移动领域具有影响的专家，因此他要求我们提供的服务必须是具有一个国际 化专业水准的团队(InternationalInternational CorporateCorporate)。所谓专业化的主要需要体现 在

5、 1 1 执行规范、执行规范、2 2 执行效率、执行效率、3 3 执行细节执行细节 这 3 个重要的环节上。在项目实施过程中除了搞 J2EE 的开发者， TA、QA 、SA、DBA 一个也不能少。1、TA 小组根据制定的项目执行规范监管我们每个开发成员 在每个 stage 和里 程碑的执行力，从需求分析的文档编写规范一直到最后的项目交付从需求分析的文档编写规范一直到最后的项目交付，他们才算 结束使命。2、QA 测试团队在我们需求和概要设计 就开始对 jboss 和 mysql 其他几项技术 学习，其中测试人员与我们一同参与需求分析其中测试人员与我们一同参与需求分析，这样将来他们才知道该如何配

6、合我们做各种测试，进行深入的测试，而不是我们在引导他们在测试，他们 100%能知晓业务 并且制定出不同的测试计划。并不是依靠我们自己测试或者我 们在指导他们测试，那样运动员和裁判员都是同一人，那样肯定出问题。3、SA 的压力最大 需要对系统整体的架构进行设计这个都是分内的事情，更重 要的 在真实生产的环境遇到致命性错误，可以回退或者拿出现成的备份方案， 把问题在短时间内化解。4、DBA 需要从高往低的系统架构层次进行对数据库设计与整体规划，必须根 据客户需求设计出具有远景的 方案，不是一成不变，更不是所谓不是一成不变，更不是所谓“一步到位一步到位” 的规划设计的规划设计，是根据预计的数据增长

7、进行实施规划的不同方案。5、开发者们需要对每个业务模块都要详细了解。因为我们需要降低风险 开发 者们如果出现有人家里有事或者生病 任何一个成员都可以替代，不会出现我今 天不来上班，导致项目进度拖慢一天的现象。在产品在设计开发到发布的过程中，我们分为四个阶段 prototypeprototype、demodemo、stagestage、productingproducting。prototypeprototype 是一个原型，主要完成核心的部分，完成核心的功能和业务逻辑， 开发团队内部评估使用。demodemo 阶段是将产品的主要部分演示给客户看，让客户确认主体的方向。stagestage 根据

8、项目计划分为多个不同的 stage 版本，每个 stage 阶段的版本都会 在 stage 服务器上由我们 测试人员先测试 5-7 天，再发布到真实的生产环境中。 客户对这样的流程要求的非常的严格。因此 stagestage 服务器的配置和数量与 productingproducting 环境是 100%相同的，没有他们的邮件确认我们是不能擅自发布到 productingproducting 环境中的，如果 productingproducting 环境出现问题，必须在短时间内能回 归到上一个稳定版本的状态 。 后期会在 stagestage 和 productingproducting 服务

9、器上轮回 ，fix testing release。我们当时使用 SVN 和 Trac，值得一提的是 Trac 这个东西，客户有任何需求变 更 通过 Trac 系统 TA，QA，DBA，SA 统统都会知道，并且知道我们会在下个 版本 什么时候 会 发布在 stagestage 服务器上，我们也能在第一时间知道他们对 当前版本的 性能情况，客户也能看见但似乎他们并不在意这个结果，因为他们 需要知道我们当前的执行状态是否符合计划，其实 TA 的成员比他们更加关注我们的项目进度，呵 呵。因此，所有人的开发进度执行情况都在 trac 上进行展 现。客户也可以看见，也可以回复，所有信息所有人同步。呵呵，另外那三十几台需要发布应用程序的机器，分别发布不同的应用程序或 者不同的版本不可能完全依靠人工完成，我们需要一个半自动化的工具帮助我 们完成，所以我们选择了 hudson 和自己编写的 liunx 脚本。这样可以提供效率， 并且大大减少了发布时出错的机率。先写这么多，有什么忘记的地方我回头补上，下一篇将开始 讲述 纯纯 技术方面 的那点事儿了。