升訊威微信營銷系統開發實踐：（1）功能概要與架構設計（ 完整開源於 Github）

GitHub：https://github.com/iccb1013/Sheng.WeixinConstruction
由於我的精力時間有限，不會再對現有代碼進行更新維護，不過微信接口比較穩定，經測試至今沒有變化，功能依然所有可用，你能夠在此基礎上，二次開發，完成你的業務功能，也能夠抽取本平臺中的代碼複用在你的項目中，請遵循 MIT 開源協議保留個人版權聲明和網站連接便可。

GitHub：https://github.com/iccb1013/Sheng.WeixinConstruction.WeixinContract
微信協議包裝的項目還有一個單獨的工程，這個工程的版本稍新，我會進行必定的更新維護，如最近增長了幾個小程序開發須要使用到的接口。可是注意由於代碼結構通過優化調整，直接引用到升訊威微信平臺中，須要修改一些類的引用和名稱。

升訊威微信營銷系統開發實踐系列
升訊威微信營銷系統開發實踐：（1）功能概要與架構設計
升訊威微信營銷系統開發實踐：（2）中控服務器的詳細設計
升訊威微信營銷系統開發實踐：（3）功能介紹與此項目推廣過程的一些體會
升訊威微信營銷系統開發實踐：（4）源代碼結構說明 與 安裝部署說明

 

---

 

微信開發系列教程，將以一個實際的微信平臺項目爲案例，深刻淺出的講解微信開發、應用各環節的實現方案和技術細節。

本系列教程的最終目標是完成一個功能完善並達到高可用性能指標的微信管理軟件，因此除了與微信自己緊密相關的對接和應用技術，還會講到其它相關的全部知識點，從技術選型，架構設計，數據層的設計，API的設計，數據傳輸協議的設計，再到細節的前端的設計及技術應用，後臺開發中的各方面技術，都會涉及。同時，在架構設計中，會考慮到運維領域的諸多問題，會涉及到部署環節中負載均衡及CDN分發，服務器流量及帶寬控制等因素。有許多開發人員對運維領域的工做不熟悉形成項目運維階段成本高，難度大，但願本文可以幫助到你。

 

在上一篇中，咱們詳細分析了微信訂閱號和服務號的區別，在本篇中，將進入正題：升訊威微信營銷系統的功能設計及架構設計。

 

1、功能設計

1）設計目標

◇ 爲微信服務號提供運營及管理所需的各類功能，包括微官網、微會員、活動中心、營銷輔助、微信支付。

◇ 提供簡潔友好的功能畫面，使非專業技術人員也可以輕易的使用。

◇ 提供可獨立於系統以外的插件功能或接口，可輕易對接其它系統或功能模塊。

 

2）詳細設計

如圖，功能的設計從業務上劃分，分爲五大塊：

◇  微官網

         微主頁提供若干預置的模版，能夠經過上傳自定義的主題圖片造成本身的微主頁，對於有必定開發能力的使用者，提供模版引擎功能，使用一個相似於輕量級CMS的功能，定製本身的微主頁。

         電影排片須要寫一個蜘蛛程序進行抓取。

◇  微會員

         須要實現一套積分系統，包括在後臺對積分規則的設定。積分商城與大多數商城系統相似。

         卡券功能須要支持後臺派發和前端在線下經過二維碼覈銷，這一塊與微信原生卡券有一個重要區別，在於領取的方式，微信原生卡券主要是自主領取，好比掃碼、分享等，可是對於部分線下商戶，卡券的派發是要嚴格管控的，好比電影院的兌換券、景點的門票等，這種場景目前微信自帶卡券不能實現。

◇  活動中心

         必須將全部的活動所有模版化，使用戶可以簡單配置就發起活動，並在活動進行的過程當中提供運營數據報表。

◇  微信支付

         除了打通微信支付之外，須要提供線下的充值和消費能力，好比會員直接在線下向服務人員現金充值，或線下購物時刷二維碼消費本身預存的現金，這裏實際上意味着須要實現一套比較完整的消費系統。

◇  營銷輔助

         可以提供各類運營數據，並提供郵件通知、短信通知的能力。

 

2、架構設計

1）設計目標

◇  穩定可靠，低耦合高內聚，可維護性強。

         穩定可靠主要取決於設計及編碼水平，這個無需多解釋。低耦合高內聚應該也是你們都瞭解的原則，爲了實現這個目標，項目會按功能模塊進行拆分和抽象，具體拆分方式請見下文的詳細設計。

◇  易水平擴展，易運維。

         將高頻請求的部分和低頻請求的部分分解，將內網請求與外網請求分解，可分佈式部署，將內網請求部分徹底隔離在防火牆以後或內網環境中，並使對外的高頻請求的部分可經過增長服務器來增長承載能力。在設計之初就須要考慮負載均衡及CDN分發所帶來的問題，在負載均衡方面，咱們以負載均衡不開啓會話保持爲設計指標，此外，咱們須要將全部用戶上傳的文件，或發送的文件，在獨立的文件服務器存儲，以便於CDN分發和控制流量及帶寬，要知道服務器的流量及帶寬費用是至關可觀的，同時也避免文件傳輸對服務器帶寬的佔用而影響業務數據的處理能力。

◇  所選技術應用成熟，生產性（開發維護的效率）高，編碼實施難度較低，後續開發容易。

         在具體的技術選型上，選擇成熟穩定的技術方案，而不是「牛」的方案，這一點很是重要，由於咱們不是在作研究，咱們是在作項目。或者從另外一個角度來講，你對技術「牛」和「不牛」是怎樣理解的。在此項目中咱們考量如下幾個因素：

         a.是否成熟穩定，後續支持怎樣。成熟穩定一般表明着問題較少，團隊學習成本低，接納度高，後續支持指的是是否有商業公司或開源社區積極的維護更新。

         b.生產性怎樣，是否能夠提供足夠高的生產性。生產性指的是開發維護的效率，軟件開發過程當中最大的成本是人力成本，如何用更少的人作到更多的事，甚至說在市場競爭中你的速度快不快，都至關重要，對於商業項目，我不須要你知道回香豆的「回」有幾種寫法，我只要你又快又好的給我寫一百遍「回」字便可。

         能解決個人問題，成熟穩定，生產性高，能夠稱之爲「牛」的技術。

◇  數據庫必須支持分庫存儲

         基於承載能力擴展性和業務方面的考量，必需要可以將不一樣的公衆號數據存儲到不一樣的數據庫服務器上。

 

2）詳細設計

         架構設計我想分爲兩個部分說明，一是開發架構，二是部署架構。這兩個不一樣角度的設計互相影響或者互相制約，必須在設計期間就把握好大方向，作好這件事情須要設計者除了懂開發，還要懂運維，不然很容易形成前人挖坑後人填坑。

 

         1.開發架構

         注意圖上的一個矩形模塊並不必定就表明着一個程序集，一個邏輯上的「模塊」可能由多個程序集共同構成。

         從上向下簡單分析，首先是管理端的UI層和手機端的UI層，我習慣將之稱爲Shell。從圖上能夠看到管理端Shell和手機端Shell是分開的兩個模塊，在咱們的解決方案中它們是兩個不一樣的工程，我也看到過一些微信項目將管理端和手機端放在一個工程中，不管是從安全性、可維護性上說我都強烈不建議你這麼作。徹底分開的好處有不少，首先是部署成本，管理端通常狀況下是不須要應對大量請求的，而手機端有這個需求，在部署時管理端甚至只需一臺服務器便可，而手機端則須要更多的服務器和帶寬支撐，另外在工程的前期運維階段，管理端的版本發佈頻率可能高於手機端，徹底隔離的開發和部署能夠避免在發佈管理端時影響到手機端的業務，第二是安全性的問題，手機端從工程上就是徹底不包含任何管理功能的，能夠在必定程序上提升安全性。

         接下來是若干輔助服務，報表服務、文件服務，這兩個服務是獨立的Web工程。和管理端或手機端並非一一對應的關係，一個報表服務器或文件服務器能夠爲多臺管理端或手機端Shell提供服務。

         報表服務器直接提供報表查詢和顯示的畫面，嵌入在管理端中。

         文件服務器提供文件上傳下載功能，這個服務有幾個技術細節須要注意，聰明的你或許已經想到第一個問題：跨域上傳的問題。管理端和手機端都是獨立部署的，所使用的域名天然是不一樣的，那麼在瀏覽器中上傳就存在跨域的問題，不過這個問題並不難解決，我將的後續篇章中介紹，另外一個就是對於（嵌入在微信中的）手機端來講，是不能直接上傳文件的，必須先把文件發送到微信後臺，獲取媒體ID，再下載下來，這個過程須要文件服務器完成，最後是關注服務號的會員，發文件到服務號上，實際是發到了微信服務器，咱們的文件服務器要能異步的把這些文件從微信後臺下載下來。

         定時任務是一個或若干個Windows服務，用於定時執行一些業務。

         業務核心模塊這裏的介紹比較籠統，在項目中實際對應着實現不一樣功能的諸多程序集，限於篇幅和本章節的主旨，仍是留到後文中詳細說明業務核心的設計和實現。

         中控服務器主要的功能是維護調用微信API所需的AccessToken，與微信對接時，根據公衆號的AppId和AppSecert，你能夠獲取到一個有效期爲2個小時的AccessToken，調用幾乎全部的微信接口都須要這個         AccessToken，固然你不能在每次請求API時都獲取一個新的AccessToken，這是徹底沒有必要的，因此須要一個獨立的服務來處理這件事，其它模塊須要使用AccessToken時，從中控服務器獲取。

         微信SDK並非微信官方提供的，是項目裏須要本身實現的部分，微信官方並無提供完善的開發包，只有若干示例。網上有一些開源的微信SDK，可是或多或少存在一些問題，此處使用的是咱們本身實現的SDK包。

         基礎架構部分涉及到數據實體的定義、數據協議的定義等等，數據協議指的是各Web工程之間之前單個Web工程中先後端通訊所使用的協議。此外還包括許多共通的功能實現也在這裏。

         服務模塊封裝了項目中所需的許多服務，如：日誌、緩存、統一異常處理等等。

         最後是數據層，數據層沒有使用Entity Framework，使用的是個人另外一個開源項目S-ORM，下文的技術選型部分有簡略的說明和介紹。

 

         2. 部署架構

 

        如圖所示，咱們的部署目標是須要支持易於水平擴展的分佈式部署。管理端Shell、手機端Shell、報表服務器、文件服務器都必須可以經過增長服務器快速擴充承載能力。

        在上文中提到，咱們在開發環節必須以負載均衡不開啓會話保持爲一項技術指標，這意味着從瀏覽器中發起的請求每次均可能落在不一樣的服務器上，咱們就不能使用服務器Session存儲會話數據，須要在開發階段就實現一套基於獨立緩存的Session機制。

        數據庫服務器、緩存集羣、中控服務器、定時任務服務器都部署在內網中，其它項目經過內網IP與它們進行通訊，對於中控服務器和定時任務服務器，存在須要外網交互的部分，咱們經過一個代理服務器來實現。