解web
決數據庫
方安全
案服務器
XXXX科技有限公司微信
XXXX年XX月網絡
目錄架構
本文檔的詳細描述了修車養車網支付系統項目的每一個功能的設計方案。例如功能的需求來源,與各功能模塊之間的關係,功能操做流程示例,序列圖,程序設計,外部接口,數據庫設計等。開發人員可經過閱讀該文檔快速的瞭解每個功能的業務邏輯,便於往後在對系統進行修改時確認修改內容是否正確。
同時本文檔也是與終端用戶(在本項目中大多數狀況是技術支持人員)進行系統功能確認,業務流程肯定的惟一文檔。
因爲公司多個系統都用到了支付模塊,並且功能等方面都一致。
把支付模塊單獨整理出來,然而實現統一管理、維護方便、而且方便之後新系統的開發。
保證支付的安全性,一致性,不影響原系統的支付,在原有系統上以最小的改動方面來實現這個支付的分離。
Ø 原各系統的支付
Ø 問題分析
從上圖能夠看出咱們這個養車修車網有好修養、好淘氣、等多個項目。然而他們都須要用到支付寶、微信、銀聯這三個第三方支付。那麼既然都是同一個平臺的系統,每一個系統支付都從新寫,或者之後又有新項目支付又要寫支付。
得出如下結論:
1. 代碼重用性不高
2. 維護不方便
Ø 解決問題
爲了解決上面存在的問題,將原來各系統的支付獨立分離出來整合成一個支付系統。如今就是由各個系統去和這個獨立出來的支付系統交互,而後在由支付系統再去調用第三方支付(微信、銀聯、支付寶)進行交互。這樣即便有新的系統須要用到支付也不要從新寫支付的功能,而後也也方便之後的管理維護。
各個系統調用支付系統,而後咱們在根據出傳入的支付途徑的調用對應的第三方支付進行支付(WEB)或者返回相應的屬性(APP),而且返回成功或失敗。
各個系統調用支付系統,而後咱們在根據出傳入的支付途徑的調用對應的第三方支付進行退款,而且返回成功或失敗。
第三方通知咱們的支付系統的回調地址,而後咱們驗證簽名和參數解析,若是支付成功就修改付款單支付狀態爲已支付,而後根據在通知付款單的系統ID將結果通知對應的系統,若是通知失敗就隔1秒在失敗就隔2秒依次加時間請求,超過20次就添加到系統日誌裏面。
第三方通知咱們的支付系統的回調地址,而後咱們驗證簽名和參數解析,若是支付成功就修改付款單支付狀態爲已支付,而後根據在通知付款單的系統ID將結果通知對應的系統,若是通知失敗就隔1秒在失敗就隔2秒依次加時間請求,超過20次就添加到系統日誌裏面。
[這裏描述系統的性能需求。]
[這裏描述系統的安全方面的需求。]
[這裏描述和系統相關的用戶,包括客戶,最終用戶細分,他們在系統中的職責,以及他們如何使用系統。簡單的說,就是本系統的全部干係人及職責描述,至關於用例分析中的角色。]
[這裏描述系統的全部功能需求,能夠使用用例圖,若是功能需求比較多,能夠採用用例包。最好在開始時,給出系統用例圖。]
[這裏描述對架構設計有指導性的關鍵需求,會影響到後面的架構設計。]
[這裏描述系統的整體設計目標。]
[這裏描述系統的整體設計原則。]
[這裏以邏輯結構圖(通常分層組織)的方式,描述咱們提供的整個軟件生態系統,通常不涉及具體的技術。]
[這裏用網絡拓撲圖的形式描述網絡方面的設計。]
[這裏描述硬件方面的設計,通常包括:數據庫服務器、備份服務器、Web服務器、應用服務器、存儲設備、防火牆等。]
[這裏描述硬件服務器的選型,依據內容多少,目錄可自行添加。]
[這裏描述網絡設備的選型,依據內容多少,目錄可自行添加。]
[這裏描述存儲設備的選型,依據內容多少,目錄可自行添加。]
[這裏列出全部數據庫,應用服務器,web服務器,操做系統等軟件平臺的選型,能夠包含介紹和選擇理由。]
[在有些大型系統中,須要作開創性的規範方面的設計,用來指導後面系統的開發。通常就是數據方面的規範。這裏能夠分兩個方面進行描述,一個是規範採用的技術,通常是xml;另外一個就是規範初步設計。]
[描述整個技術架構的設計思路,通常是介紹架構設計的歷史,引導出本系統實際的符合先進行的架構思路。]
[簡要描述設計原則,通常都是都是固定的,可參考指南。]
[列出全部架構決策的要點,並逐點解釋其與架構需求的對應。]
[給出方案所選平臺的技術架構,通常是採用廠商平臺的技術架構,能夠從廠商網站或ppt中拷貝。]
[在平臺架構的基礎上,給出具體針對本項目的技術架構。 ]
[對上面的技術架構進行說明]
[按子系統或模塊進行組織,能夠使用樹形圖表示。]
[視客戶具體要求,可獨立章節,寫方案時應考慮招標方的具體安全需求,並給出具體的建議措施。]