GitHub：https://github.com/iccb1013/Sheng.WeixinConstruction
因為個人精力時間有限，不會再對現有代碼進行更新維護，不過微信接口比較穩定，經測試至今沒有變化，功能依然全部可用，你可以在此基礎上，二次開發，完成你的業務功能，也可以抽取本平台中的代碼復用在你的項目中，請遵循 MIT 開源協議保留我的版權聲明和網站鏈接即可。
GitHub：https://github.com/iccb1013/Sheng.WeixinConstruction.WeixinContract
微信協議包裝的項目還有一個單獨的工程，這個工程的版本稍新，我會進行一定的更新維護，如最近增加了幾個小程序開發需要使用到的接口。但是注意因為代碼結構經過優化調整，直接引用到升訊威微信平台中，需要修改一些類的引用和名稱。
升訊威微信營銷系統開發實踐系列
升訊威微信營銷系統開發實踐：（1）功能概要與架構設計
升訊威微信營銷系統開發實踐：（2）中控服務器的詳細設計
升訊威微信營銷系統開發實踐：（3）功能介紹與此項目推廣過程的一些體會
升訊威微信營銷系統開發實踐：（4）源代碼結構說明 與 安裝部署說明
微信開發系列教程，將以一個實際的微信平台項目為案例，深入淺出的講解微信開發、應用各環節的實現方案和技術細節。
本系列教程的最終目標是完成一個功能完善並達到高可用性能指標的微信管理軟件，所以除了與微信本身緊密相關的對接和應用技術，還會講到其它相關的所有知識點，從技術選型，架構設計，數據層的設計，API的設計，數據傳輸協議的設計，再到細節的前端的設計及技術應用，后台開發中的各方面技術，都會涉及。同時，在架構設計中，會考慮到運維領域的諸多問題，會涉及到部署環節中負載均衡及CDN分發，服務器流量及帶寬控制等因素。有許多開發人員對運維領域的工作不熟悉造成項目運維階段成本高，難度大，希望本文能夠幫助到你。
在上一篇中，我們詳細分析了微信訂閱號和服務號的區別，在本篇中，將進入正題：升訊威微信營銷系統的功能設計及架構設計。
一、功能設計
1）設計目標
◇ 為微信服務號提供運營及管理所需的各種功能，包括微官網、微會員、活動中心、營銷輔助、微信支付。
◇ 提供簡潔友好的功能畫面，使非專業技術人員也能夠輕易的使用。
◇ 提供可獨立於系統之外的插件功能或接口，可輕易對接其它系統或功能模塊。
2）詳細設計
如圖，功能的設計從業務上划分，分為五大塊：
◇ 微官網
微主頁提供若干預置的模版，可以通過上傳自定義的主題圖片形成自己的微主頁，對於有一定開發能力的使用者，提供模版引擎功能，使用一個類似於輕量級CMS的功能，定制自己的微主頁。
電影排片需要寫一個蜘蛛程序進行抓取。
◇ 微會員
需要實現一套積分系統，包括在后台對積分規則的設定。積分商城與大多數商城系統類似。
卡券功能需要支持后台派發和前端在線下通過二維碼核銷，這一塊與微信原生卡券有一個重要區別，在於領取的方式，微信原生卡券主要是自主領取，比如掃碼、分享等，但是對於部分線下商戶，卡券的派發是要嚴格管控的，比如電影院的兌換券、景點的門票等，這種場景目前微信自帶卡券不能實現。
◇ 活動中心
必須將所有的活動全部模版化，使用戶能夠簡單配置就發起活動，並在活動進行的過程中提供運營數據報表。
◇ 微信支付
除了打通微信支付以外，需要提供線下的充值和消費能力，比如會員直接在線下向服務人員現金充值，或線下購物時刷二維碼消費自己預存的現金，這里實際上意味着需要實現一套比較完整的消費系統。
◇ 營銷輔助
能夠提供各種運營數據，並提供郵件通知、短信通知的能力。
二、架構設計
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與它們進行通信，對於中控服務器和定時任務服務器，存在需要外網交互的部分，我們通過一個代理服務器來實現。