第一部分

項(xiàng)目當(dāng)時就我們5個人在做，可以說這5個人都是百里挑一的人選，但我們需要面對以下挑戰(zhàn)：
1、雖然都是搞J2EE的老手，都沒有接觸過Push Mail這樣的國外項(xiàng)目，所以對業(yè)務(wù)的精髓不能完全吃透，導(dǎo)致理解需求比較吃力。
2、在3個月內(nèi)完成演示版本，證明業(yè)務(wù)可行性；9個月內(nèi)構(gòu)建完全產(chǎn)品化的系統(tǒng)。
3、系統(tǒng)需要支持大并發(fā)，海量數(shù)據(jù)，系統(tǒng)必須達(dá)到很高性能指標(biāo)。
4、提供7X24及時服務(wù)，在第一時間解決任何技術(shù)問題。(有時差，客戶在睡覺我們在工作，客戶在工作，我們不能睡覺還在工作。)
5、對J2EE以外的技術(shù)只有1-2人了解。比如：分布式計(jì)算、應(yīng)用服務(wù)器,數(shù)據(jù)庫集群技術(shù) 和 大型系統(tǒng)的數(shù)據(jù)、文件 存儲方案。

但是再我們所有成員的不斷努力下，這些困難都被我們一一解決。

項(xiàng)目里面牽涉打了J2EE 領(lǐng)域多項(xiàng)技術(shù)，也算是一個難點(diǎn)吧，因?yàn)橄铝屑夹g(shù)跨度都比較大，例如：
1、Servlet (協(xié)議請求、回送)
2、XML (協(xié)議解析)
3、JavaMail (郵件收發(fā))
4、EJB (分布式計(jì)算)
5、ibatis(數(shù)據(jù)庫操作)
6、JMS/MDB (采用分布架構(gòu)中的內(nèi)部通訊方式)
7、多線程和線程池 (多任務(wù)提取郵件)
8、還有很多 J2EE規(guī)范以外的技術(shù)， 例如：httpclient 網(wǎng)頁抓取、html 解析、Office附件處理、圖片壓縮 、加密/解密 等等。

第二部分

這個 Push Mail 項(xiàng)目留給我最深的影響就是給我們團(tuán)隊(duì)來了豐厚的利潤，客戶他是一個美籍印度佬，就是我們常說的那種有錢人，做事爽快、干脆，也是全球移動領(lǐng)域具有影響的專家，因此他要求我們提供的服務(wù)必須是具有一個國際化專業(yè)水準(zhǔn)的團(tuán)隊(duì)(International  Corporate)。所謂專業(yè)化的主要需要體現(xiàn)在 1執(zhí)行規(guī)范、2執(zhí)行效率、3執(zhí)行細(xì)節(jié) 這3個重要的環(huán)節(jié)上。

在項(xiàng)目實(shí)施過程中除了搞J2EE 的開發(fā)者， TA、QA 、SA、DBA  一個也不能少。
1、TA 小組根據(jù)制定的項(xiàng)目執(zhí)行規(guī)范監(jiān)管我們每個開發(fā)成員 在每個stage和里程碑的執(zhí)行力，從需求分析的文檔編寫規(guī)范一直到最后的項(xiàng)目交付，他們才算結(jié)束使命。

2、QA 測試團(tuán)隊(duì)在我們需求和概要設(shè)計(jì) 就開始對jboss和mysql其他幾項(xiàng)技術(shù)學(xué)習(xí)，其中測試人員與我們一同參與需求分析，這樣將來他們才知道該如何配合我們做各種測試，進(jìn)行深入的測試，而不是我們在引導(dǎo)他們在測試，他們100%能知曉業(yè)務(wù) 并且制定出不同的測試計(jì)劃。并不是依靠我們自己測試或者我們在指導(dǎo)他們測試，那樣運(yùn)動員和裁判員都是同一人，那樣肯定出問題。

3、SA 的壓力最大 需要對系統(tǒng)整體的架構(gòu)進(jìn)行設(shè)計(jì)這個都是分內(nèi)的事情，更重要的 在真實(shí)生產(chǎn)的環(huán)境遇到致命性錯誤，可以回退或者拿出現(xiàn)成的備份方案，把問題在短時間內(nèi)化解。

4、DBA  需要從高往低的系統(tǒng)架構(gòu)層次進(jìn)行對數(shù)據(jù)庫設(shè)計(jì)與整體規(guī)劃，必須根據(jù)客戶需求設(shè)計(jì)出具有遠(yuǎn)景的 方案，不是一成不變，更不是所謂“一步到位”的規(guī)劃設(shè)計(jì)，是根據(jù)預(yù)計(jì)的數(shù)據(jù)增長 進(jìn)行實(shí)施規(guī)劃的不同方案。

5、開發(fā)者們需要對每個業(yè)務(wù)模塊都要詳細(xì)了解。因?yàn)槲覀冃枰档惋L(fēng)險 開發(fā)者們?nèi)绻霈F(xiàn)有人家里有事或者生病 任何一個成員都可以替代，不會出現(xiàn)我今天不來上班，導(dǎo)致項(xiàng)目進(jìn)度拖慢一天的現(xiàn)象。

在產(chǎn)品在設(shè)計(jì)開發(fā)到發(fā)布的過程中，我們分為四個階段  prototype、demo、stage、producting。

prototype 是一個原型，主要完成核心的部分，完成核心的功能和業(yè)務(wù)邏輯，開發(fā)團(tuán)隊(duì)內(nèi)部評估使用。

demo 階段是將產(chǎn)品的主要部分演示給客戶看，讓客戶確認(rèn)主體的方向。

stage 根據(jù)項(xiàng)目計(jì)劃分為多個不同的stage版本，每個stage階段的版本都會在stage服務(wù)器上由我們 測試人員先測試5-7天，再發(fā)布到真實(shí)的生產(chǎn)環(huán)境中?？蛻魧@樣的流程要求的非常的嚴(yán)格。因此 stage 服務(wù)器的配置和數(shù)量與 producting 環(huán)境是100%相同的，沒有他們的郵件確認(rèn)我們是不能擅自發(fā)布到 producting 環(huán)境中的，如果 producting 環(huán)境出現(xiàn)問題，必須在短時間內(nèi)能回歸到上一個穩(wěn)定版本的狀態(tài) 。 后期會在 stage 和 producting 服務(wù)器上輪回 ，fix –> testing —> release。

我們當(dāng)時使用SVN和Trac，值得一提的是Trac這個東西，客戶有任何需求變更 通過 Trac 系統(tǒng) TA，QA，DBA，SA  統(tǒng)統(tǒng)都會知道，并且知道我們會在下個版本 什么時候 會  發(fā)布在stage 服務(wù)器上，我們也能在第一時間知道他們對 當(dāng)前版本的 性能情況，客戶也能看見但似乎他們并不在意這個結(jié)果，因?yàn)樗麄冃枰牢覀儺?dāng)前的執(zhí)行狀態(tài)是否符合計(jì)劃，其實(shí)TA的成員比他們更加關(guān)注我們的項(xiàng)目進(jìn)度，呵呵。因此，所有人的開發(fā)進(jìn)度執(zhí)行情況都在trac上進(jìn)行展現(xiàn)?？蛻粢部梢钥匆?，也可以回復(fù)，所有信息所有人同步。

呵呵，另外那三十幾臺需要發(fā)布應(yīng)用程序的機(jī)器，分別發(fā)布不同的應(yīng)用程序或者不同的版本不可能完全依靠人工完成，我們需要一個半自動化的工具幫助我們完成，所以我們選擇了hudson和自己編寫的liunx腳本。這樣可以提供效率，并且大大減少了發(fā)布時出錯的機(jī)率。

先寫這么多，有什么忘記的地方我回頭補(bǔ)上，下一篇將開始 講述 純 技術(shù)方面的那點(diǎn)事兒了。

第三部分

通過這個項(xiàng)目讓我們充分的認(rèn)識到一個用戶的系統(tǒng) 例如：單用戶的 OutLook 和 一個百萬級的系統(tǒng)的是截然不同的，系統(tǒng)中僅有100條數(shù)據(jù)和100w條數(shù)據(jù)的系統(tǒng)更是截然不同的，從100w條數(shù)據(jù)上升到上億條數(shù)據(jù)那樣的系統(tǒng)更會讓人感受到無論從代碼結(jié)構(gòu)、數(shù)據(jù)庫設(shè)計(jì)還是從系統(tǒng)架構(gòu)都是完全不同的設(shè)計(jì)。

客戶端環(huán)境
    MKT    SDK
    C        語言開發(fā)環(huán)境   

服務(wù)器端環(huán)境     
    Apache2            Web服務(wù)器
    mod_proxy        Web負(fù)載均衡模塊   
    HAProxy             前端、數(shù)據(jù)庫負(fù)載分載(后期使用)
    Java EE1.5        語言開發(fā)環(huán)境
    Jboss 4.0.5 GA    應(yīng)用服務(wù)器
    Jboss MQ        JMS服務(wù)器
    MySQL  5.1.4        數(shù)據(jù)庫服務(wù)器
    EJB 3.0            Java 開發(fā)API 工具
    iBATIS            Java 開發(fā)API 工具
    OsCache            緩存組件
    Gluster DFS        分布式文件系統(tǒng)
    Nagios            系統(tǒng)監(jiān)控、報警工具
    Qmail              1臺發(fā)送郵件服務(wù)器

壓力測試工具
    Apache Jemter
    Apache AB

當(dāng)前運(yùn)行狀態(tài)
    每月大約有4000多新注冊用戶
    當(dāng)前注冊大約用戶數(shù)量200-300w
    每天大約有90-110w用戶登錄
    每天大約接收500-700W 封郵件
    每天大約接收附件3-5G，超過5M以上的附件將不接受
    每天數(shù)據(jù)庫增加 2W條記錄
    每天數(shù)據(jù)庫接受 700W 次請求
    每秒并發(fā)最大18000個請求

整體架構(gòu)

概覽
總體上概括，系統(tǒng)分為 1客戶端，2服務(wù)器端，3SP Mail Server 端，4 CRM 端   下面將講述整個系統(tǒng)的概況。

后端發(fā)送郵件實(shí)現(xiàn)過程

1.手機(jī)客戶端通過http網(wǎng)絡(luò)協(xié)議發(fā)送XML數(shù)據(jù)到服務(wù)器端，

2.服務(wù)器端接收到xml數(shù)據(jù)進(jìn)行解析，服務(wù)器端傳輸層的web請求模塊將xml 協(xié)議解析，并且重新包裝成pojo 對象，

3.中間有一個業(yè)務(wù)模塊分發(fā)器將 獲得pojo對象交給不同的業(yè)務(wù)模塊進(jìn)行處理，如：DAL層、消息中間件，

4.將處理完成的業(yè)務(wù)通過業(yè)務(wù)模塊分發(fā)器包裝成xml報文回送給客戶端。

整個業(yè)務(wù)處理組成部分如圖所示：

內(nèi)部業(yè)務(wù)邏輯

1.定時器從數(shù)據(jù)庫裝載帳戶，采用多線程實(shí)現(xiàn)一個線程池，我們稱這個玩意兒叫做任務(wù)工廠，

2.定時向JMS服務(wù)器中不同的消息隊(duì)列發(fā)送消息 ，消息接收端收到消息后驅(qū)動業(yè)務(wù)模塊去 SP Mail Server  收取郵件，

3.收郵件模塊 上SP Mail Server  獲取郵件列表頭信息，并且和數(shù)據(jù)庫中已存在的郵件列表頭信息進(jìn)行新郵件比對，

4.收取新郵件并且將郵件信息保存到數(shù)據(jù)庫或者緩存，當(dāng)用戶需要讀取的時候?qū)南到y(tǒng)的數(shù)據(jù)庫或者緩存中讀取，

5.保存完畢后，將通過IP Push 或者 SMS Push 技術(shù) 通知用戶上服務(wù)器獲得新郵件。

后端內(nèi)部架構(gòu)

Web層
用戶的所有請求都是從web層進(jìn)入，最上層是apache將請求分載到每臺AP 服務(wù)器 Jboss的web容器上，web容器請求處理用戶提交的各種xml請求協(xié)議，并且回送處理結(jié)果xml協(xié)議給客戶端，apache經(jīng)過幾次優(yōu)化并且開了20個進(jìn)程處理用戶所有請求分發(fā)，另一臺apache standby 通過 heartbeat做備份，如果apache server1失效 將會自動轉(zhuǎn)移到 apach server2上去。在項(xiàng)目后期我們采用HaProxy來替代了Apache的轉(zhuǎn)發(fā)工作，也許2者進(jìn)行優(yōu)化后的功效相差不了多少，但是我們認(rèn)為HaProxy安裝、移植、部署 比Apache更加方便，最高可以處理2.7W的并發(fā)請求處理，并且可以采用leastconn 負(fù)載均衡算法，將當(dāng)前連接請求數(shù)量最小的服務(wù)器進(jìn)行命中。

任務(wù)調(diào)度
檢測用戶的新郵件功能依賴系統(tǒng)中的任務(wù)調(diào)度模塊，我們管這個模塊叫做任務(wù)工廠，他先從數(shù)據(jù)庫中裝載賬戶，再放入緩存中，每3分鐘裝載所有賬戶一次，向JMS服務(wù)器發(fā)送消息請求新郵件檢查。
從緩存中讀取是為了降低數(shù)據(jù)庫的壓力， 因?yàn)檫@樣的操作太頻繁了而且數(shù)據(jù)量越來越大，會導(dǎo)致數(shù)據(jù)的壓力增大。任務(wù)工廠是系統(tǒng)中非常重要的模組，如果任務(wù)工廠停止工作將不能檢測到所有用戶的新郵件， 整個Push Mail系統(tǒng)將會癱瘓，所以必須能支持壓力分載和失效轉(zhuǎn)發(fā)的功能。

BTW：任務(wù)工廠模塊最開始在demo的時候采用Quartz 放入Spring微容器中進(jìn)行集群，因?yàn)椴荒軓木彺嬷兄苯幼x取，將來系統(tǒng)賬戶會越來越多，導(dǎo)致數(shù)據(jù)庫那邊的壓力越來越大，所以后期我們用 線程池+oscache集群技術(shù) 自己開發(fā)了一套類似 Quartz+spring集群的方案。另外，這個項(xiàng)目發(fā)生在沒有Memcached的年代，如果當(dāng)時使用Memcached也許設(shè)計(jì)上會更加完美些。

分布式應(yīng)用
國外用戶使用郵箱賬號多數(shù)都是以 Gmail、AOL、Hotmail、Yahoo 4大郵箱為主，所以我們將處理郵件具體操作的機(jī)器分為4組，每組機(jī)器處理具體不同的郵箱賬號的郵件存取，將整個業(yè)務(wù)中負(fù)荷最大的部分進(jìn)行分散，獨(dú)立計(jì)算, 每組中的服務(wù)器都支持 失效轉(zhuǎn)發(fā)和壓力分載。
 

EJB消息驅(qū)動Bean /JMS  消息系統(tǒng)
系統(tǒng)多線程的定時器，將系統(tǒng)中所有用戶賬號裝載后由多個JMS發(fā)送端發(fā)送Queue消息到不同的消息隊(duì)列，例如：Gmail消息隊(duì)列、AOL消息隊(duì)列、Hotmail消息隊(duì)列、Yahoo消息隊(duì)列，然后接收端將接收不同的消息隊(duì)列發(fā)送過來的消息，通常我們每組消息隊(duì)列使用一個發(fā)送端對應(yīng)多個接收端，每組接收端，例如：接收到一批Yahoo賬號的JMS消息，將會由多個接收端，例如：接收到一批Yahoo賬號的JMS消息，接收端將通過消息分發(fā)給不同的計(jì)算機(jī)組，JMS服務(wù)器端采用集群技術(shù)，2臺JMS服務(wù)器上建有4個消息隊(duì)列，不僅可以進(jìn)行壓力分載，還可以進(jìn)行失效轉(zhuǎn)發(fā)。將4大郵箱分為4個業(yè)務(wù)群組，每分組各4臺消息接收端，一共16臺，加上JMS MOM 消息中間件服務(wù)器一共18臺，在得到上層模組傳送過來的指令后，16臺專門進(jìn)行用戶郵件解析、發(fā)送的操作。

數(shù)據(jù)庫
8臺 16 GB內(nèi)存 、4個CPU 的機(jī)器作為 我們使用的MySQL數(shù)據(jù)庫，每臺MySQL數(shù)據(jù)庫都安裝了XtraDB MySQL插件，主要提高M(jìn)ySQL innodb引擎的讀寫性能，對于MySQL的整體性能我們主要還是通過調(diào)整MySQL的內(nèi)部參數(shù)來進(jìn)行優(yōu)化。MySQL原本算使用 NDB引擎來做數(shù)據(jù)同步和單點(diǎn)失效的，經(jīng)過實(shí)際情況我們反復(fù)比對還是使用傳統(tǒng)MySQL數(shù)據(jù)同步來完成我們預(yù)想的效果，因?yàn)镸ySQL的集群在我們當(dāng)時還不算很成熟，而且這玩兒比較消耗內(nèi)存。

分片(sharding)
每個用戶的請求都包含一個用戶的ID，我們將判斷不同的用戶ID到不同的數(shù)據(jù)上進(jìn)行操作，當(dāng)然我們也不是每張表都做拆分，由于用戶越來越多我們只把郵件相關(guān)的表進(jìn)行拆分，例如：郵件列表、郵件內(nèi)容、郵件附件表 3張表近拆分。每張表中都有用戶ID這個字段，DAL層根據(jù)用戶 ID 進(jìn)行判斷 數(shù)據(jù)的路由規(guī)則到具體對應(yīng)范圍的數(shù)據(jù)庫進(jìn)行存取數(shù)據(jù)，比如ID在1-10000之間的用戶對應(yīng)到數(shù)據(jù)庫1， ID在10001-20000范圍對應(yīng)到數(shù)據(jù)庫2，以此類推,但是不能在不停機(jī)的狀態(tài)下動態(tài)添加數(shù)據(jù)庫服務(wù)器節(jié)點(diǎn)，后來我們想了一個辦法，添加節(jié)點(diǎn)的時候通過JMS消息通知每個機(jī)器上的DAL層重新讀取數(shù)據(jù)路由配置一次，系統(tǒng)中的數(shù)據(jù)需要和系統(tǒng)中的CRM系統(tǒng)相結(jié)合，后期我們又建立了一個全局?jǐn)?shù)據(jù)庫(global)，這個全局?jǐn)?shù)據(jù)庫只作為數(shù)據(jù)索引，為了將所有數(shù)據(jù)同步，操作所有數(shù)據(jù)庫的記錄通過JMS消息定時向全局?jǐn)?shù)據(jù)庫(global)進(jìn)行批量操作，如果每筆執(zhí)行同步操作，將會降低系統(tǒng)性能。

分布式文件系統(tǒng)(DFS)
用戶郵件的所以郵件附件都保存在 分布文件系統(tǒng) 前期我們采用Gluster，后期我們采用了MooseFs搭建 使用分布式文件系統(tǒng)是為了能滿足我們2點(diǎn)需求 1、由于系統(tǒng)用戶不斷的增多，導(dǎo)致我們需要保存的郵件附件不斷增長，我們需要可以做到當(dāng)磁盤容量不足時在不停機(jī)的情況下無限的添加存儲的容量，并且操作方便。2、對于保存的數(shù)據(jù)可以實(shí)時同步，防止單點(diǎn)失效，數(shù)據(jù)丟失。

JavaMail
我們將Sun  JavaMail 的源代碼進(jìn)行改寫，提高收郵件的效率，這樣我們在代碼中向POP3郵件服務(wù)器發(fā)送一個命令，立刻在瞬間可以獲得上千份郵件的MessageID的頭信息。可參見 《修改源碼提高JavaMail比較新郵件效率》一文中提到的具體技術(shù)。發(fā)送郵件采用的是Apache 的 Commons email來簡化發(fā)送郵件的操作。

經(jīng)驗(yàn)與教訓(xùn)

1.HAProxy的擴(kuò)展使用，不僅僅可以使用在Web方面，還可以使用到其他應(yīng)用層，進(jìn)行壓力分鐘， 例如，可以應(yīng)用到 數(shù)據(jù)MySQL?？梢詤⒖歼@篇文章，http://www./blog/2009/08/10/using-haproxy-for-mysql-failover-and-redundancy

2.JVM的優(yōu)化是任何大型J2EE項(xiàng)目中必不可少的話題，當(dāng)然并不是你把JVM的內(nèi)存使用空間設(shè)置的越大越好，SUN的官方網(wǎng)站已經(jīng)指出，不同的操作系統(tǒng)，不同的應(yīng)用，建議你的JVM內(nèi)存分配大小是不同的。另外，對與不同的JVM也有不同的參數(shù)配置，通常的JVM配置參數(shù)可以參見這里，http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

3.Linux系統(tǒng)上的swap 空間，4G和4G內(nèi)存 以內(nèi)的機(jī)器還是非常有必要使用swap空間的，有一次有一個應(yīng)用服務(wù)器系統(tǒng)down機(jī)，花了很久的時間才發(fā)現(xiàn)，居然是忘記建立Swap空間，多么簡單的問題啊，可是把我們折磨了3個星期，3個星期里被老板和客戶罵的慘不忍睹，血的教訓(xùn)，讓我們再也不會忘記小內(nèi)存機(jī)器建立swap空間了。

4.Jboss MQ的抱怨，首先聲明我不是在給Apache 的JMS做廣告，因?yàn)镴bossMQ實(shí)在是不好用，而且性能也不咋地，我看見有一篇文章說到JbossMQ的性能在同類產(chǎn)品中是最好的，不知道結(jié)果是怎么來的，還是建議大家還是使用Apache的JMS，文檔全面啊，不懂就可以找到很全面的資料，jboss MQ 資料的支持不多。

5.MySQL的優(yōu)化，MySQL的一些參數(shù)調(diào)優(yōu)就不說了，但使用MySQL 插件以后給我們帶來了不少性能上的提升，特別是在數(shù)據(jù)查詢上的瓶頸可以得到不少緩解。

6.MySQL集群，這玩意兒是個不錯的解決方案，可是沒有足夠的內(nèi)存是玩不起的，因?yàn)镸ySQL的集群因?yàn)橥耆蕾噧?nèi)存，另外對表的字段也有特別的限制，用起來有點(diǎn)不太自然，不支持所有大字段的類型。如果是老系統(tǒng)遷移過來，估計(jì)要折騰一段時間才能合用。

7.JMS 消息的使用，不需要放入數(shù)據(jù)庫，將消息內(nèi)存當(dāng)中，并且對JVM運(yùn)行參數(shù)進(jìn)行優(yōu)化 ，對與客戶端的代碼也需要進(jìn)行優(yōu)化，關(guān)閉消息id (setDisableMessageID),減少消息的大小并且 省去了創(chuàng)建唯一ID的時間。關(guān)閉消息的時間戳。如果不需要時間戳，用MessageProducer的setDisableMessageTimeStamp()方法將其關(guān)閉。避免使用AUTO_ACKNOWLEDGE。 AUTO_ACKNOWLEDGE  使得每收到一個消息就要向服務(wù)器發(fā)送一個通知－－這樣增加的網(wǎng)絡(luò)傳輸?shù)呢?fù)擔(dān)。如果可能，盡量使用 DUPS_OK_ACKNOWLEDGE或者CLIENT_ACKNOWLEDGE?；蛘呤褂檬聞?wù)性會話，將通知在提交時批量完成。