消息中心產品簡介產品簡介
在XXX產品框架中，我們根據產品發展規劃和業務領域需要，使用基於JMS技 術，通過應用WEBService，開發了消息中心中間件（簡稱MC）。通過消息中間件 ，我們可以實現各系統間的異步數據交換和事務處理、執行不需前台使用人員干 預的如後台業務和數據同步工作，也可用來處理一些受到安全和其它一些因素制 約，導致無法直接通過數據庫或應用系統進行處理的受限業務。
消息中心中間件，包括消息總線和消息客戶端兩部分：消息客戶端負責業務 類消息實例的產生、發送消息實例到消息總線、接收從消息總線轉發而來的消息 實例、將收到的消息實例交由其載體應用系統進行與之對應的業務處理等活動； 消息總線負責接收從消息客戶端產生並發送而來的消息實例、消息重建、根據消 息配置進行消息實例重建,將重建後的消息實例轉發至對應的消息客戶端等活動 。
消息客戶端與XXX各應用系統集成在一起，並通過應用系統開放WEBService端 口進行消息的發送和接收等，從而避免單獨部署和發布所帶來的困難和額外資源 消耗。消息總線可單獨部署，也可和消息客戶端一樣，與XXX應用系統集成部署 ，在XXX產品框架下，有且只需要一套消息總線即可滿足需要。消息配置中心， 其作用包括配置和管理消息中心各組成部分的部署方式和訪問信息，以此將消息 中心各部有機的聯系起來；同時，各消息業務應用，也使用配置文件進行配置化 管理，並與消息中心各組成部分進行關聯配置，從而形成一個統一且開放的整體 ；其它的如性能優化處理、日志記錄等也在配置中心進行配置和管理。
應用現狀
在消息中間件V1.0版本開發完成後，我們即將其投入 實用。在XXX各分子系統這近一年時間的運行和使用過程中，消息中心很好的完 成了預定任務，其可靠性、可擴展性和適用性得到很好的驗證。以此為據，通過 使用消息中心，開發出基於消息中心的客戶化應用和業務活動也在持續的增加中 ，到現在為止，已經有包括網絡檢測、信息同步、配置更新、電子目錄樹更新、 權限同步等諸多應用是基於消息中心應用開發，並很好的使用在XXX各分子系統 的測試和內網正式環境中。
問題出現、描述、分析與處理記錄問題出現
在XXX系統正式接入外網後，通過對業務進行跟蹤，發現外網用戶（系統 ）所產生的消息實例無法正常的到達指定的消息總線及消息客戶端。最主要的體 現是權限同步消息應用無法正常完成的問題，導致外網用戶權限未得到及時更新 。對此過程中消息中心所涉及部分進行分析發現：所有的權限同步消息實例在產 生後，不能正常的將此消息實例發送至消息總線，分析失敗原因，只有一種，那 就是”connect time out”。從此信息可看出，應該是外網系統所發 出的消息無法通過WEBService送達指定的消息總線接收端所至。但從內網發出的 同一類消息，其發送和接收卻又都是正常的。
分析過程記錄
1、 先分析我們系統的整體部署方式，如下圖所示：
根據外網用戶可正常登錄和訪問系統，並可通過系統准確及時的發出執行指 令操作，完成其所需的業務活動來看，網絡方面和系統和硬件方面都不存在問題 。
2、在外網環境下，直接進行各消息客戶端和消息總線的服務的檢測，所發請 求都能夠正確的到達指定目標，WEBService的響應也正常且正確，也就是說，各 應用系統加載的消息服務運行也正常。
3、根據本次檢測需要，另行開發消息中心專用檢測工具，為本次和今後的行 的消息中心檢測和問題分析，作好更充分的准備。
4、通過檢測工具，發現，外網環境下，消息客戶端和消息總線之間不能夠聯 通，從而找到問題所出：即不知是何原因，導致外網消息與外網的消息總線間聯 絡不通！
5、對外網用戶消息產生和發送的過程和邏輯實現進行分析：我們發現，為了 滿足應用系統外網訪問的需要，我們對消息系統配置信息中服務地址的 ServerName進行了偽處理，即在運行時，根據用戶浏覽器的請求頭來判斷用戶使 用的是哪一個WEB服務器地址，並將此地址動態的代替消息配置中的各 ServerName信息，從而保證各使用用戶只能夠訪問其指定的WEB服務器，從而避 免因WEB服務器的不匹配而影響其訪問速度、處理效率等故障的發生。此方式已 在我部門多套同時服務於內外網絡的系統中得到可靠的驗證。
那麼，會不會因為ServerName在動態解釋過程中，因多並發情況下，因後訪 問者將前訪問者的ServerName改寫而導致錯誤的解釋，即將不同網絡用戶的消息 地址進行張冠李戴而導致消息無法正常發送呢？
分析消息中心各部分WEBService生成和使用機制：因系統的並發性要求較高 ，在高峰期其在線用戶可達3000人，並發用戶在300以上，且系統穩定性要求極 高。為提高系統的性能和穩定性，在系統啟動時即將消息中心各部的WEBService 連接進行創建和緩存，以提升消息中心資源利用率，並提升其訪問性能。
當存在多網絡用戶訪問時，可能因消息中心存貯的WEBService連接並不是其 用戶所使用的那個網絡的WEBService服務地址，此時，消息肯定是無法送達至此 用戶所需要的目標的。因此，報”connect time out”錯誤就成必然的了。
既然已找到問題的可能原因，我們立即進行著手分析和解決：根據部署要求 ，我們對對消息服務連接服務進行了升級，即將服務請求進行分類處理和實現， 並在消息配置中對所使用的部署方式、代理實現後，交由測試人員進行部署和測 試。
測試結果：令人失望的是，此問題依然存在！在通過外網WEB服務器訪問的系 統，其消息還是無法發送至消息總線。由此得知，此種分析方向是錯誤的！
至此，好像已經走入了死區,能想到的方式都已經想到了，但問題到底出在哪 呢？
問題解決
在一次與同事聊天的過程中，忽然想到一個問題，那就是：我們的消息的產 生和應用都是由應用系統和與之集成在一起的消息客戶端自動產生和處理的，此 過程中完全不受人工干預和影響。而應用系統是部署在應用服務器中，WEB服務 器僅是用來處理用戶的HTTP請求à將此請求轉發至對應的應用服務器後à將應用服 務器的響應返回給用戶。
在此過程中WEB服務器並未對用戶業的http請求進行過任何業務上的處理！那 麼，問題會不會出在WEB服務器端呢？檢查一下消息中心的配置不管是使用 ServerName還是寫死IP和域名，我們的消息中心配置的地址都是指向WEB服務器 。而在應用系統發現消息時，其所在位置是應用服務器。而應用服務器是無法直 接訪問部署於外網IP中的WEB服務器的，當然，消息無法發送至目標就成為必然 了。
既然已經找到問題，那就動手，將消息中心的配置信息指向應用服務器後， 重啟應用系統後測試，問題果然解決！
通過應用服務器進行後台自動處理的，進行HTTP或WEBService活動，其目標 必需是它能夠訪問的有效地址！這個問題在以前也曾經碰到過，只是由於時間隔 得太久，且這些場景應用出現太少，而導致再次發生。
補充與心得
1、基於應用系統或後台自動觸發的一些業務邏輯，如其中存在著系統間相互 訪問或遠程調用等，必需以應用系統自身為根，進行連接測試；通過外層包裝或 其它代理，進行訪問時，必需先剝離過外層包裝或其它代理後，再進行連接測試 ，並以測試結果，作為決策的依據！此舉適用於各類系統的架構設計和邏輯實現 過程中。
2、基於中間件產品應用，及時開發與之配套的檢測和使用工具，是一件必不 可少的工作，此舉將為後期的實施和問題分析節省大量的工作量。
