近期在弄一個業務系統，這個業務系統本來是有一個架構的，但是在後期擴展時發現問題多多。關鍵擴展很是不方便，而且因爲業務系統安全規格較高。數據網絡鏈接需要經過多個閘口傳遞纔可，而且業務系統可能需要多地系統聯合組網。共享業務數據，但是各地系統又必須相互獨立。數據庫

用戶但願改動架構，讓系統可擴展性添加，同一時候要知足系統相互獨立方便升級和興許開發。安全

依照用戶的要求我考慮使用一個基於消息傳遞的架構設計來知足需求。網絡

所謂基於消息，就是經過消息中轉server，中轉所有系統間鏈接數據，同一時候管理數據路由，由消息中心詳細消息的目標。架構

事實上相似的系統我在很是多年前使用過，當時的需求是基於不一樣物流行業間的數據交換設計的，作過物流行業的人都知道，物流行業數據（如：海關報關數據，船公司航次數據，箱信息等）都是經過EDI報文方式相互傳遞的，海關的系統和客戶的系統毫無關係。他們經過暴露的EDI數據接口相互鏈接，當時我作了一個消息server功能比較單一，做爲消息中轉server，可以接收來自海關的EDI報文，同一時候可以經過多種方式將EDI報文發送（FTP，Email等）給指定用戶或者直接保存到本地數據庫，也會定時經過數據庫數據製做EDI報文依照配置發送。也就是說當時這個程序需要作的。提供一個暴露接口給外部，外部系統可以經過這個接口向內部發送EDI，程序對接收的EDI報文進行分析並將結果保存入數據庫中。它還需要在指定時間內依據配置制查詢數據庫做符合要求的EDI報文併發送給指定用戶。併發

當前業務系統設計中，儘管仍是使用相似的結構。但是消息server的功能將被大大的減弱。消息server將僅僅作消息的轉發，再也不像EDI報文系統裏那樣什麼事情都會去作。負載均衡

1、架構需求異步

客戶業務系統在各地分公司都是獨立執行的，分公司之間的數據在必定條件下可共享，但各系統必須是獨立存在。函數

可以將分公司理解爲相互無關的獨立企業。但企業間在需要時可以相互協做。spa

各地數據聯網時需要經過多個安全閘口，因此數據需要在各閘口間方便搬運。但願系統寬展性好，之後添加新系統儘可能不要更改結構。架構設計

2、架構設計

依照用戶架構需求，考慮使用消息server連接所有設備，結構如圖2.1

2.1

第一反應是否是很是像WCF的結構？但是仍是有差異，消息server不處理不論什麼的東西，僅依照給定的路由地址轉發到指定server處理消息。

如上圖所看到的。所有的業務服務都由消息server串聯起來。

比方，當業務系統需要將數據保存到數據庫時。業務server首先處理完業務相關的數據。而後將需要保存的業務數據發給消息server進行轉發。

消息處理server接收到數據後會依照數據指定的路由發送消息，此樣例中會發送給數據server，數據server接收到數據後會依照數據要求將消息轉會爲可以保存到數據庫中的格式並存入數據庫。

簡單的講，每個處理環節由單獨的server完畢，各司其職互不干涉。當架構中需要添加新環節時也不會產生連鎖影響。

因爲所有的系統都是獨立的，之間僅經過消息系統關聯。

數據可路由傳送。當數據沒法從一點直接到達還有一點時可經過中轉數據包到達。而且目標是可以多個的，比方目標爲數據server和郵件server

3、程序結構

這裏僅僅說一下簡單的程序結構。所有的消息都必須包括路由信息（比方一個或多個目標），需要包括驗證信息。各節點都應該驗證信息正確性。

各節點程序獨立執行，訪問數據以實體串行化後進行傳送，傳送過程是異步的，當發送數據完畢後結果將經過異步方式返回給發送方並經過消息ID肯定詳細數據。以後異步調用消息回調函數處理興許事件。

因爲消息是經過消息server轉發的，因此各模塊都可以獨立開發，管數據操做的管數據操做（同一時候可以被隔離在安全地帶），管業務的管業務，做爲消息server同一時候可以經過負載均衡設置分配不一樣的server來處理消息（因爲模塊獨立，並行擴展很的方便）