您好,登錄后才能下訂單哦!
先了解點問題:
◎ 是否擔心數據丟失,比如丟失率 1%?
◎ 系統時效性要求是否很高,比如是:實時、秒級、分鐘級還是小時級?
◎ 系統間網絡環境是否OK,比如是:互聯網、同機房、同城專線?
◎ 系統間有無安全通訊信道等問題需要保障?
給點初步建議:
◎ 不暴露數據庫,否則:人家統計你等待、人家鎖表你死機、人家改數你糾錯;
◎ 約松耦合越好,能批處理就不要實時處理,能用數據交換就不用接口調用,能用異步接口就不用同步接口;
◎ 是不是WebService隨意,不過現在有不少輕量級方案,主要還是看安全性和性能要求了。
4種系統間交互方法比較 | ||||
指相對獨立子系統間的交互 | ||||
指標\方式 | API | 數據文件 | 共享數據庫 | (web系統)根域名cookie |
實效性 | 高 | 低 | 最高 | 實時 |
時間效率 | 高 | 低 | 最高 | 低 |
實時空間效率 | 低 | 高 | 低 | - |
實時占用帶寬 | 低 | 低 | 低 | 低 |
系統設計正交性 | 高 | 高 | 低 | 低 |
系統設計耦合度 | 低 | 低 | 高 | 高 |
實現方式 | 同步/異步 | 異步 | 異步 | 異步 |
協議 | http request,socket,… | ftp,telnet,http,https,iSCSI,nfs… | mysql,MongoDB… | http,https |
數據結構 | 自定義 | xml,yaml,csv,excel,txt,binany,… | database | |
適用場景 | 時效性要求高,請求次數多,請求頻率很高 | 時效性要求低,數據量小或中,請求頻率最低 | 時效性要求最高,系統中,某幾個對數據請求次數很高,請求頻率最高 | 需要記錄在瀏覽器中的信息 |
舉例 | 單點登錄中,cas服務器和cas客戶端之間的交互 | 財務系統和銀行的對賬文件 | 計費系統的數據庫 | 單點登錄系統中的登陸信息(ticket等) |
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。