歡迎來到Tungsten Fabric用戶案例系列文章，一起發(fā)現(xiàn)TF的更多應(yīng)用場景?！敖颐豅OL”系列的主人公是Tungsten Fabric用戶Riot Games游戲公司，作為LOL《英雄聯(lián)盟》的開發(fā)和運(yùn)營商，Riot Games面臨全球范圍復(fù)雜部署的挑戰(zhàn)，讓我們一起揭秘LOL背后的“英雄們”，看他們是如何運(yùn)行在線服務(wù)的吧。

創(chuàng)新互聯(lián)公司是專業(yè)的愛輝網(wǎng)站建設(shè)公司，愛輝接單;提供網(wǎng)站建設(shè)、網(wǎng)站制作,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行愛輝網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作! 作者：Nicolas Tittley和Ala Shiban（文章來源：Riot Games）譯者：TF編譯組

這個長系列的文章，探討并記錄了Riot Games如何開發(fā)、部署和運(yùn)營后端基礎(chǔ)架構(gòu)的歷程。我們是Riot 開發(fā)體驗團(tuán)隊的軟件架構(gòu)師兼產(chǎn)品經(jīng)理Nicolas Tittley和Ala Shiban。我們團(tuán)隊負(fù)責(zé)幫助Riot開發(fā)人員在玩家所處的任何地方構(gòu)建、部署和運(yùn)營游戲，同時專注于云無感（cloud-agnostic）平臺，這些平臺使游戲的發(fā)行和運(yùn)營變得更加輕松。 在過去的兩年前的一篇文章中，Maxfield Stewart介紹了有關(guān)開發(fā)生態(tài)系統(tǒng)，以及當(dāng)時使用的許多工具。這里我們將更新一些最新的內(nèi)容，包括面臨的新挑戰(zhàn)，如何解決問題，以及我們從中學(xué)到的東西。

快速回顧

我們強(qiáng)烈建議您回過頭閱讀以前的文章，但是如果您想直接閱讀本文，這里有一個超級精簡版本來幫您趕上進(jìn)度。 Riot使用裸金屬和云基礎(chǔ)架構(gòu)的組合來在全球范圍內(nèi)運(yùn)行后端系統(tǒng)。這些后端系統(tǒng)被分散到不同的地理位置，基于完全不同的部署，運(yùn)行著允許玩家與LOL《英雄聯(lián)盟》互動的整套服務(wù)。像大多數(shù)游戲的后端系統(tǒng)一樣，LOL后端開始時作為一個整體，由專門的運(yùn)營團(tuán)隊來負(fù)責(zé)運(yùn)營。隨著時間的推移，Riot逐漸擁抱了DevOps實(shí)踐和基于微服務(wù)的體系架構(gòu)。 本系列的第一篇文章做了詳細(xì)介紹，為了幫助我們的開發(fā)人員更快地服務(wù)玩家，Riot大量依賴于Docker容器這種打包服務(wù)，并開始在集群調(diào)度程序中運(yùn)行它們。直到 最近一篇文章，討論了為實(shí)現(xiàn)此目的而使用的許多工具。

運(yùn)行效果如何？

非常牛，但，痛并快樂著。 在上篇文章發(fā)表之時（ 編者按：發(fā)表時間為2017年12月 ），我們運(yùn)營著5000多個生產(chǎn)容器。這個數(shù)字并沒有停止增長，今天，僅在Riot自主運(yùn)營的區(qū)域（Riot-operated regions），我們就運(yùn)行了14,500多個容器。Riot的開發(fā)人員喜歡為玩家創(chuàng)造新事物，當(dāng)他們越容易編寫、部署和運(yùn)營服務(wù)，他們就越能創(chuàng)造出令人興奮的新體驗。 開發(fā)團(tuán)隊以真正的DevOps方式，擁有并負(fù)責(zé)他們的服務(wù)。他們創(chuàng)建了工作流來部署、監(jiān)視和運(yùn)營那些服務(wù)，當(dāng)他們找不到所需的東西時，就干脆自己發(fā)明再造。對于開發(fā)人員來說，這是一個非常自由的時期，他們很少遇到無法自行解決的問題。 但慢慢地，我們開始注意到一些令人擔(dān)憂的趨勢。每個月的QA和負(fù)載測試環(huán)境變得越來越不穩(wěn)定。我們不得不花費(fèi)更多的時間，來查找錯誤的配置或過時的依賴關(guān)系。這些孤立的事件并不是關(guān)鍵，但總的來說，它們耗費(fèi)了團(tuán)隊很多時間和精力——我們更愿意將其花費(fèi)在創(chuàng)造玩家價值上。 更糟糕的是，在非Riot自主運(yùn)營的分片區(qū)域（non-Riot shards），不僅開始出現(xiàn)類似的困難，而且還爆出一系列其它問題。合作伙伴們必須與越來越多的開發(fā)人員進(jìn)行對接，并采用越來越多的微服務(wù)，每種微服務(wù)都有不同的方式，彼此各不一樣。現(xiàn)在，運(yùn)營人員必須比以往更加努力，以創(chuàng)造出有效且穩(wěn)定的分片區(qū)域。在這些非Riot自主運(yùn)營的分片區(qū)域，問題發(fā)生率要高得多，直接原因就是微服務(wù)的實(shí)時版本不兼容，或者其它類似的跨界問題。

Riot的DevOps現(xiàn)狀

在討論如何解決打包、部署和運(yùn)營之前，讓我們花一點(diǎn)時間來探討Riot的運(yùn)行環(huán)境。這些都不是Riot所獨(dú)有的，但所有這些細(xì)節(jié)的重疊，都說明了我們是如何組織起來，以便為所有玩家提供價值的。 開發(fā)者模式

---

Riot的工程師們喜歡自己建造東西！為了幫助他們做到這一點(diǎn)，我們采用了強(qiáng)大的DevOps思維方式。團(tuán)隊建立并擁有了自己的后端服務(wù)，確保對其提供支持，并在服務(wù)表現(xiàn)不如預(yù)期時進(jìn)行分流?？偟膩碚f，Riot工程師很高興能夠?qū)崿F(xiàn)快速迭代，也很樂意對自己的實(shí)時服務(wù)負(fù)責(zé)。這是一個非常標(biāo)準(zhǔn)的DevOps設(shè)置，Riot并沒有在任何方面逆勢而上。 有狀態(tài)分片模式

---

由于歷史原因、規(guī)模性問題，以及法律方面你的因素，Riot產(chǎn)品的后端系統(tǒng)按照分片的方式進(jìn)行組織。其中，生產(chǎn)分片通常在地理位置上靠近目標(biāo)受眾。這樣做有許多好處，包括改進(jìn)的延遲問題，更好的匹配性，有限的故障域，以及清晰的非高峰時間窗口（可在其中執(zhí)行維護(hù)操作）。當(dāng)然，我們還在內(nèi)部和外部運(yùn)行著許多開發(fā)和QA分片，例如《英雄聯(lián)盟》公開測試服（PBE）。  
運(yùn)營模式

---

這是事情變得更加復(fù)雜的地方。盡管Riot是開發(fā)者，但出于合規(guī)性和專有技術(shù)的原因，我們與一些本地運(yùn)營商合作以提供一些服務(wù)分片。實(shí)際上，這意味著Riot的開發(fā)人員必須打包分片的每個組件，將其交付給運(yùn)營人員，并指導(dǎo)他們?nèi)绾尾渴稹⑴渲煤瓦\(yùn)營所有分片。Riot的開發(fā)人員不會自己去操作、訪問甚至查看這些分片。（編者按：文中的分片邏輯可以理解成分塊分區(qū)域的定義）

迭代解決方案

嘗試1-新的聯(lián)盟部署工具

---

我們第一次嘗試改善情況，就采取了全新的方法，嘗試?yán)瞄_源組件和最少Riot定制功能，來推進(jìn)Riot的部署和運(yùn)營工作。盡管這項工作成功地部署了完整的《英雄聯(lián)盟》分片，但工具的設(shè)計方式并沒有達(dá)到開發(fā)人員和運(yùn)營人員的期望。團(tuán)隊表達(dá)了對工具的不滿——這種工具被證明對運(yùn)營來說太難采用，對開發(fā)者來說太受約束。 因此，在第一個分片部署后，我們就做出了痛苦的決定——讓這些工具退役。這看起來好像很激進(jìn)，但由于所有團(tuán)隊仍然擁有自己維護(hù)的部署系統(tǒng)并且尚未完全過渡，因此我們能夠快速淘汰新的工具。 嘗試2-更多流程

---

由于第一次嘗試并不如預(yù)期的成功，我們轉(zhuǎn)向傳統(tǒng)，通過添加流程來達(dá)到要求。廣泛的溝通，明確的發(fā)布日期，文檔化的流程，變更管理會議和儀式，以及永遠(yuǎn)存在的電子表格，在某種程度上取得了一點(diǎn)點(diǎn)進(jìn)展，但始終感覺不佳。團(tuán)隊喜歡他們的自由DevOps，巨大的變化量和變化速度，都使他們的工作更加繁重。盡管合作伙伴的情況有所改善，但我們?nèi)晕催_(dá)到所期望的運(yùn)營水準(zhǔn)。 嘗試3-元數(shù)據(jù)

---

我們決定嘗試另一種方法。之前我們一直將開發(fā)人員作為工具的主要受眾，現(xiàn)在則開始研究針對于合作伙伴的運(yùn)營人員，部署/運(yùn)營系統(tǒng)將如何工作。我們精心設(shè)計了一種工具，允許開發(fā)人員向其Docker容器的打包微服務(wù)添加標(biāo)準(zhǔn)化元數(shù)據(jù)，例如所需的配置和擴(kuò)展特性。這帶來了進(jìn)步，運(yùn)營人員可以采用更加標(biāo)準(zhǔn)化的方式來理解所需的服務(wù)配置和部署特性，并且在日常運(yùn)營中減少對開發(fā)人員的依賴。 此時，本地和合作伙伴運(yùn)營站點(diǎn)的故障率、事件率和額外的停機(jī)時間都有所改善，但我們?nèi)匀活l繁遇到部署和運(yùn)營故障，這些故障本來都是可以避免的。 嘗試4-Riot的應(yīng)用程序和環(huán)境模式

---

我們最終采用了一種新方法，將關(guān)注點(diǎn)從個人服務(wù)轉(zhuǎn)移到了整個產(chǎn)品。我們創(chuàng)建了一個高級別的聲明性規(guī)范，以及可對其執(zhí)行操作的工具集，讓規(guī)范和工具變得與眾不同。在詳細(xì)介紹之前，我們先來看一下前三次的嘗試中出了什么問題。

反思錯誤之處

部署和運(yùn)營的是產(chǎn)品，而非服務(wù)

---

盡管擁抱DevOps和微服務(wù)給我們帶來了許多好處，但它創(chuàng)建了一個危險的反饋環(huán)路。開發(fā)團(tuán)隊創(chuàng)建微服務(wù)，對其進(jìn)行部署、運(yùn)營，并對其性能負(fù)責(zé)。這意味著他們?yōu)樽约簝?yōu)化了日志、度量標(biāo)準(zhǔn)和流程，并且通常很少考慮其服務(wù)能否為其他人所理解，包括沒有開發(fā)背景甚至工程能力的人。 隨著開發(fā)人員創(chuàng)建出越來越多的微服務(wù)，運(yùn)營整體產(chǎn)品變得非常困難，并導(dǎo)致越來越多的失敗。最重要的是，Riot的流動團(tuán)隊結(jié)構(gòu)，使一些微服務(wù)的所有權(quán)變得不清晰，很難在分流時搞清楚應(yīng)該與誰聯(lián)系，從而導(dǎo)致出現(xiàn)很多屬性錯誤的頁面。越來越多的異構(gòu)微服務(wù)、部署流程和組織變更，使得合作伙伴地區(qū)的運(yùn)營團(tuán)隊不知所措。 搞清楚“為什么”

---

我們檢查了Riot運(yùn)營區(qū)域和非Riot運(yùn)營區(qū)域的故障，并將故障頻率的差異提煉為一項關(guān)鍵的觀察結(jié)果： 允許不連續(xù)的變更流進(jìn)入分布式系統(tǒng)最終將導(dǎo)致可預(yù)防的事件。 當(dāng)團(tuán)隊希望跨邊界進(jìn)行協(xié)調(diào)時，就會開始發(fā)生故障，因為依賴關(guān)系需要將發(fā)布與多個更改捆綁在一起。團(tuán)隊要么使用人工流程來創(chuàng)建發(fā)布周期，通過項目管理儀式協(xié)調(diào)發(fā)布，要么臨時發(fā)布較小規(guī)模的發(fā)布更改，導(dǎo)致團(tuán)隊在找出兼容版本的過程中陷入混亂。 兩者各有其優(yōu)缺點(diǎn)，但是在大型組織中往往會崩潰。想象一下，數(shù)十個團(tuán)隊需要以協(xié)調(diào)的方式，連續(xù)交付代表共享產(chǎn)品的數(shù)百個微服務(wù)，并且允許這些微服務(wù)使用不同的開發(fā)實(shí)踐。更糟的是，對于合作伙伴來說，嘗試應(yīng)用這些流程非常困難，他們的操作人員缺乏關(guān)于各個部分如何組合起來的上下文。

新解決方案：Riot的應(yīng)用程序和環(huán)境模型

鑒于先前的嘗試未能產(chǎn)生預(yù)期的結(jié)果，我們決定通過創(chuàng)建一個自用固有對的（opinionated）聲明性規(guī)范來消除部分狀態(tài)操縱，該聲明性規(guī)范可以捕獲整個分布式產(chǎn)品——環(huán)境。環(huán)境包含完全指定、部署、配置、運(yùn)行和運(yùn)營一組分布式微服務(wù)所需的所有聲明性元數(shù)據(jù)，這些微服務(wù)共同代表一種產(chǎn)品，并且是完整且不變的版本。我們之所以選擇“環(huán)境”這個名字，是因為它是Riot 最不會過度使用的一個詞。命名實(shí)在是一件難事。 隨著游戲《符文之地傳奇》LOR的發(fā)布，我們證明了可以描述整個的微服務(wù)游戲后端（包括游戲服務(wù)器），并使其在Riot自主運(yùn)營地區(qū)以及全球合作伙伴的數(shù)據(jù)中心中，作為產(chǎn)品進(jìn)行部署、運(yùn)行和運(yùn)營。我們還展示了實(shí)現(xiàn)這一目標(biāo)的能力，同時改善了已經(jīng)廣受喜愛的DevOps方法的優(yōu)勢。 對什么進(jìn)行規(guī)定描述（OPINIONATED ON WHAT）

---

該規(guī)范描述了服務(wù)捆綁包或環(huán)境之間的層次關(guān)系。  
捆綁到環(huán)境規(guī)范中的應(yīng)用程序規(guī)范
聲明性與高等級 聲明性規(guī)范的好處之一是它易于操作。對于合作伙伴的運(yùn)營人員，他們的其中一個困難，就是無法理解、調(diào)整和潛在地自動化整個游戲后端的部署方式。規(guī)范的聲明性性質(zhì)，意味著它不需要工程師具有腳本或編程專業(yè)知識，就可以對規(guī)范中的大多數(shù)內(nèi)容進(jìn)行更改。 保持規(guī)范的高等級，有助于將游戲后端的定義與基礎(chǔ)實(shí)現(xiàn)脫鉤。這使我們能夠在對游戲工作室影響最小的情況下，從名為Admiral的內(nèi)部編排器/調(diào)度程序，遷移到基于Mesos的調(diào)度程序，以及考慮遷移到Kubernetes。它還使我們的合作伙伴運(yùn)營人員可以在需要時交換其基礎(chǔ)架構(gòu)組件。例如，它允許運(yùn)營人員可以使用不同的指標(biāo)聚合系統(tǒng)，而不需要更改微服務(wù)工具。 不可變與版本化 我們發(fā)現(xiàn)，要在快速發(fā)展的DevOps世界中有效部署和運(yùn)營，使用共享語言來引用服務(wù)和環(huán)境至關(guān)重要。版本控制服務(wù)和環(huán)境及其關(guān)聯(lián)的元數(shù)據(jù)，使我們能夠確保所有位置都部署了正確的版本。它使我們的合作伙伴運(yùn)營人員可以確定地知道正在運(yùn)行哪個版本，并且回傳給我們。此外，當(dāng)應(yīng)用于整個環(huán)境時，它提供了一組眾所周知的服務(wù)，可以對其進(jìn)行質(zhì)量檢查并標(biāo)記為“好”。這種捆綁消除了在向合作伙伴傳達(dá)新版本時遺失依賴項的任何可能性。 使這些版本不可變，可以確保我們維持這種通用語言。當(dāng)相同版本的服務(wù)被部署在兩個不同的分片中，我們現(xiàn)在也可以確定它們是完全相同的。 專注于運(yùn)營 鑒于我們的目標(biāo)是提高合作伙伴運(yùn)營人員服務(wù)玩家的水平，我們很快意識到，部署軟件只是第一步。了解如何對實(shí)時系統(tǒng)進(jìn)行分類、運(yùn)營和維護(hù)，是同樣重要的事情。 從歷史上看，我們非常依賴于運(yùn)行手冊。手冊由開發(fā)人員維護(hù)，并取得了不同程度的成功，他們記錄了從必需的配置值到高等級體系架構(gòu)的所有內(nèi)容。為了使合作伙伴運(yùn)營人員具備配置和操作每種服務(wù)所需的全部知識，我們決定將這些運(yùn)行手冊中包含的盡可能多的信息帶到服務(wù)規(guī)范的最前面。這大大減少了合作伙伴地區(qū)投入新服務(wù)的時間，并確保他們在微服務(wù)更新時被告知所有重要變化。 如今，合作伙伴運(yùn)營人員可以使用該規(guī)范來了解有關(guān)操作元數(shù)據(jù)的信息，包括所需/可選配置、擴(kuò)展特性、維護(hù)操作，重要指標(biāo)/警報定義、部署策略，服務(wù)間依存關(guān)系，以及越來越多的其它有用信息。 處理分片差異

---

當(dāng)然，分片不是彼此完全相同的副本。盡管我們希望使它們盡可能地接近，但總有一些配置必須有所不同。數(shù)據(jù)庫密碼、支持的語言、擴(kuò)展參數(shù)，以及特定的調(diào)整參數(shù)必須隨每個分片而變化。為了支持該模式，我們的工具使用分層的覆蓋系統(tǒng)部署環(huán)境規(guī)范，使運(yùn)營人員可以專門化特定的部署，同時仍然知道它們都源自已知的良好版本。讓我們看看它是如何工作的！ 應(yīng)用案例

---

一個簡單的游戲后端可以包括兩個環(huán)境，一個用于游戲服務(wù)器，另一個用于元游戲服務(wù)（排行榜，匹配系統(tǒng)等）。元游戲環(huán)境由多種服務(wù)組成：排行榜、匹配系統(tǒng)、比賽歷史等等。每個服務(wù)都包含一個或多個Docker映像，從概念上講，它們等效于Kubernetes容器。對于所有環(huán)境，相同的層次結(jié)構(gòu)都是正確的，并且從哲學(xué)上講，每一個環(huán)境都毫無例外地封裝了在任何受支持的基礎(chǔ)架構(gòu)或云上部署、運(yùn)行和運(yùn)營的游戲后端所需的一切，及其所有的依賴項。 該規(guī)范還包括運(yùn)行和運(yùn)營整個環(huán)境所需的所有元數(shù)據(jù)。不斷增長的集合包括配置、機(jī)密、指標(biāo)、警報、文檔、部署及rollout策略、入站網(wǎng)絡(luò)限制，以及存儲、數(shù)據(jù)庫和緩存要求。 下面我們有一個示例，演示在兩個區(qū)域中進(jìn)行兩個假設(shè)的游戲分片部署。您可以看到它們都由元游戲環(huán)境和游戲服務(wù)器環(huán)境組成。在歐洲分片中的游戲服務(wù)器產(chǎn)品環(huán)境，落后于美國分片中的同類游戲環(huán)境。這為游戲和運(yùn)營團(tuán)隊提供了描述和比較不同游戲分片部署的通用語言。每個環(huán)境中不斷增加的服務(wù)數(shù)量可以保持簡單性，從而可以可靠地部署數(shù)十個分片。 游戲分片部署示例
我們的下一步：延遲感知調(diào)度

---

我們希望能夠描述服務(wù)之間的預(yù)期和可接受的延遲，并使工具針對基礎(chǔ)區(qū)域和較低級別的PaaS服務(wù)進(jìn)行優(yōu)化，使其能夠滿足這些需求。這將導(dǎo)致某些服務(wù)位于同一個機(jī)架、主機(jī)或云區(qū)域中，而不是允許它們分布在其它服務(wù)中。 由于游戲服務(wù)器和支持服務(wù)的性能特點(diǎn)，這件事與我們高度相關(guān)。Riot已經(jīng)是一家多云公司，有我們自己的數(shù)據(jù)中心，也有AWS以及合作伙伴的云，但是我們依靠靜態(tài)設(shè)計的拓?fù)?。紙牌游戲和射擊游戲具有不同的配置文件，不必針對一、兩種情況的優(yōu)化進(jìn)行手工拓?fù)?，從而?jié)省了工程師們的時間，使他們可以專注在游戲上面。

最后的話

我們在運(yùn)行游戲過程中面臨著穩(wěn)定性下降的問題，主要是來自合作伙伴經(jīng)營的游戲分片。工具開發(fā)團(tuán)隊捆綁了開源部署工具，并將元數(shù)據(jù)添加到了容器中，而游戲團(tuán)隊則實(shí)施了集中發(fā)布流程。這些方法可以解決癥狀，但不能解決導(dǎo)致問題的根本原因，這意味著我們未能達(dá)到目標(biāo)水準(zhǔn)。 我們最終采用的解決方案引入了一個新規(guī)范，該規(guī)范捕獲了整個游戲后端的所有拓?fù)?、層次結(jié)構(gòu)和元數(shù)據(jù)及其所有依賴項。這種方法之所以有效，是因為它帶來了綁定容器的一致的版本發(fā)布，它們之間交互方式的依賴關(guān)系，以及啟動和操作整個游戲所需的所有支持元數(shù)據(jù)。而不可變性帶來了確定性的部署和可預(yù)測的操作。 作為一個平臺團(tuán)隊，我們的目標(biāo)是挑選能夠產(chǎn)生良性循環(huán)的系統(tǒng)和構(gòu)建模塊，在這樣的良性循環(huán)中，功能開發(fā)工作自然會帶來易于操作的產(chǎn)品。將DevOps模式的敏捷性與易于操作的整個產(chǎn)品相結(jié)合是長期組織敏捷性的關(guān)鍵。我們的環(huán)境捆綁方法直接改善了運(yùn)營指標(biāo)，更重要的是提高了玩家體驗的質(zhì)量。我們很高興看到業(yè)界其他人士如何解決類似的問題。我們已經(jīng)看到了來自CNCF（云原生計算基金會）和大型云供應(yīng)商（例如Microsoft開放應(yīng)用程序模式規(guī)范）的想法和項目。希望其中一些項目能夠取代我們自己制定的規(guī)范，并朝著全行業(yè)解決方案邁進(jìn)。 在以后的文章中，我們還將更詳細(xì)地探討Riot規(guī)范，介紹示例，并討論設(shè)計中的權(quán)衡以及Riot特定的快捷方式。 謝謝閱讀！如果您有任何疑問，非常歡迎與我們?nèi)〉寐?lián)系。

---

·END·

更多“揭秘LOL”系列文章

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨踏上部署 多樣性的征程

• 揭秘LOL背后的IT基礎(chǔ)設(shè)施丨關(guān)鍵角色“調(diào)度”

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨SDN解鎖新基礎(chǔ)架構(gòu)

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨基礎(chǔ)設(shè)施即代碼

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨微服務(wù)生態(tài)系統(tǒng)

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨開發(fā)者“打野”工具能做什么？
  

---

分享標(biāo)題：揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨產(chǎn)品而非服務(wù)-創(chuàng)新互聯(lián)
本文路徑：http://aaarwkj.com/article12/cdhhgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、服務(wù)器托管、面包屑導(dǎo)航、網(wǎng)站改版、外貿(mào)建站、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)