在XXX產(chǎn)品框架中,我們根據(jù)產(chǎn)品發(fā)展規(guī)劃和業(yè)務領域需要,使用基于JMS技術,通過應用WEBService,開發(fā)了消息中心中間件(簡稱MC)。通過消息中間件,我們可以實現(xiàn)各系統(tǒng)間的異步數(shù)據(jù)交換和事務處理、執(zhí)行不需前臺使用人員干預的如后臺業(yè)務和數(shù)據(jù)同步工作,也可用來處理一些受到安全和其它一些因素制約,導致無法直接通過數(shù)據(jù)庫或應用系統(tǒng)進行處理的受限業(yè)務。
消息中心中間件,包括消息總線和消息客戶端兩部分:消息客戶端負責業(yè)務類消息實例的產(chǎn)生、發(fā)送消息實例到消息總線、接收從消息總線轉發(fā)而來的消息實例、將收到的消息實例交由其載體應用系統(tǒng)進行與之對應的業(yè)務處理等活動;消息總線負責接收從消息客戶端產(chǎn)生并發(fā)送而來的消息實例、消息重建、根據(jù)消息配置進行消息實例重建,將重建后的消息實例轉發(fā)至對應的消息客戶端等活動。

消息客戶端與XXX各應用系統(tǒng)集成在一起,并通過應用系統(tǒng)開放WEBService端口進行消息的發(fā)送和接收等,從而避免單獨部署和發(fā)布所帶來的困難和額外資源消耗。消息總線可單獨部署,也可和消息客戶端一樣,與XXX應用系統(tǒng)集成部署,在XXX產(chǎn)品框架下,有且只需要一套消息總線即可滿足需要。消息配置中心,其作用包括配置和管理消息中心各組成部分的部署方式和訪問信息,以此將消息中心各部有機的聯(lián)系起來;同時,各消息業(yè)務應用,也使用配置文件進行配置化管理,并與消息中心各組成部分進行關聯(lián)配置,從而形成一個統(tǒng)一且開放的整體;其它的如性能優(yōu)化處理、日志記錄等也在配置中心進行配置和管理。

在消息中間件V1.0版本開發(fā)完成后,我們即將其投入實用。在XXX各分子系統(tǒng)這近一年時間的運行和使用過程中,消息中心很好的完成了預定任務,其可靠性、可擴展性和適用性得到很好的驗證。以此為據(jù),通過使用消息中心,開發(fā)出基于消息中心的客戶化應用和業(yè)務活動也在持續(xù)的增加中,到現(xiàn)在為止,已經(jīng)有包括網(wǎng)絡檢測、信息同步、配置更新、電子目錄樹更新、權限同步等諸多應用是基于消息中心應用開發(fā),并很好的使用在XXX各分子系統(tǒng)的測試和內網(wǎng)正式環(huán)境中。
在XXX系統(tǒng)正式接入外網(wǎng)后,通過對業(yè)務進行跟蹤,發(fā)現(xiàn)外網(wǎng)用戶(系統(tǒng))所產(chǎn)生的消息實例無法正常的到達指定的消息總線及消息客戶端。最主要的體現(xiàn)是權限同步消息應用無法正常完成的問題,導致外網(wǎng)用戶權限未得到及時更新。對此過程中消息中心所涉及部分進行分析發(fā)現(xiàn):所有的權限同步消息實例在產(chǎn)生后,不能正常的將此消息實例發(fā)送至消息總線,分析失敗原因,只有一種,那就是”connect time out”。從此信息可看出,應該是外網(wǎng)系統(tǒng)所發(fā)出的消息無法通過WEBService送達指定的消息總線接收端所至。但從內網(wǎng)發(fā)出的同一類消息,其發(fā)送和接收卻又都是正常的。
1、先分析我們系統(tǒng)的整體部署方式,如下圖所示:

根據(jù)外網(wǎng)用戶可正常登錄和訪問系統(tǒng),并可通過系統(tǒng)準確及時的發(fā)出執(zhí)行指令操作,完成其所需的業(yè)務活動來看,網(wǎng)絡方面和系統(tǒng)和硬件方面都不存在問題。
2、在外網(wǎng)環(huán)境下,直接進行各消息客戶端和消息總線的服務的檢測,所發(fā)請求都能夠正確的到達指定目標,WEBService的響應也正常且正確,也就是說,各應用系統(tǒng)加載的消息服務運行也正常。
3、根據(jù)本次檢測需要,另行開發(fā)消息中心專用檢測工具,為本次和今后的行的消息中心檢測和問題分析,作好更充分的準備。
4、通過檢測工具,發(fā)現(xiàn),外網(wǎng)環(huán)境下,消息客戶端和消息總線之間不能夠聯(lián)通,從而找到問題所出:即不知是何原因,導致外網(wǎng)消息與外網(wǎng)的消息總線間聯(lián)絡不通!
5、對外網(wǎng)用戶消息產(chǎn)生和發(fā)送的過程和邏輯實現(xiàn)進行分析:我們發(fā)現(xiàn),為了滿足應用系統(tǒng)外網(wǎng)訪問的需要,我們對消息系統(tǒng)配置信息中服務地址的ServerName進行了偽處理,即在運行時,根據(jù)用戶瀏覽器的請求頭來判斷用戶使用的是哪一個WEB服務器地址,并將此地址動態(tài)的代替消息配置中的各ServerName信息,從而保證各使用用戶只能夠訪問其指定的WEB服務器,從而避免因WEB服務器的不匹配而影響其訪問速度、處理效率等故障的發(fā)生。此方式已在我部門多套同時服務于內外網(wǎng)絡的系統(tǒng)中得到可靠的驗證。
那么,會不會因為ServerName在動態(tài)解釋過程中,因多并發(fā)情況下,因后訪問者將前訪問者的ServerName改寫而導致錯誤的解釋,即將不同網(wǎng)絡用戶的消息地址進行張冠李戴而導致消息無法正常發(fā)送呢?
分析消息中心各部分WEBService生成和使用機制:因系統(tǒng)的并發(fā)性要求較高,在高峰期其在線用戶可達3000人,并發(fā)用戶在300以上,且系統(tǒng)穩(wěn)定性要求極高。為提高系統(tǒng)的性能和穩(wěn)定性,在系統(tǒng)啟動時即將消息中心各部的WEBService連接進行創(chuàng)建和緩存,以提升消息中心資源利用率,并提升其訪問性能。
當存在多網(wǎng)絡用戶訪問時,可能因消息中心存貯的WEBService連接并不是其用戶所使用的那個網(wǎng)絡的WEBService服務地址,此時,消息肯定是無法送達至此用戶所需要的目標的。因此,報”connect time out”錯誤就成必然的了。
既然已找到問題的可能原因,我們立即進行著手分析和解決:根據(jù)部署要求,我們對對消息服務連接服務進行了升級,即將服務請求進行分類處理和實現(xiàn),并在消息配置中對所使用的部署方式、代理實現(xiàn)后,交由測試人員進行部署和測試。
測試結果:令人失望的是,此問題依然存在!在通過外網(wǎng)WEB服務器訪問的系統(tǒng),其消息還是無法發(fā)送至消息總線。由此得知,此種分析方向是錯誤的!
至此,好像已經(jīng)走入了死區(qū),能想到的方式都已經(jīng)想到了,但問題到底出在哪呢?
在一次與同事聊天的過程中,忽然想到一個問題,那就是:我們的消息的產(chǎn)生和應用都是由應用系統(tǒng)和與之集成在一起的消息客戶端自動產(chǎn)生和處理的,此過程中完全不受人工干預和影響。而應用系統(tǒng)是部署在應用服務器中,WEB服務器僅是用來處理用戶的HTTP請求à將此請求轉發(fā)至對應的應用服務器后à將應用服務器的響應返回給用戶。
在此過程中WEB服務器并未對用戶業(yè)的http請求進行過任何業(yè)務上的處理!那么,問題會不會出在WEB服務器端呢?檢查一下消息中心的配置不管是使用ServerName還是寫死IP和域名,我們的消息中心配置的地址都是指向WEB服務器。而在應用系統(tǒng)發(fā)現(xiàn)消息時,其所在位置是應用服務器。而應用服務器是無法直接訪問部署于外網(wǎng)IP中的WEB服務器的,當然,消息無法發(fā)送至目標就成為必然了。

既然已經(jīng)找到問題,那就動手,將消息中心的配置信息指向應用服務器后,重啟應用系統(tǒng)后測試,問題果然解決!
通過應用服務器進行后臺自動處理的,進行HTTP或WEBService活動,其目標必需是它能夠訪問的有效地址!這個問題在以前也曾經(jīng)碰到過,只是由于時間隔得太久,且這些場景應用出現(xiàn)太少,而導致再次發(fā)生。
1、 基于應用系統(tǒng)或后臺自動觸發(fā)的一些業(yè)務邏輯,如其中存在著系統(tǒng)間相互訪問或遠程調用等,必需以應用系統(tǒng)自身為根,進行連接測試;通過外層包裝或其它代理,進行訪問時,必需先剝離過外層包裝或其它代理后,再進行連接測試,并以測試結果,作為決策的依據(jù)!此舉適用于各類系統(tǒng)的架構設計和邏輯實現(xiàn)過程中。
2、 基于中間件產(chǎn)品應用,及時開發(fā)與之配套的檢測和使用工具,是一件必不可少的工作,此舉將為后期的實施和問題分析節(jié)省大量的工作量。