經(jīng)過本系列前幾篇文字的分析和設(shè)計(jì)，我們成功地開發(fā)出了自己的SDK服務(wù)端。在我們自己的調(diào)試環(huán)境下運(yùn)行一切正常，但是當(dāng)然我們不能就這樣把這套SDK服務(wù)端部署上線到正式生產(chǎn)環(huán)境，稍有正式大型項(xiàng)目經(jīng)驗(yàn)的同學(xué)應(yīng)該都知道性能優(yōu)化以及部署上線相關(guān)設(shè)計(jì)對于服務(wù)端項(xiàng)目的重要性。我們到目前為止的分析設(shè)計(jì)中，并沒有考慮到這些設(shè)計(jì)。那么，針對我們SDK服務(wù)端這樣的應(yīng)用場景，應(yīng)該著重關(guān)注哪些相關(guān)的優(yōu)化和設(shè)計(jì)呢？
數(shù)據(jù)存取優(yōu)化
在我們的應(yīng)用場景中，需要使用到存儲(chǔ)的場景主要在以下幾個(gè)處理中：
l 獲取配置信息
對每個(gè)收到的請求，處理時(shí)都需要根據(jù)其來源游戲渠道等各種信息，獲取到對應(yīng)的配置信息，再作處理。配置信息訪問頻率相當(dāng)頻繁，但基本是只讀的，處理過程中并不會(huì)對其進(jìn)行修改。
l 存取訂單信息
對支付產(chǎn)生的訂單消息，服務(wù)端對其處理包括創(chuàng)建訂單，查詢訂單和修改訂單狀態(tài)等等，對數(shù)據(jù)的處理包括儲(chǔ)存和讀取，兩種操作頻率基本相當(dāng)。
l 保存日志信息
對收到的請求及產(chǎn)生的錯(cuò)誤，服務(wù)端需要作保存日志的動(dòng)作，這一動(dòng)作屬于純寫入操作，操作頻率較高。
針對這幾種數(shù)據(jù)，我們的處理策略也不相同：
對配置信息這樣的頻繁訪問，又變化較小的數(shù)據(jù)，為了盡量加快訪問速度，我們通常會(huì)選擇將其存入內(nèi)存。但是如果將配置信息以配置文件的方式保存，則又無法靈活管理。考慮到更進(jìn)一步的動(dòng)態(tài)加載配置需求，這里我們可以使用內(nèi)存緩存的方式存取。即應(yīng)用程序啟動(dòng)時(shí)從外部存儲(chǔ)（DB）中讀取配置，保存在內(nèi)存中待調(diào)用，定期通過檢查更新標(biāo)志的方式更新配置。
訂單信息屬于重要的結(jié)構(gòu)化信息，無疑應(yīng)該保存在DB中。但是回顧一下前幾篇文字中分析的支付到帳請求流程，可以發(fā)現(xiàn)，該流程對我們的處理效率提出了相當(dāng)高的要求。如果我們不能在盡可能短的時(shí)間內(nèi)，完成整個(gè)查詢對比發(fā)貨流程，就會(huì)導(dǎo)致渠道判定游戲服務(wù)端處理超時(shí)，從而觸發(fā)渠道的訂單重發(fā)機(jī)制。最糟糕的情況下，前一次處理過程還沒有結(jié)束，渠道的后一次重發(fā)請求又到了，就會(huì)導(dǎo)致系統(tǒng)的處理效率急速下降乃至崩潰。因此，我們需要為訂單建立一個(gè)緩存，為DB承擔(dān)查詢壓力。在這方面，市面常見的緩存產(chǎn)品如Redis Memcache等都可以勝任該需求，具體設(shè)計(jì)這里就不再贅述。
日志信息屬于只寫不讀的信息。如果將所有的日志都存入DB，無疑在空間和效率上都會(huì)不必要的消耗DB的性能。我們一般選擇將日志以文件的形式存儲(chǔ)。另外，這一寫入操作必須使用異步形式處理，否則會(huì)大幅降低性能。關(guān)于異步處理，后文會(huì)進(jìn)一步說明。
異步處理
任何可以晚點(diǎn)做的事情都應(yīng)該晚點(diǎn)再做，異步處理正是基于這一原則來實(shí)施的。具體到我們的服務(wù)端設(shè)計(jì)上，我們可以總結(jié)出以下邏輯可以設(shè)計(jì)成為異步操作。
l 所有記錄日志操作
l 大多數(shù)對DB的寫入操作（包括修改訂單狀態(tài)/保存訂單信息等）
讀取操作則通常是一個(gè)同步操作，我們無法要求一個(gè)查詢訂單的請求“先返回一個(gè)已收到查詢請求的信息，隨后再異步提供查詢結(jié)果”。
l 發(fā)貨流程中，與游戲服務(wù)端通信的HTTP請求操作。
這里實(shí)際上異步操作由SDK端或由游戲端來實(shí)現(xiàn)均可達(dá)到我們的目的，但是還是由游戲服務(wù)端來實(shí)現(xiàn)更為合理。
具體的異步實(shí)現(xiàn)方式，由于開發(fā)語言及工具的實(shí)現(xiàn)各有不同，這里也不再詳細(xì)討論。
集群部署
在網(wǎng)站高并發(fā)訪問的場景下，使用負(fù)載均衡技術(shù)為一個(gè)應(yīng)用構(gòu)建一個(gè)由多臺(tái)服務(wù)器組成的服務(wù)器集群，將并發(fā)訪問請求分發(fā)到多臺(tái)服務(wù)器上處理，避免單一服務(wù)器因負(fù)載壓力過大而響應(yīng)緩慢，使用戶請求具有更好的響應(yīng)延遲特性。
使用集群部署和負(fù)載均衡技術(shù)的場合下，要求我們的應(yīng)用在設(shè)計(jì)時(shí)也需要注意并發(fā)處理的技術(shù)細(xì)節(jié)，例如重復(fù)請求過濾，事務(wù)化處理邏輯等設(shè)計(jì)。原則上注意考慮多臺(tái)服務(wù)端同時(shí)處理時(shí)帶來的這些問題即可。
代碼優(yōu)化
之所以把代碼優(yōu)化的部分放在最后，是因?yàn)檫@部分無非是一些老生常談的東西，相信讀者每個(gè)人都處理過類似的優(yōu)化工作。包括連接池資源復(fù)用，數(shù)據(jù)結(jié)構(gòu)優(yōu)化，利用垃圾回收機(jī)制等等。這里就需要讀者自己根據(jù)所使用的開發(fā)工具和語言來實(shí)際操作了。

服務(wù)端設(shè)計(jì)的思路和架構(gòu)系列文字，到本篇為止就告一段落，之后我們會(huì)用幾篇文字和代碼實(shí)際講解如何具體實(shí)現(xiàn)本系列文字設(shè)計(jì)出的服務(wù)端。以及如何解決實(shí)際編碼中遇到的設(shè)計(jì)問題。并在實(shí)際解決問題的過程中再進(jìn)一步討論更加深入的優(yōu)化手段。

如果想了解更多，請聯(lián)系我們或關(guān)注官網(wǎng)

了解更多：www.typesdk.com

問題解答：1771930259

聯(lián)系郵箱：qianyuzhou@typesdk.com

項(xiàng)目地址：https://github.com/typesdk