升讯威微信营销系统开发实践：（2）功能设计与架构设计
在上一篇中，我們詳細分析了微信訂閱號和服務號的區別，在本篇中，將進入正題：升訊威微信營銷系統的功能設計及架構設計。
?
一、功能設計
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與它們進行通信，對于中控服務器和定時任務服務器，存在需要外網交互的部分，我們通過一個代理服務器來實現。
?
3）技術選型
? ? ? ??對于這樣的項目無論是商業平臺還是開源平臺，都是可以的，都不會有太多障礙。
? ? ? ??本項目基于微軟平臺開發，并使用了一些基于Linux平臺的開源應用作為輔助。
? ? ? ??這里要指出一個關于跨平臺的問題，有些開發人員認為微軟平臺不能夠跨平臺是一個問題，關于這一點我認為“跨平臺”本身是一個偽命題和偽需求，我從沒見過正經項目在運維過程中遷移技術平臺的案例，一定是在設計時就確認了部署平臺。微軟平臺的優點是技術方案成熟，可靠性較高，開發效率高，缺點是運維時的軟硬件成本較高。開源平臺的優點相反，運維期間的軟硬件成本要低幾個數量級，但是前期的綜合開發成本較高，可靠性更多的依賴于人的因素。?
后臺：
1）ASP.NET MVC5 （Razor）
2）Web API
3）S-ORM
4）Microsoft Enterprise Library
5）其它組件，在相關章節介紹
? ? ? ??ASP.NET MVC 沒有懸念，視圖部分使用 Razor，生產性和可維護性都極高。如果發現項目中存在非常高頻請求的頁面，可以對特定頁面實行完全靜態化的HTML代碼和前端異步請求的方案處理。這樣的情況可能出現的場景在手機端，但是沒有必要整個項目都使用這種方式處理。
? ? ? ??此外關于數據訪問層，沒有使用 Entity Framework，有幾個方面的考慮：a.開發運維時更新數據庫表結構等比較麻煩；b.性能問題，關于執行效率我們可以通過許多開發技巧進行提升，但是對于團隊開發來說，這個隱性成本太高了；c.靈活性問題，在許多較復雜的應用場景中，數據庫表結構和實體對象的映射關系不一定是簡單的一對一隱射，可能存在分解、組合、包含等多種情況。所以在ORM層面，使用了我的另外一個開源項目：S-ORM，嚴格來說它不是一個ORM，而是一個輕量級的內存數據映射模塊，詳細的介紹請移步：http://www.cnblogs.com/sheng_chao/p/4553832.html。
? ? ? ??項目的日志處理，統一異常處理使用了微軟企業庫（Microsoft Enterprise Library）。?
前端：
1）jQuery
2）其它組件，在相關章節介紹
? ? ? ??對于前端實現，要盡可能多的兼容更多的瀏覽器，包括現代的古代的，力所能及的都盡可能兼容。此外前端分為兩個部分，PC端和手機端，在具體實現上略有不同。
? ? ? ??在前端技術選型中，考慮過AngularJS、Knockoutjs、Backbone等框架，毫無疑問都是牛的框架，但是在這個項目中我都沒有使用，最主要的原因是出于生產性的考慮，我認為使用這些框架的生產性不夠高，或許在單頁面應用（Single Page Application）場景中它們更能大展身手，但是對于這個項目來說，沒有SPA這樣的需求，相對來說比較傳統，這種場景下網頁前端的每個頁面都是獨立的區域、與其它的頁面完全沒有任何依賴、引用的關系，這一點對于后臺開發或者應用程序開發有很大區別，在（大多數頁面并不那么復雜的）單個頁面中實現MVC是否有必要？能夠得到什么回報？不要把“學技術”放到考量因素中，這不是做項目需要考慮的問題，開發人員也不應該帶著這種目的做項目，這是自私的。
? ? ? ??可能有開發人員認為使用優秀的開發框架可以提高代碼可讀性和代碼品質，關于這一點我認為代碼的品質和可讀性與所使用的框架完完全全沒有任何關系，完全取決于程序員的編碼水平和態度。
? ? ? ??前端技術不是我的強項，關于這一塊內容請前端技術的牛人斧正。?
緩存：
1）? Redis
? ? ? ??在本項目的開發中緩存的應用經歷了從 memcached 到 Redis 的轉變，轉變的具體原因將在后續介紹緩存實現的篇幅中詳細介紹。?
數據庫：
1）? MS SQL Server
? ? ? ??在數據庫層面，大量使用了存儲過程處理業務邏輯，并做到99.9%以上的參數化查詢,一是可大幅提高數據庫請求效率，二是防止注入攻擊。為什么不是100%？在個別場景中，有一些特例，這些特例可以通過統一的函數進行安全方面的過濾，并且這些特例中的輸入參數并不依賴于外部提供，后文將詳細說明。
原文地址：http://www.cnblogs.com/sheng_chao/p/5801401.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的升讯威微信营销系统开发实践：（2）功能设计与架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 升讯威微信营销系统开发实践：（3）中控服
- 下一篇： 升讯威微信营销系统开发教程：（1）订阅号