TYPESDK 服務(wù)端設(shè)計思路與架構(gòu)之六：性能及調(diào)優(yōu)初步

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

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

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

了解更多：www.typesdk.com

問題解答：1771930259

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

項目地址：https://github.com/typesdk