前面的話：本文只是本人單純的臆測，如有雷同，純屬巧合。
1、遊戲說明
玩法跟COC基本沒區別，只不過除了普通的兵，多了一些武將，並且社交系統比COC加強了不少，但總體來說交互性和實時性還是比較弱的。閱讀以下文檔之前最好對此款遊戲有一些基本瞭解。此文檔目的在於理清使用雲平臺架構全球大服的思路，若以後有類似的需求，可以進行一些參考。
2、機房架構及說明
首先看看全局的架構圖：
首先，各種渠道的客戶端限制了玩家連接的機房，比如大陸的包只能連到阿里雲，跟其他因素無關，即使IP是美國、香港也是如此，這樣可以儘可能的靠近玩家，不會讓網絡連接過慢影響體驗。遊戲在檢測到新玩家的時候就給玩家加一個標識，比如大陸玩家標識爲CN，香港玩家標識爲HK，這一點跟COC是一樣的。
另外看到在大陸地區使用了阿里雲，其他地區都使用了亞馬遜，同樣的一套東西使用2個服務，多多少少有些彆扭，這是因爲亞馬遜當時在大陸沒有機房，但最近在北京開設了機房，如果以後要使用雲服務，最好就統一使用同一個服務商提供的服務了。（阿里雲在9月初又出故障，你還敢用嗎？）
每個機房構成了一個區域服，屬於這個區域的玩家的一些私有數據存儲在各自的區域服中，比如在線獎勵、任務、揹包、郵件、本地副本、好友列表等一些玩傢俬有數據，因爲這些數據跟其他的玩家不會發生交互，所以存放在各自的區域服即可。
另外一些可能跟其他區域玩家交互的數據，如公衆聊天、軍團數據、LBS，則統一放在一個機房，在圖中則假設放在新加坡機房，另外還會處理一些全局的事務，如軍團戰的倒計時等。
具體把公共數據和公共服務放在哪個機房需要具體分體具體分析，其中一個因素是根據各機房之間的網絡時延，由於需要在服務器之間傳輸數據，需要找到一個與各個機房傳輸網絡最好的機房。
當各機房之間需要發生一些交互時，通過遠程RPC的方式來進行交互。
3、機房內部架構圖
再看看內部的架構圖：
下面來分塊講解，由於看不到君臨天下的具體實現，所以以下部分把所有可能的方案都列舉了出來，僅供參考。
負載均衡器
使用它的目的是爲了防止區域同時在線玩家過多。
阿里雲方面提供的產品是：負載均衡SLB。
相關地址爲：http://www.aliyun.com/product/slb/?spm=5176.383338.201.10.MiaoNt
亞馬遜方面提供的產品是：Elastic Load Balancing。
相關地址爲：https://aws.amazon.com/cn/elasticloadbalancing/
另外也可以自行搭建，如最新的Nginx版本就可以提供這些功能。
遊戲邏輯服和全局後臺任務
這裏的服務是跑在阿里雲或者亞馬遜的虛擬主機中，具體的業餘由於邏輯開發人員制定，但要保證不能存儲狀態數據，要保證一個玩家連接到任何一臺邏輯服上都是一樣的，邏輯服中也包含遠程RPC的服務，如果使用Apache的Thrift來做遠程RPC可減輕開發工作。
分佈式緩存集羣
緩存一些使用頻繁的數據。
阿里雲方面提供的產品是：開放緩存服務OCS，支持Memcached協議。
相關地址爲：http://www.aliyun.com/product/ocs/?spm=5176.383633.3.8.7LIixc
還有：鍵值存儲KVStore for Redis，支持Redis協議。
相關地址爲：http://www.aliyun.com/product/kvstore?spm=5176.683009.3.9.Eb6gfl
亞馬遜方面提供的服務是：Amazon ElastiCache，同時支持Memcached協議和Redis協議。
相關地址爲：https://aws.amazon.com/cn/elasticache/
另外也可以自行搭建一套，個人建議使用Redis 3.0的集羣版本。
分佈式數據庫集羣
阿里雲和亞馬遜都提供了MySQL的服務，但都是單機的主從架構，存在單機瓶頸，無法橫向擴展，雖然阿里雲提供了一個解決方案，就是引入了一箇中間件來自動分表分庫，相關地址爲：http://www.aliyun.com/product/drds/?spm=5176.7630237.3.32.y4m8wM
但因爲在亞馬遜上沒有這種服務，所以不推薦使用，故下面主要介紹NoSQL的產品，它的好處就是不需要關注可擴展性的問題。
另外如果實在需要MySQL，也可以自行搭建，如使用一些相對比較成熟的開源方案。
如阿里開源的Cobar：https://github.com/alibaba/cobar
和OneProxy：http://www.onexsoft.com/?page_id=3383
優勢是可以自動的分庫分表，對應用層開發透明，缺點是會損失一部分功能，如無法使用存儲過程，無法跨庫進行JOIN操作，不過這點對互聯網以及遊戲業務來說影響不大。
阿里雲提供的NoSQL產品爲：開放結構化數據服務OTS。
相關地址爲：http://www.aliyun.com/product/ots/?spm=5176.7622920.3.7.TAp1cO
亞馬遜提供的NoSQL產品爲：Amazon DynamoDB
相關地址爲：https://aws.amazon.com/cn/dynamodb/
若自行搭建可選用Mongo、HBase等，這方面的候選方案比較豐富，可酌情選擇。
分佈式文件系統
主要是存儲一些日誌、戰報等文件。
阿里雲提供的服務爲：開放存儲服務OSS
相關地址爲：http://www.aliyun.com/product/oss/?spm=5176.7393637.3.10.PBAGYg
亞馬遜這一塊服務分得比較細，可根據實際需求使用，如圖：
相關地址爲：https://aws.amazon.com/cn/products/?nc2=h_ql
自行搭建的話，若量不大，可存本地文件系統，如有必要可搭建分佈式文件系統，如HDFS等等。
隊列系統
引入的目的是會使用到一些Pub/Sub、異步計算等場景。
阿里雲相關服務爲：開放消息服務ONS
相關地址爲：http://www.aliyun.com/product/ons/?spm=5176.383663.3.33.iByuFr
值得一提的是此服務支持延時消息。
亞馬遜相關服務爲：Amazon SQS
相關地址爲：https://aws.amazon.com/cn/sqs/
不過功能略爲簡單，不能滿足一些場景，不推薦使用。
也可以自行搭建，如RabbitMQ，RocketMQ等，若要支持延時隊列，建議使用Beanstalkd，總而言之根據具體的場景來選擇。
關於CDN、DNS、推送等一些技術方案此處先略過。
4、某些功能服務端方面的流程的分析
這裏對一些需要涉及跨區域交互的遊戲功能的服務端流程進行一些分析，僅是自己的主觀分析。
場景1 世界排行榜
各個區域都維護一份自己的前200名的排行榜，定時再去其他區域拉取指定的前200名的排行榜，合併成一份世界前200名的排行榜即可。
場景2 攻城略池
就是找其他一些玩家攻擊，其實搜到的玩家都是本區域的，如果實在要搜別的區域的玩家，可以定時去拉取一批玩家數據過來，再隨機返回一個即可。戰鬥結束後，向雙方的攻擊/防守日誌中插入一條記錄，對於非本區域的玩家，則進行遠程RPC調用一下即可。
場景3 羣雄爭霸
類似於競技場，從一個時間段開始，比如上午7點開始，隨機抽取全世界的一些玩家到一個小組裏，你可以攻擊小組裏的其他玩家，到了規定的時間後結算排名，可以領取排名獎勵。
可以在區域服的公共定時任務中來做，同樣也是從其他區域服中拉取其他玩家的數據來生成小組。
場景4 公衆聊天
對於公衆聊天，遊戲對語言進行區分，分爲中文、英語、韓語、日語做了區分，華語渠道的玩家只能進中文聊天室，日本渠道玩家只能進日語聊天室，韓國渠道玩家只能進韓語聊天室，其他渠道玩家只能進英文聊天室。
這是因爲遊戲沒有像COK那樣做翻譯功能，只能做這樣的限制，讓說同一種語言的人在一起聊天。
另外處於性能考慮，公衆聊天切分成了數個聊天室，如下圖：
這樣做可以降低聊天消息的廣播，這也是出於對網絡延遲和性能的考慮。當某個聊天室的玩家發言後，就把該消息發向本區域和其他區域的處於同一個聊天室中的其他玩家。當玩家退出，再次登錄進入聊天室時，並不能獲取之前的聊天記錄，可見不會存儲公衆聊天。
場景5 好友系統
搜索好友的功能，應該是交給全局服務區域來完成的，這裏假設是在新加坡完成的，新加坡定時把其他區域的玩家基礎表（只包含頭像ID、等級等基礎數據）異步增量同步一次。依據是對於剛註冊的用戶，無論是在本區域還是其他區域，都無法搜索到，而對於隨機一個高等級的玩家來說，在本區域後者其他區域都可以搜到。這樣做降低了實時性，降低了開發難度。
搜到好友之後可以查看玩家更具體的資料，如擁有的武將，陣形等等，可以通過國家來判斷在哪個區域，遠程RPC來獲取資料。
然後可以申請添加對方爲好友，也是利用遠程RPC的方式通知對方，把自己添加到對方的好友申請列表中。對於玩家留言也是如此。
最後是LBS，應該也是全局處理的。
場景6 軍團系統
軍團是各個區域的玩家都能夠隨意加入或者離開的，軍團沒有國家的概念，故軍團的數據應該是在全局區域存儲的，這裏是存儲在新加坡，數據包括軍團成員、軍團科技等等，玩家獲取或修改軍團數據通過遠程RPC操作。
對於軍團搜索，剛創建的軍團是可以馬上搜索到的，這也印證了軍團的數據是全局存儲的。
對於軍團聊天，跟公衆聊天的處理方式是類似的，區別是會存儲聊天記錄。
對於軍團援兵，就是廣播給其他的在線的軍團成員請求援兵，對方收到通知後則回饋，否則不做處理。
軍團戰的邏輯也基本沒什麼新意，不贅述。