網(wǎng)易游戲海外AWS實(shí)踐分享

4 月 27 日，網(wǎng)易游戲?qū)W院受邀 AWS，作為主題演講分享的重磅嘉賓，參與了中國(guó)區(qū) AWS Game Tech Day- AWS 游戲開(kāi)發(fā)者大會(huì)深圳站分享，網(wǎng)易游戲資深云解決方案工程師孫國(guó)良代表網(wǎng)易團(tuán)隊(duì)帶來(lái)了《網(wǎng)易游戲海外 AWS 實(shí)踐分享》，技術(shù)內(nèi)容豐富，引起現(xiàn)場(chǎng)熱烈討論，與會(huì)人員收獲滿載。

孫國(guó)良，2013 年加入網(wǎng)易游戲，曾負(fù)責(zé)《天諭》《獵魂覺(jué)醒》《楚留香》等游戲項(xiàng)目運(yùn)維工作，之后負(fù)責(zé)游戲出海對(duì)接公有云的運(yùn)維架構(gòu)以及混合云管理平臺(tái)設(shè)計(jì)，專注于混合云上業(yè)務(wù)解決方案和最佳實(shí)踐的沉淀積累。

孫國(guó)良帶來(lái)的《網(wǎng)易游戲海外 AWS 實(shí)踐分享》，分享了網(wǎng)易游戲在《陰陽(yáng)師》《荒野行動(dòng)》《第五人格》《明日之后》等多款游戲出海運(yùn)營(yíng)過(guò)程中積累的實(shí)踐經(jīng)驗(yàn)，這次分享以全球化的開(kāi)放視野，與廣大游戲熱愛(ài)者共探云技術(shù)的實(shí)踐運(yùn)用。

以下為分享實(shí)錄：

大家好，今天非常高興能夠 分享網(wǎng)易游戲海外在 AWS 云上的實(shí)踐情況，希望我分享的內(nèi)容能給大家提供一些線上最佳實(shí)踐優(yōu)化的思路，當(dāng)然也非常歡迎大家對(duì)我分享的內(nèi)容提出建議幫助我們一起改進(jìn)在云上的業(yè)務(wù)架構(gòu)。簡(jiǎn)單自我介紹一下，我從 2013 年加入網(wǎng)易游戲，早期是做游戲運(yùn)維的工作，是端游《天諭》、手游《楚留香》等游戲的運(yùn)維負(fù)責(zé)人，后來(lái)我主要負(fù)責(zé)了網(wǎng)易游戲出海對(duì)接公有云的運(yùn)維架構(gòu)，以及國(guó)內(nèi)外混合云解決方案方面的工作。

國(guó)內(nèi)發(fā)行 VS 海外發(fā)行

首先簡(jiǎn)單介紹一下網(wǎng)易游戲出海的歷程，這里主要是指手游。 我們差不多是從 14 年底 15 年初開(kāi)始做海外發(fā)行，比較典型的游戲有《陰陽(yáng)師》《荒野行動(dòng)》《終結(jié)者》《第五人格》等等， 今年我們也會(huì)有更多的游戲出海發(fā)行，比如最近發(fā)布的《明日之后》《量子特工》等，后續(xù)還會(huì)有更多的重磅游戲，敬請(qǐng)期待。

根據(jù)第三方統(tǒng)計(jì)，去年中國(guó)的游戲發(fā)行商在海外的收入排行榜中網(wǎng)易取得了第三的成績(jī)，并且中國(guó)出海手游收入榜單前 30 中我們有兩款游戲上榜——《荒野行動(dòng)》和《終結(jié)者》。根據(jù) Sensor Tower 的統(tǒng)計(jì)，《荒野行動(dòng)》2018 年在全球吸金 4.56 億美元，其中日本玩家貢獻(xiàn)了八成。當(dāng)然我們也還有其它很多游戲在全球多個(gè)地區(qū)取得了不錯(cuò)的成績(jī)。

我們回到剛開(kāi)始出海的時(shí)間點(diǎn)，14 年底，從運(yùn)維和基礎(chǔ)架構(gòu)層面出發(fā)，當(dāng)時(shí)我們面臨了國(guó)內(nèi)發(fā)行和海外發(fā)行的一些根本性的差異：

第一點(diǎn)： 網(wǎng)易游戲在國(guó)內(nèi)是有 自建數(shù)據(jù)中心 的，但是游戲出海我們不可能去每一個(gè)發(fā)行的地方自建機(jī)房，所以會(huì)考慮引入 公有云 的基礎(chǔ)設(shè)施；
第二點(diǎn)：因?yàn)橐牍性?，海外使用的資源是 虛擬化的，而我們?cè)瓉?lái)在國(guó)內(nèi)還有比較多的使用 物理資源；
第三點(diǎn)： 云上的資源是 彈性 的，而物理資源是 固定 的；
第四點(diǎn)： 國(guó)內(nèi)發(fā)行的游戲 只要覆蓋國(guó)內(nèi)網(wǎng)絡(luò)，但是發(fā)行到海外的話我們面臨的是 全球范圍的網(wǎng)絡(luò) 情況。

這些差異化給我們帶來(lái)了新的挑戰(zhàn)，總的來(lái)說(shuō)就分為這幾點(diǎn)：

第一：性能。 國(guó)內(nèi)可以直接用物理網(wǎng)絡(luò)設(shè)備和服務(wù)器承載高性能的業(yè)務(wù)，如果在海外用公有云的虛擬網(wǎng)絡(luò)和服務(wù)器，這些虛擬化的資源能否滿足游戲業(yè)務(wù)需求，這對(duì)我們來(lái)說(shuō)其實(shí)是一個(gè)未知數(shù)。

第二，動(dòng)態(tài)彈性。 因?yàn)樵瀑Y源大都是按時(shí)收費(fèi)的，所以從成本考慮會(huì)引入動(dòng)態(tài)伸縮的方案，而動(dòng)態(tài)伸縮對(duì)于游戲業(yè)務(wù)和基礎(chǔ)架構(gòu)來(lái)說(shuō)也是一個(gè)全新的內(nèi)容。

第三，安全性。 國(guó)內(nèi)我們有自建的數(shù)據(jù)中心，安全性比較容易掌控。在公有云上我們就需要考慮很多安全方面的因素，除了網(wǎng)絡(luò)安全，還有數(shù)據(jù)安全等。

第四，全球通服。 游戲海外發(fā)行給我們帶來(lái)一個(gè)全新的需求就是全球通服，后面也會(huì)介紹我們?cè)谌蛲ǚ矫娴囊恍?shí)踐。

基于這些海外發(fā)行和國(guó)內(nèi)發(fā)行的差異和挑戰(zhàn)，從基礎(chǔ)架構(gòu)層面出發(fā)，我們一直在做的一件事情就是建立起一套標(biāo)準(zhǔn)化的云評(píng)測(cè)體系，來(lái)評(píng)估一個(gè)游戲是否能發(fā)行到公有云，以及哪個(gè)云能夠滿足需求標(biāo)準(zhǔn)，并且在實(shí)踐過(guò)程當(dāng)中根據(jù)我們遇到的問(wèn)題不斷迭代這套體系。

云測(cè)評(píng)標(biāo)準(zhǔn)

我們的評(píng)測(cè)大概分為這幾個(gè)方面，第一是基礎(chǔ)設(shè)施層面，例如對(duì)于計(jì)算、存儲(chǔ)的性能 / 可靠性 / 可用性方面的考量，還有對(duì)于網(wǎng)絡(luò)質(zhì)量的評(píng)估，會(huì)分為數(shù)據(jù)中心網(wǎng)絡(luò)以及玩家網(wǎng)絡(luò)兩方面。第二個(gè)就是安全性，剛才也已經(jīng)有提過(guò)。另外也會(huì)有技術(shù)支持，成本等多方位的評(píng)估，這次分享會(huì)集中講我們?cè)谟?jì)算性能以及網(wǎng)絡(luò)延遲方面是怎么做的。

性能測(cè)評(píng)

首先是計(jì)算性能的評(píng)測(cè)，對(duì)于 CPU 可能很多同學(xué)都已經(jīng)比較熟悉了，常規(guī)評(píng)估會(huì)從硬件架構(gòu) / 型號(hào) / 核數(shù) / 主頻等指標(biāo)出發(fā)，然后做一些 Benchmark 性能測(cè)試，但我今天要講的重點(diǎn)不是在這些方面。

我想先講一個(gè)案例，在 16 年底當(dāng)時(shí)《陰陽(yáng)師》有在海外部署兩個(gè)服，一個(gè)是日服，第二個(gè)是北美的全球華人服，兩個(gè)服都跑在 AWS，用了相同的機(jī)型，運(yùn)行相同的操作系統(tǒng)和游戲程序代碼，但是很奇怪的一個(gè)現(xiàn)象是日服的性能只有美服的十分之一，日服在一開(kāi)始完全無(wú)法支撐當(dāng)時(shí)的發(fā)行需求。

從運(yùn)維的角度，硬件 / 系統(tǒng) / 軟件代碼層面都沒(méi)有什么差異，就先從業(yè)務(wù)進(jìn)程這邊先入手排查一下。這是當(dāng)時(shí)陰陽(yáng)師代碼壓測(cè)的情況，上面是日服，可以看到在空跑的狀態(tài)下 CPU 總體使用率就超過(guò) 60%，下面是美服，在空跑狀態(tài)下它 CPU 總體使用率不到 5%。

通過(guò) Perf top 或者是 strace 之類的工具去分析進(jìn)程到底消耗在哪些系統(tǒng)調(diào)用，我們發(fā)現(xiàn)大部分的調(diào)用在 hrtimer，這是獲取時(shí)鐘源的指令，其實(shí)對(duì)很多游戲引擎來(lái)說(shuō)可能都會(huì)依賴這個(gè)調(diào)用，因?yàn)樾枰映绦虿鍢队糜谛阅?profile，所以當(dāng)時(shí)我們就懷疑到可能是時(shí)鐘源設(shè)置上的差異，一看果然是。

上面是性能有問(wèn)題的時(shí)鐘源，設(shè)置成了 hpet，下面是正常服的時(shí)鐘源，它設(shè)置的是 xen，但是 Hpet 是讀主板的時(shí)鐘的，而 Tsc 這些是直接讀 CPU 寄存器的，兩者性能相差懸殊，而兩個(gè)服支持的時(shí)鐘源完全一樣。

這里其實(shí)引伸出另一個(gè)問(wèn)題，網(wǎng)易游戲是有一套服務(wù)器初始化的自動(dòng)化標(biāo)準(zhǔn)流程的，當(dāng)時(shí)我們的流程沒(méi)有把 AWS 時(shí)鐘源統(tǒng)一設(shè)置為高性能 tsc 的原因是 AWS 的機(jī)型少支持某一個(gè) cpu 指令，我們會(huì)根據(jù)有沒(méi)有這些指令 flag 去設(shè)置時(shí)鐘源，初始化流程沒(méi)有去設(shè)置就導(dǎo)致它用了 AWS 自動(dòng)設(shè)置的時(shí)鐘源，而 AWS 會(huì)自動(dòng)隨機(jī)設(shè)置成 hpet/xen/tsc 的任意一種；

解決方案是很簡(jiǎn)單的，我們?cè)诔跏蓟鞒汤锶ザㄖ?AWS 的機(jī)器要把它設(shè)置成我們想要的時(shí)鐘源。 在經(jīng)過(guò)這個(gè)問(wèn)題之后我們就把 CPU 所支持的指令集以及時(shí)鐘源作為一個(gè)關(guān)鍵的評(píng)測(cè)指標(biāo)，如果說(shuō)新的平臺(tái)需要改用新的時(shí)鐘源，比如 5 系實(shí)例是一個(gè)新的 nitro 平臺(tái)，它引入了全新的時(shí)鐘源叫做 kvm-clock。那么針對(duì)這個(gè)時(shí)鐘源我們就需要做游戲引擎的壓測(cè)，確認(rèn)這個(gè)時(shí)鐘源的性能能夠滿足業(yè)務(wù)的需求。

接下來(lái)再看另外一個(gè)案例，在 2018 年初 Intel 的兩個(gè)漏洞 Spectre&Meltdown 全面爆發(fā)，所有云商都跟進(jìn)修復(fù)這個(gè)漏洞，當(dāng)然 AWS 也很快修復(fù)了這個(gè)漏洞，修復(fù)這個(gè)漏洞需要底層打上幾個(gè)補(bǔ)丁，當(dāng)時(shí)我們發(fā)現(xiàn)漏洞修復(fù)后 3 系，4 系的實(shí)例都出現(xiàn)不同程度的 CPU 性能損失，尤其是對(duì)于網(wǎng)絡(luò)密集型的業(yè)務(wù)，最多會(huì)出現(xiàn) 50% 的下降。

而《荒野行動(dòng)》的游戲服恰好是網(wǎng)絡(luò)密集型的業(yè)務(wù)，并且 18 年初正好是《荒野行動(dòng)》在春節(jié)期間人數(shù)一直上升的階段，所以這個(gè)性能下降導(dǎo)致了當(dāng)時(shí)玩家承載量上不去，需要排隊(duì)。

這里截取了游戲壓測(cè)的 CPU 負(fù)載情況，最下面的那條線就是某一個(gè) CPU 的 SI 的軟中段已經(jīng)到達(dá)瓶頸，pps 已經(jīng)撐不住了會(huì)開(kāi)始丟包，玩家的體驗(yàn)沒(méi)辦法保證，但整體的 CPU 性能并沒(méi)有達(dá)到瓶頸，大概是百分之四、五十還沒(méi)有被充分利用，但就是因?yàn)槟骋粋€(gè) CPU 的 si 吃滿導(dǎo)致了網(wǎng)絡(luò)軟中段的性能瓶頸。

這里第一個(gè)想到的方案可能就是堆機(jī)器，是不是增加機(jī)器就可以提升承載量？這個(gè)方案不是很可行，或者是它的效果不佳。因?yàn)槲乙坏┰黾訖C(jī)器的話整個(gè)集群內(nèi)部的通信反而會(huì)增加，而且瓶頸仍然會(huì)在那個(gè) CPU 核上。增加機(jī)器是一種提升效率不佳，而且成本又很高的方式。

接著我們就嘗試從系統(tǒng)層面去優(yōu)化，當(dāng)時(shí)我們專門(mén)跟 AWS 的架構(gòu)師進(jìn)行探討，4 系的實(shí)例是支持多少個(gè)網(wǎng)卡隊(duì)列？結(jié)論是應(yīng)該有兩個(gè)隊(duì)列，然而我們?cè)谙到y(tǒng)里面看到只有一個(gè)隊(duì)列，我們懷疑可能是因?yàn)橛玫木W(wǎng)卡的驅(qū)動(dòng)版本太老了，然后就把它做了升級(jí)，確實(shí)就有兩個(gè)隊(duì)列，并且開(kāi)啟了 Irq，Irq 是從 linux 2.6.22 內(nèi)核開(kāi)始引入的一個(gè)新特型，它可以把硬件多個(gè)網(wǎng)卡隊(duì)列的數(shù)據(jù)包處理分散到多個(gè) CPU 核上去，這樣一來(lái)兩個(gè)隊(duì)列可以分散到兩個(gè) CPU 核上，這個(gè)優(yōu)化可以提升約 50% PPS 承載量。

但是光靠這個(gè)還不夠，還沒(méi)有達(dá)到漏洞修復(fù)前的性能，我們繼續(xù)尋找其它的優(yōu)化方式，考慮引入 RPS 跟 RFS， 它是從 linux 2.6.35 開(kāi)始進(jìn)入 linux 內(nèi)核的，通過(guò)軟件模擬的方式實(shí)現(xiàn)更多多隊(duì)列的功能，把軟中斷負(fù)載分散到多個(gè) CPU 核上去。但是默認(rèn)情況下我們不會(huì)去開(kāi) RPS，因?yàn)樗鼤?huì)造成額外 CPU 的開(kāi)銷(xiāo)，這個(gè)分散本身就會(huì)消耗一定的 CPU?；趦蓚€(gè)隊(duì)列確實(shí)已經(jīng)不夠，那我們就選擇開(kāi)啟，開(kāi)了之后大概能提升 40% 左右的 PP。

這里也再提一下 RFS，雖然說(shuō)我們把網(wǎng)卡分散到了多個(gè) CPU，但是有可能出現(xiàn)這樣的情況，即給該數(shù)據(jù)流分發(fā)的 CPU 核和執(zhí)行處理該數(shù)據(jù)流的應(yīng)用程序的 CPU 核不是同一個(gè)，這樣對(duì)于 CPU CACHE 的性能影響較大，RFS 就是保證應(yīng)用程序處理的 cpu 跟軟中斷處理的 cpu 是同一個(gè)，從而保證 CPU CACHE，當(dāng)然這兩個(gè)特性一般來(lái)說(shuō)都是結(jié)合一起開(kāi)的。

做了這兩個(gè)提升之后系統(tǒng)的網(wǎng)絡(luò)包處理性能差不多已經(jīng)達(dá)到了之前說(shuō)的因漏洞修復(fù)以前的狀態(tài)，但是這個(gè)狀態(tài)仍然沒(méi)辦法滿足需求，因?yàn)楫?dāng)時(shí)《荒野行動(dòng)》在日本的人數(shù)一直新高，數(shù)據(jù)流的量級(jí)其實(shí)已經(jīng)超出了我們所用的 4 系實(shí)例的極限，我們開(kāi)始思考當(dāng)前的 4 系列虛擬化體系的性能可能已經(jīng)無(wú)法滿足現(xiàn)在的業(yè)務(wù)需求。

這時(shí)候剛好離 AWS 推出 5 系 Nitro 新平臺(tái)不久，這個(gè)平臺(tái)本身它有很多重大升級(jí)，包括硬件底層，hypervisor 層等都是全新的，尤其需要注意的一個(gè)是網(wǎng)絡(luò)性能優(yōu)化從 SRIOV 改成了 ENA，第二個(gè)是磁盤(pán)驅(qū)動(dòng)改成了 NVMe。這兩個(gè)改變理論上來(lái)說(shuō)是能夠本質(zhì)的提升網(wǎng)絡(luò)處理性能，所以我們開(kāi)展了測(cè)試：

可以看到上面是 4 系，下面是 5 系。5 系最多有 8 個(gè)網(wǎng)卡隊(duì)列，它的網(wǎng)卡軟中斷負(fù)載可以更均衡的分散到多個(gè)核上去，所以能更加均衡的承載業(yè)務(wù)網(wǎng)絡(luò)數(shù)據(jù)，整體的實(shí)例性能也是可以繼續(xù)往下壓榨的，可以去到 70-80% 的總利用率。

我們還對(duì)比了他們的成本，4 系到 5 系實(shí)例的替換比例接近 2：1，可以節(jié)省不少成本。于是我們就進(jìn)行了升級(jí)操作，包括操作系統(tǒng)、驅(qū)動(dòng)、軟件依賴包等都做了升級(jí)，然而升級(jí)并沒(méi)有那么的順利，我們?cè)?1 個(gè)月內(nèi)就遭遇了 8 次各種類的故障，其中有硬件底層的，有 hypervisor 層的，也有上層應(yīng)用兼容性的問(wèn)題。

所以這里也想提一點(diǎn)，對(duì)于一個(gè)新技術(shù)或者新平臺(tái)，我們還是需要用敬畏的心態(tài)面對(duì)它，而不是說(shuō)好像覺(jué)得很厲害很牛，就去用它。其中有一個(gè)疑難問(wèn)題我們也通過(guò) AWS 的 enterprise support 跟 EC2 產(chǎn)品團(tuán)隊(duì)直接進(jìn)行了溝通。

我們定制了一個(gè)調(diào)試用的 linux 內(nèi)核，并且 EC2 團(tuán)隊(duì)為我們定制了一個(gè)調(diào)試用的 hypervisor，加了很多的 debug 設(shè)置，然后在 dedicated host 上綁定這個(gè) hypervisor 去跑應(yīng)用來(lái)定位到底這個(gè)問(wèn)題是什么，雖然最后還是沒(méi)有能定位到精確的問(wèn)題，不過(guò)好在我們找到了一個(gè) workaround，線上暫時(shí)來(lái)說(shuō)可以有解決辦法，當(dāng)然我們也仍然在尋找更優(yōu)雅的解決方案。

經(jīng)過(guò)這次實(shí)踐之后我們就實(shí)例支持的隊(duì)列數(shù) / 網(wǎng)卡數(shù)，包括支持的 IP 數(shù)都把它加到了我們的評(píng)測(cè)體系里面，以及它的帶寬和 PPS 指標(biāo)，其中多網(wǎng)卡，多 IP 是有一些其他的應(yīng)用場(chǎng)景需要的。

儲(chǔ)存測(cè)評(píng)

第二方面是存儲(chǔ)，主要就是可用性，IOPS，吞吐量等方面的評(píng)測(cè)。

這里要說(shuō)一點(diǎn)的就是我們會(huì)更加追求性價(jià)比， 舉一個(gè)例子，假設(shè)有一個(gè)數(shù)據(jù)庫(kù)的應(yīng)用它的需求是需要一個(gè) 600G 大小的快存儲(chǔ)，IOPS 要求是 10000，吞吐量要求是 200MB/s。因?yàn)檫@是一個(gè)高 IOPS 的應(yīng)用，我們第一個(gè)想到的方案可能就是用 IO1 EBS，因?yàn)?IOE 是一個(gè)可以制定 IOPS 的高性能方案。

但其實(shí)還有一個(gè)方案是用一個(gè)很大的 GP2 的磁盤(pán)，GP2 是一種 IOPS 隨容量增大的 EBS，比如這里寫(xiě)的 3.3T 這么大的磁盤(pán)，它的 IOPS 也能夠達(dá)到 10000，但是它的價(jià)格不到 IO1 的一半，這時(shí)候我們可能就傾向于用 GP2 去承載存儲(chǔ)密集型的業(yè)務(wù)。

網(wǎng)絡(luò)測(cè)評(píng)

接下來(lái)是網(wǎng)絡(luò)評(píng)測(cè)，這一塊分為兩方面：一個(gè)是 IDC 網(wǎng)絡(luò)，一個(gè)是玩家網(wǎng)絡(luò)。

IDC 網(wǎng)絡(luò)就會(huì)比較直觀了，比如說(shuō)要在新加坡部署一個(gè)服，那新加坡的服跟日本的服互相之間可能需要交互，例如跨服戰(zhàn)斗。那這時(shí)候就需要評(píng)估新加坡到日本這些地方的數(shù)據(jù)中心的網(wǎng)絡(luò)延遲能否滿足游戲需求？

通常來(lái)說(shuō)不同的游戲可能會(huì)有不一樣的需求，這個(gè)游戲是 100 毫秒，那個(gè)游戲可能是 200 毫秒，所以就需要我們有這樣的評(píng)測(cè)數(shù)據(jù)作為決策支撐。圖里是舉例在 AWS 上面的一個(gè)評(píng)測(cè)案例，我們?cè)u(píng)測(cè)了 AWS 新加坡到日本和韓國(guó) AWS 節(jié)點(diǎn)之間的網(wǎng)絡(luò)情況；當(dāng)然實(shí)際的評(píng)測(cè)會(huì)更加復(fù)雜和龐大一些。

對(duì)于玩家網(wǎng)絡(luò)評(píng)測(cè)，這個(gè)也很直白，比如說(shuō)還是在新加坡部署一個(gè)服，但是面向的玩家可能是東南亞地區(qū)，越南，泰國(guó)，馬來(lái)，印尼，菲律賓等。

那這些地方的玩家到數(shù)據(jù)中心的網(wǎng)絡(luò)是否能夠滿足到我們游戲需要的延遲 / 丟包的要求，這就需要我們做一個(gè)全面的評(píng)測(cè)。通過(guò)我們?cè)诟鞯赝婕铱蛻舳?SDK 中加入探針去探測(cè)這些地區(qū)的玩家到數(shù)據(jù)中心網(wǎng)絡(luò)的延遲和丟包情況，一般的會(huì)測(cè)游戲本身流量基于的協(xié)議，比如說(shuō) TCP 或者是 UDP 或者是其它自研協(xié)議，圖中就是一個(gè)玩家網(wǎng)絡(luò)評(píng)測(cè)樣例。

數(shù)據(jù)為偽數(shù)據(jù)，僅作示例，請(qǐng)勿參考

其他測(cè)評(píng)

其它我們也會(huì)有很多方面的標(biāo)準(zhǔn)化評(píng)測(cè)，包括剛才提到的安全性是一個(gè)非常重要的方面，因?yàn)槲覀兌嗫钣螒蛟?DDOS 上吃過(guò)很多虧，也做了一些優(yōu)化方案，其他的還有例如基礎(chǔ)設(shè)施可編程，因?yàn)槲覀冇袛?shù)十上百款游戲，光在 AWS 上面可能就有成千上萬(wàn)臺(tái)服務(wù)器，我們需要用到云的 API 或者是 SDK 來(lái)開(kāi)發(fā)我們的自動(dòng)化管理工具。

還有技術(shù)支持方面，除了售前的架構(gòu)咨詢，還有就是售后的 7*24 故障響應(yīng)等等。另外成本也會(huì)做一個(gè)綜合的評(píng)估，包括收費(fèi)模式，費(fèi)用對(duì)比等；網(wǎng)易游戲?qū)υ频臉?biāo)準(zhǔn)化評(píng)測(cè)大概就是這一些方面。

經(jīng)過(guò)評(píng)測(cè)之后 AWS 是一個(gè)符合業(yè)務(wù)需求的選擇，因?yàn)?AWS 有廣泛的全球基礎(chǔ)設(shè)施，在計(jì)算存儲(chǔ)網(wǎng)絡(luò)等方面都有高性能的方案，所以很自然 AWS 成為我們海外發(fā)行比較重要的選擇之一。

實(shí)踐心得

最后我想分享一下經(jīng)過(guò)這幾年海外上云實(shí)踐的心得總結(jié)：

第一點(diǎn)：實(shí)踐永遠(yuǎn)是檢驗(yàn)技術(shù)的唯一標(biāo)準(zhǔn)，一項(xiàng)新的技術(shù)是否值得引入需要評(píng)估測(cè)試，經(jīng)過(guò)線上實(shí)踐驗(yàn)證，能明確它能夠?qū)ξ覀儤I(yè)務(wù)產(chǎn)生價(jià)值我們才會(huì)認(rèn)為它是一項(xiàng)很好的技術(shù)。

第二點(diǎn)：我們會(huì)在滿足業(yè)務(wù)需求的前提下不斷尋求成本優(yōu)化的解決方案。

第三點(diǎn)：不管是云還是游戲，每天都在快速發(fā)展，這就需要我們不斷學(xué)習(xí)，尋找業(yè)務(wù)的切入點(diǎn)， 切實(shí)滿足業(yè)務(wù)需求或優(yōu)化線上服務(wù)，我覺(jué)得這是我們做云架構(gòu)或云解決方案的核心價(jià)值。

希望能對(duì)大家有所啟發(fā)。

中國(guó)區(qū)首次舉辦的 AWS Game Tech Day- AWS 游戲開(kāi)發(fā)者大會(huì)深圳站已與 2019 年 4 月 27 日完滿落幕，作為目前為止規(guī)模最大的 AWS 游戲行業(yè)會(huì)議, 內(nèi)容豐富更勝以往。對(duì)于行業(yè)未來(lái)發(fā)展，網(wǎng)易游戲?qū)W院與 AWS 擁有同樣的愿景，希望游戲能夠在運(yùn)行流暢之余不斷創(chuàng)新，也希望借助這個(gè)平臺(tái)，與全球游戲熱愛(ài)者自由交流，碰撞出思想和技術(shù)的火花，攜手探索出更多的可能性