在上一篇文章中，簡要介紹了升訊威微信營銷系統(tǒng)的功能設(shè)計(jì)和架構(gòu)設(shè)計(jì)，限于篇幅只能拋磚引玉，從本章節(jié)開始將圍繞功能的設(shè)計(jì)和架構(gòu)的設(shè)計(jì)進(jìn)行詳細(xì)的論述。

?

中控服務(wù)器的設(shè)計(jì)

在上文中，我們談到需要一個(gè)中控服務(wù)器，用來維護(hù)公眾號(hào)的AccessToken等。本節(jié)首先圍繞這個(gè)內(nèi)容討論。

?

背景

微信接口調(diào)用需要首先獲取一個(gè)AccessToken進(jìn)行鑒權(quán)，目前每次獲取的AccessToken有效期為2個(gè)小時(shí)，每天獲取次數(shù)限制在2000次以下。當(dāng)然我們不需要如此頻繁的請求新的AccessToken，我們只需要把它存儲(chǔ)起來，在過期前刷新即可。

對于只為單個(gè)公眾號(hào)服務(wù)的系統(tǒng)，中控服務(wù)器的設(shè)計(jì)實(shí)現(xiàn)可以從簡，只需定時(shí)刷新AccessToken，并為應(yīng)用服務(wù)器提供獲取AccessToken的接口即可。

對于直接將AccessToken寫入Redis，在我實(shí)踐過程中發(fā)現(xiàn)不能100%保證寫入成功，存在寫入失敗，數(shù)據(jù)沒有更新的情況，這個(gè)問題是致命的，因?yàn)橐坏┇@取了新的AccessToken，舊的就會(huì)很快失效，如果不能寫入成功，應(yīng)用服務(wù)器繼續(xù)使用舊的AccessToken，將導(dǎo)致微信API調(diào)用全部失敗。

我沒有找到相關(guān)資料說明是否Redis寫入機(jī)制不保證一定成功？如果有熟悉Redis的大神請指教，謝謝。

?

對于需要同時(shí)服務(wù)于多個(gè)公眾號(hào)的系統(tǒng)，中控服務(wù)器的設(shè)計(jì)要稍微復(fù)雜一些。

我們現(xiàn)在將問題放大一些，在升訊威微信營銷系統(tǒng)中，所需要維護(hù)和管理的數(shù)據(jù)很多，其中有一些數(shù)據(jù)，如公眾號(hào)的基本信息數(shù)據(jù)、個(gè)性化設(shè)置數(shù)據(jù)、授權(quán)數(shù)據(jù)、以及各種AccessToken、Ticket等，我將之打包稱之為“公眾號(hào)上下文”。中控服務(wù)器除了維護(hù)AccessToken，更重要的作用是維護(hù)起整個(gè)公眾號(hào)上下文。

?

設(shè)計(jì)目標(biāo)

概括來說中控服務(wù)器有以下幾個(gè)職責(zé)：

1）? 維護(hù)鑒權(quán)所需的各種AccessToken、Ticket。

2）? 維護(hù)基本信息、授權(quán)信息等基礎(chǔ)數(shù)據(jù)。

3）? 提供一套供應(yīng)用服務(wù)器使用的API，用于同步用戶的個(gè)性化設(shè)置及其它需要?jiǎng)討B(tài)更新的數(shù)據(jù)。

4）? 提供基于 TCP/IP 的接口以提高通信能力。

5）? 可通過增加服務(wù)器橫向擴(kuò)展以提高承載能力。

?

架構(gòu)設(shè)計(jì)

這里的架構(gòu)設(shè)計(jì)是針對上一篇《功能設(shè)計(jì)及架構(gòu)設(shè)計(jì)》中“架構(gòu)設(shè)計(jì)”環(huán)節(jié)里中控服務(wù)器部分的展開。

中控服務(wù)器的具體實(shí)現(xiàn)方法我想放到后面的章節(jié)中介紹，本篇專注于架構(gòu)的設(shè)計(jì)。

?

中控服務(wù)器最重要的核心即“域容器”。

?

對于我們的系統(tǒng)來說，要提供承載多個(gè)公眾號(hào)（100000+）的能力，所以需要將不同公眾號(hào)的上下文數(shù)據(jù)組織好之后，放到一個(gè)域容器中進(jìn)行維護(hù)。為什么這里叫做“域容器”而不叫做“公眾號(hào)容器”？這里為了方便論述，我對相關(guān)的設(shè)計(jì)做了簡化，實(shí)際上單個(gè)公眾號(hào)上下文是被包含在一個(gè)“域”中的，“域”除了承載公眾號(hào)上下文數(shù)據(jù)之外，還需要承載并維護(hù)其它一些數(shù)據(jù)。

中控服務(wù)器在維護(hù)公眾號(hào)上下文時(shí)，有多種架構(gòu)設(shè)計(jì)方案，根據(jù)項(xiàng)目的技術(shù)指標(biāo)，由易到難。

?

入門級(jí)

?

入門級(jí)只需要單臺(tái)中控服務(wù)器即可，維護(hù)所有的公眾號(hào)上下文，通過Http Web API 接口向應(yīng)用服務(wù)器提供服務(wù)。

可以適用于一般小規(guī)模服務(wù)，如果中控服務(wù)器Out of Service，需要運(yùn)維團(tuán)隊(duì)及時(shí)響應(yīng)，重啟服務(wù)或服務(wù)器，數(shù)據(jù)可以在啟動(dòng)時(shí)從緩存中恢復(fù)，但是會(huì)造成短時(shí)間的服務(wù)中斷。

?

門廳級(jí)

鑒于中控服務(wù)器的重要性，我們不能接受它出現(xiàn)問題，我們的目標(biāo)是達(dá)到服務(wù)99.999% 以上的可用時(shí)間。

進(jìn)一步的方案是對中控服務(wù)器進(jìn)行冗余，使用多臺(tái)服務(wù)器維護(hù)公眾號(hào)上下文并提供服務(wù)。

在此方案中，每臺(tái)中控服務(wù)器所維護(hù)的數(shù)據(jù)是一致的，都是彼此的副本。

規(guī)模不大時(shí)已經(jīng)適用了，可以將部分接口基于TCP/IP來實(shí)現(xiàn)，主要是為應(yīng)用服務(wù)器提供AccessToken的接口，請求頻率會(huì)非常高。

如果系統(tǒng)所需要服務(wù)的公眾號(hào)數(shù)量非常多，達(dá)到數(shù)萬甚至數(shù)十萬，單臺(tái)中控服務(wù)器的承載能力將受到很大影響，甚至根本不能承受，我們需要對公眾號(hào)上下文數(shù)據(jù)的維護(hù)進(jìn)行拆分。

?

客廳級(jí)

在客廳級(jí)方案中，最重要的目的是拆分中控服務(wù)器對公眾號(hào)上下文的維護(hù)，使系統(tǒng)的整體承載能力得到提高，并使之具有橫向擴(kuò)展的能力。

舉例來說中控服務(wù)器1維護(hù)第1~3000個(gè)公眾號(hào)上下文，中控服務(wù)器2維護(hù)第3001~6000個(gè)公眾號(hào)上下文。具體維護(hù)數(shù)量根據(jù)服務(wù)器配置和網(wǎng)絡(luò)情況，以及你的中控服務(wù)器實(shí)現(xiàn)質(zhì)量決定。

中控服務(wù)器對公眾號(hào)上下文的維護(hù)的拆分，帶來的問題當(dāng)然是應(yīng)用層怎么樣才能找到指定公眾號(hào)所需的上下文數(shù)據(jù)在哪臺(tái)服務(wù)器上呢？偷懶的方案是在公眾號(hào)對接時(shí)直接定死，但是這個(gè)方案很容易造成運(yùn)維階段的成本浪費(fèi)，因?yàn)楣娞?hào)的活躍度是不同的，有很多公眾號(hào)在對接后可能長時(shí)間處于不活動(dòng)狀態(tài)。而且定死的話你雖然能通過橫向擴(kuò)展增加服務(wù)的承載能力，但是沒有辦法通過增加單臺(tái)服務(wù)器的配置提高既有服務(wù)器的承載能力。所以在我們的具體實(shí)現(xiàn)中，中控服務(wù)器對于公眾號(hào)上下文的加載和維護(hù)都是懶加載的，單臺(tái)可加載數(shù)量可以根據(jù)運(yùn)維期的服務(wù)器配置進(jìn)行調(diào)整。

如何使應(yīng)用層的服務(wù)器找到指定公眾號(hào)上下文在哪臺(tái)服務(wù)器上？其實(shí)很簡單，增加一個(gè)中控服務(wù)器路由即可，這個(gè)路由服務(wù)器必須知道公眾號(hào)上下文和中控服務(wù)器的對應(yīng)關(guān)系，知道它在哪里。是不是每次請求中控服務(wù)器都需要經(jīng)過路由服務(wù)器去定位哪？并不需要這樣做，只需要在應(yīng)用層服務(wù)器初次定位時(shí)到路由服務(wù)器上查詢即可，后續(xù)的通信直接與中控服務(wù)器進(jìn)行。

?

臥室級(jí)

?

客廳級(jí)的加強(qiáng)版，對所有中控服務(wù)器進(jìn)行一對一的冗余，以防單臺(tái)故障Out Of Service。

其實(shí)這里有一個(gè)技術(shù)點(diǎn)是要注意的，AccessToken的同步問題，這個(gè)問題在上文的門廳級(jí)方案中也是一樣存在的，冗余的服務(wù)器之間如何確保AccessToken是同步的，當(dāng)然不能各自去調(diào)用微信API刷新，后刷新的就把先刷新的沖掉了，所以需要把刷新AccessToken的工作放到中控服務(wù)器對外代理中，在其中實(shí)現(xiàn)一個(gè)隊(duì)列來處理這件事，并在得到新的AccessToken后，分發(fā)到中控服務(wù)器。

?

陽臺(tái)級(jí)

生活不只是眼前的茍且，還有遠(yuǎn)方的茍且等著你，慢慢來……?

中控服務(wù)器的設(shè)計(jì)實(shí)現(xiàn)可以采取不斷演進(jìn)的方式進(jìn)行，可以隨著運(yùn)維規(guī)模的擴(kuò)大適時(shí)迭代，但是必須在前期規(guī)劃設(shè)計(jì)時(shí)考慮到這些問題，特別是橫向擴(kuò)展的能力。

原文地址：http://www.cnblogs.com/sheng_chao/p/5808643.html

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注

總結(jié)

以上是生活随笔為你收集整理的升讯威微信营销系统开发实践：（3）中控服务器的设计 .Net 还是 Java？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。