本篇文章為大家展示了Kubernetes實踐彈性的CI/CD系統(tǒng)現(xiàn)狀分析，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

公司專注于為企業(yè)提供網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、微信公眾號開發(fā)、商城網(wǎng)站建設(shè)，成都微信小程序，軟件按需設(shè)計網(wǎng)站等一站式互聯(lián)網(wǎng)企業(yè)服務(wù)。憑借多年豐富的經(jīng)驗，我們會仔細了解各客戶的需求而做出多方面的分析、設(shè)計、整合，為客戶設(shè)計出具風格及創(chuàng)意性的商業(yè)解決方案，創(chuàng)新互聯(lián)公司更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務(wù)。

首先簡單解釋一下何為 Kubernetes 來幫助大家理解。Kuberentes 是一個生產(chǎn)可用的容器編排系統(tǒng)。Kuberentes 一方面在集群中把所有 Node 資源做一個資源池，然后它調(diào)度的單元是 Pod，當然 Pod 里面可以有多個容器。 就像一個人左手抓著 ECS 資源或計算資源，右手抓容器，然后把它們兩個匹配起來，這樣它就可以作為一個容器的編排系統(tǒng)。
而 Cloudnative 這個概念現(xiàn)在會經(jīng)常被大家提起，很多人迷惑 Cloudnative 又與 Kuberentes 有什么關(guān)聯(lián)？我們又該如何判斷一個應(yīng)用是 Cloudnative 呢？我認為有以下三個判斷標準：
第一，它能夠給資源做池化；

第二，應(yīng)用可以快速接入池的網(wǎng)絡(luò)。在 Kuberentes 里面有一層自己的獨立網(wǎng)絡(luò)，然后只需要知道我要去訪問哪個服務(wù)名就可以，就是各種服務(wù)發(fā)現(xiàn)的一些功能，它可以通過 service mesh 去做一個快速地訪問；

第三是有故障轉(zhuǎn)移功能，如果一個池子里面有一臺主機，或者某一個節(jié)點 down 掉了，然后整個應(yīng)用就不可用了，這肯定不算是 Cloudnative 的應(yīng)用。

比較這三點就可以發(fā)現(xiàn) Kuberentes 做的非常好。首先我們看一個資源池的概念，Kuberentes 一個大的集群就是一個資源池，我們再也不用去關(guān)心說我這個應(yīng)用要跑在哪臺主機上了，我只要把我們部署的 yaml 文件往 Kuberentes 上發(fā)布就可以了，它會自動做這些調(diào)度，并且它可以快速地接入我們整個應(yīng)用的網(wǎng)絡(luò)，然后故障轉(zhuǎn)移也是自動。接下來我就來分享如何基于 Kuberentes 實現(xiàn)一個彈性的 CI/CD 系統(tǒng)。

CI/CD 的現(xiàn)狀

首先了解一下 CI/CD 的現(xiàn)狀。CI/CD 這個概念實際上已經(jīng)提出很多年了，但是隨著技術(shù)地演進和新工具地不斷推出，它在整個流程和實現(xiàn)方式上逐漸豐富。而我們通常最早接觸 CI/CD 就是代碼提交，隨之觸發(fā)一個事件，然后在某個 CI/CD 系統(tǒng)上做自動構(gòu)建。

下圖可以反映目前 CI/CD 的現(xiàn)狀：

它中間包含了很多流程，從代碼提交開始觸發(fā)一個事件，然后它可以中間做一層 Build ，首先通 maven 做一個 build，然后做一個單元測試，然后做代碼規(guī)范掃描，然后部署。 接下來，做一個端到端的 UI 方面的一層測試，這是一個 UI 的自動測試工具。

然后做了一個壓測（性能上的壓測），這只是在開發(fā)測試環(huán)境做了一層處理。然后它可以在 QA 環(huán)境，最終延伸到 UAT 環(huán)境，整個 pipeline 是一個非常長的過程。CI/CD 的使用范圍很廣，它可以把整個 IT 從代碼編寫提交到代碼倉庫為起點，從這兒開始往后做，各個步驟都可以納入 CI/CD 的范圍。但是隨著它的管控范圍越來越多，整個流程越來越復(fù)雜，它對資源的占用也是越來越高。
大家如果了解 C++的話，就會知道 C++ 以前是一門著名的、構(gòu)建時間特別長的語言。Go 語言的作者之一，也是 C 語言的作者, 談及當時寫 Go 完全是因為不想寫一次代碼，編譯那么久。所以，Go 語言剛出現(xiàn)時的一大優(yōu)勢就是編譯時間非常短。Go 的編譯時間確實非常短。

我曾用一個 I5 的筆記本編譯 Kubernetes 源碼做一次完整地構(gòu)建，大概編譯了 45 分鐘左右，這是一個非常漫長的過程。所以，即便已經(jīng)對編譯過程做了很大優(yōu)化和改進，只要項目大了之后，只是構(gòu)建階段就已經(jīng)很長了，更不要說包括后面的一些自動化測試了。包括所有東西之后，CI/CD 流程對資源地消耗和占用的時間是非常大的。

CI/CD 工具的選擇

接下來，我們看一下 CI/CD 這些工具的選擇和他們的發(fā)展。首先最老牌的肯定是 Jenkins。實際上在容器技術(shù)興起之前，CI/CD 簡直約等于 Jenkins。但是在出現(xiàn)容器技術(shù)之后，很多新生 CI/CD 的工具也應(yīng)運而生，比如 Drone 工具，它是一個完全基于容器來實現(xiàn)的 CI/CD 工具。它與容器地結(jié)合地非常好，并且它的構(gòu)建過程是完全在容器中實現(xiàn)的。

另外還有 Gitlab CI，它主要特點是與 Gitlab 代碼管理工具結(jié)合地比較好。Jenkins 2.0 開始引入 pipeline as code 特性，pipeline as code 可以幫我們自動生成一個 jenkins file。

在 Jenkins 1.0 時，如果我們想要配置一條流水線，需要先登錄 Jenkins 建一個項目，然后在里面寫一些 shell。這樣雖然能達到同樣的效果，但是它有一個最大的弊端，就是可復(fù)制性和遷移性不好。而且它與 Devops 有天然地割裂，比如一般是由運維人員來管理 Jenkins 系統(tǒng)，開發(fā)人員編寫代碼，但是這個代碼怎么去構(gòu)建，發(fā)布到哪里，開發(fā)人員完全不知道。這就造成了開發(fā)和運維地割裂。但 pipeline as code 方式出現(xiàn)了之后，jenkins file 與代碼源碼可以放在同樣的倉庫里面。
首先它有一個非常大的好處是發(fā)布的流程也可以納入版本管理，這樣對一個錯誤就可追溯。這是一個非常大地改動，但是實際上我們在與客戶溝通中發(fā)現(xiàn)，雖然很多人在 Jenkins 上都已經(jīng)升到 2.0 系列了，但是它們的用法還是完全在 1.0 系列，很多用戶都沒有把 jenkins file 這種方式用起來。另外一個就是對容器地支持，大概 2016 年左右，那時對容器的支持是非常弱的，在容器里面運行 Jenkins，同時構(gòu)建的產(chǎn)物也是 Docker 會非常麻煩。 
但是， Drone 對容器的支持力度就非常好。首先它完全用 Docker 方式來運行，就是說你的構(gòu)建環(huán)境也在一個容器里，你需要構(gòu)建一個 Docker build 鏡像，然后在推送出去的時候，它也在容器里面運行，然后它需要一個 privilege 權(quán)限。它這種方式有幾個特別好的地方，首先它不會對宿主機產(chǎn)生任何殘留，比如說你這個容器一銷毀，構(gòu)建中產(chǎn)生的一些中間文件完全都跟著銷毀了，但是你如果用 Jenkins 的話，隨著用的時間越來越久會沉淀出很多臨時文件，它占的空間會越來越大。你需要定期做一些清理，而且清理過程中你又不能直接一鍵清空，所以這是很麻煩的過程。

然后插件的管理 Jenkins 還有一個特別讓人頭疼的地方，就是它的插件升級。首先你在 Jenkins 登錄進去，然后就做插件升級。如果說我想臨時在一個新的環(huán)境里面，起一個 Jenkins 先測試一下或做一些調(diào)試可能每新建一個環(huán)境，都需要把這些插件升級一次。而且剛才我們說的在 Jenkins 里面做的所有配置，也都需要重新配置一遍，這是一個非常繁瑣的一個過程。
但是 Drone 這個工具它有一個特別好的地方，就是所有的插件都是 Docker 容器，比如說你在 pipeline 里用這個插件，你只要聲明用這個插件就可以了，你不用去自己管理把插件下載到哪里，然后怎么安裝，它這個一切都是全自動，只要說你網(wǎng)絡(luò)能把插件容器鏡像訪問到就可以了，這非常便利。
然后關(guān)于生態(tài)的構(gòu)建，Jenkins 的最大的優(yōu)勢就是它的插件非常多，就是你想用的各種東西都有，而且它基礎(chǔ)的底座非常好，你的插件可以實現(xiàn)的能力非常的強。比如說 pipeline 就是這種方式，它從 1.0 到 2.0 雖然有了，但是它完全是通過插件來實現(xiàn)的。但是現(xiàn)在 Jenkins 的發(fā)展又開始有點第二春的感覺。他開始對 Kuberentes 的支持力度明顯的加大了很多，首先從 JenkinsX 開始，它融合了一些 Kuberentes 生態(tài)相關(guān)的一些工具，比如 Harbor、Helm 它可以非常便利地在 Kuberentes 集群上來做一些構(gòu)建，并且把一些做服務(wù)的固化的一些編排文件放到 Helm 里面。
另外，現(xiàn)在它有一個新的子項目叫 config as code，也就是說他把所有 Jenkin 里面做了一些配置，都可以輸出成一個 code 的形式，就是對整個 Jenkins 的遷移，或者說復(fù)制都是一個很便利的改進。
講了那么多，實際上最后我們選擇的東西還是 Jenkins，因為最重要的是生態(tài)的構(gòu)建，他們已經(jīng)很好了。今天我們要講的在做一個彈性在 CI/CD 這個 Jenkins 上已經(jīng)有這個插件了，但是在 Drone 的社區(qū)里面，有人提這個事，但是現(xiàn)在還沒有看到。

CI/CD 的系統(tǒng)業(yè)務(wù)場景

然后我們看一下 CI/CD 它的系統(tǒng)的業(yè)務(wù)場景，它有一個比較典型的場景與特點，首先它面向開發(fā)人員，這是比較少見的，因為開發(fā)人員一般都比較挑剔一點。所以你要是這個系統(tǒng)做的不夠穩(wěn)健了，或者說響應(yīng)時間比較長一點的話，會被經(jīng)常吐槽。

然后就是有時效性要求，因為我們代碼寫完之后，往上提交，我們都不希望在這個代碼的構(gòu)建中一直排隊，我們希望馬上就開始進行構(gòu)建，并且資源足夠豐富。另外一個就是它的資源占用的波峰波谷是非常明顯的。就因為開發(fā)人員不可能時時刻刻都在提交代碼，有的人可能一天提交幾次，有的人會提交很多次。

因為我之前看過有一個分享，有一個人畫了一條反映自家公司構(gòu)建任務(wù)的曲線。他們公司大概是每天下午三、四點的時候代碼提交量最高，其他時間都比較平緩。這說明他們公司三、四點的時候，程序員提交代碼開始劃水了。然后隨著 CI/CD 資源地需求越來越高，構(gòu)建集群是一個必須要做的一件事情。就是提高負載能力，縮短任務(wù)的排隊時間。當然真正的集群有一個讓人覺得很不太好的地方，就是它的 Master 實際上只有一個，當然這個也可以通過插件來做改進。
但這不是今天我們要講的重點，因為很多時候 Master 短暫的不可用，然后能快速恢復(fù)也是可以接受的。然后另外它需要來滿足各種構(gòu)建場景。一個公司里面可能用到很多的開發(fā)環(huán)境，就像雖然我們都用 Java，但可能會有 1.5、1.6、1.7 的差別。 如果不用 Java，很可能用很多其他語言如 Python、Go、NodeJS 等需要很多的構(gòu)建環(huán)境。而且如果我們不引入容器的話，這些構(gòu)建環(huán)境不能重用，可能一臺主機只能給 PHP 在用。

容器可以給我們 CI/CD 系統(tǒng)來注入新的能力，就是環(huán)境隔離的能力。我們可以通過 Kubernetes 來為 CI/CD 系統(tǒng)注入更多的能力，然后矛盾點就出現(xiàn)了。開發(fā)人員總是希望 CI/CD 系統(tǒng)能夠快速地響應(yīng)代碼提交的一個事件，但是每個公司資源都不可能是無限的。因為就像上面提到的，如果每天下午三、四點的時候是一個代碼提交的高峰，這個時候可能需要 30 或 40 臺機器才能滿足構(gòu)建的任務(wù)。但是我不可能每天就開著 30 或 40 臺機器在這里，就為了每天下午三、四點，可能會構(gòu)建一、兩個小時。
Kubernetes 可以為 jenkins 注入新的能力，讓 CI/CD 系統(tǒng)實現(xiàn)彈性的能力。我們期望的目標是什么呢？有構(gòu)建任務(wù)的時候，可以自動為我們資源增加新的機器也好，或增加新的運計算能力也好，反正就是當我需要的時候，可以幫我自動地做一個資源擴張，但是同時也在我不需要的時候，可以自動把這些資源釋放掉。

我們期望的目標就是這樣，Kuberentes 就可以為 Jenkins 來做這樣的能力。Kuberentes 作為一個容器編排的系統(tǒng)，它所能提供的能力，它可以快速地彈出一些新的實例，并且把它們自動調(diào)度到空閑的機器上，做一個資源池，在資源池里面做一個調(diào)度，并且他執(zhí)行完任務(wù)之后，它可以做一個回收。而且如果把這 Jenkins Master 也部署在 Kuberentes 之上，它可以對 Master 做一個故障轉(zhuǎn)移，就是說如果我們系統(tǒng)可以容忍的話，Master 就算掛了，我可以快速把它調(diào)到另外一臺機器上，這個響應(yīng)時間不會很長。

Kubernetes-piugin

這里面也是用一個插件來實現(xiàn)，這個插件名字比較直接叫 Kuberentes-plugin，它這個插件所能提供的能力就是說，他直接管理一個 Kuberentes 集群，它在 Jenkins 里面安裝之后，它可以監(jiān)聽 Jenkins 的構(gòu)建任務(wù)。有構(gòu)建任務(wù)，在等待資源的時候，它就可以向 Kuberenetes 去申請一個新的資源，申請一個新的 Pod 去做自動地構(gòu)建完之后，它就會自動的清理。

先簡單介紹一下它的能力，因為這個插件安裝完之后，它對 pipeline 的語法也有一個改造,一會我們來看一下實例。但是就算到了這一步，還是不行的。首先，Kuberentes 的集群規(guī)劃還是一個問題。比說我有個集群有 30 個節(jié)點，真正的 master 部署在這上面，然后裝了那些插件，做了一個管理之后，我們可以發(fā)現(xiàn)來了一個新的任務(wù)，它就起一個新的 Pod，把這個構(gòu)建任務(wù)給執(zhí)行制定完。

執(zhí)行完之后，這 Pod 自動銷毀不占集群的資源。 平時我們可以在這集群上做一些別的任務(wù)，但這個終究還是有一點不好，就是我們這個集群到底規(guī)劃多大，并且這個集群我們平時不做構(gòu)建任務(wù)的時候，可以在上面做一些別的任務(wù)。但是如果正在做任務(wù)，突然來了一些構(gòu)建任務(wù)，它可能會出現(xiàn)資源的沖突問題。

Kubernetes Autoscaler

總的來說，還是有一些不完美的地方，那么我們可以利用 Kuberentes 一些比較沒那么常見的特性，來解決我們剛才說的這個問題。這兩個東西一個是叫 Autoscaler，一個叫 Virtual node。我們先看一下 Autoscaler，Autoscaler 是一個 Kubernetes 官方的一個組件。在 Kuberentes 的 group 下面支持三種能力:

• Cluster Autoscaler，可以對集群節(jié)點做自動伸縮；

• Vertical Pod Autoscaler，對集群的 Pod 豎直方向的資源伸縮。因為 Kuberentes 本身里面就帶著 HPA 可以做水平方向的 Pod 伸縮、節(jié)點數(shù)量的伸縮；這個特性還不是生產(chǎn)可用的特性；

• Addone Resizer，是 Kuberentes 上那些 addone 比如說 Ingress Controler、 DNS 可以根據(jù) Node 的數(shù)量來對資源的分配做調(diào)整。

Cluster autoscaler

我要講的是 Cluster autoscaler，是對集群 node 節(jié)點數(shù)量做一個擴縮容。 首先我們看一下，這個是在阿里云我們?nèi)萜鞣?wù)上所實現(xiàn)的 Autoscaler 的一個方式。我們看一下這個圖，這個是 HPA 和 Autoscler 做結(jié)合使用的一個場景。

HPA 監(jiān)聽監(jiān)控的事件時發(fā)現(xiàn)資源使用率上升到一定程度了之后，HPA 會自動通知 workload，來彈出一個新的 Pod，彈出一個新的 Pod，可能這時候集群資源就已經(jīng)不夠了，所以這個 Pod 可能就會 pending 在這里。它就會觸發(fā) Autoscaler 的事件，Autoscaler 就會根據(jù)我們之前配置好的 ESS 這個模板來去彈出來一臺新的 Node，然后自動地把 Node 加入到我們集群里面。 它是利用了 ESS 定制的模板功能，并且它可以支持多種的 Node 實例的類型，可以支持普通實例，支持 gpu，還有搶占式實例。

Virtual node

然后第二種是 Virtual node，Virtual node 實現(xiàn)方式是基于微軟開源的 Virtual Kubelet 這個項目。它做了一個虛擬的 Kubelet，然后向 Kubernetes 集群里面去注冊上面。但如果不太好理解的話，可以想象一下 MySQL proxy ，然后他把自己偽裝成一個MySQL server，然后后端可能管理著非常多的 MySQL server，并且它可以幫你自動的做一些 SQL 查詢的路由或者拼接。

Virtual kubelet 做的也是類似的工作，就是說它本身向著 Kubernetes 注冊說我是一個節(jié)點，但實際上它后端管理的可能是整個公有云上的非常多的資源，他可能對接公有云的一些 ECI 或者說對接的這些 VPC，這是一個它的大體的示意圖。

在阿里云上他們對接的是阿里云的 ECI 做一個彈性的容器實例，它響應(yīng)時間就非?？?，因為它不需要把 Node 去加入到集群里面，它是大概能夠到一分鐘一百個 Pod 左右這種性能。而且我們可以在 Pod 上聲明這種資源的使用情況，這是一個非?？斓捻憫?yīng)速度時間。

然后剛才說我們利用這兩種方式，就可以對我們 CI/CD 彈性的系統(tǒng)做出新的改造，我們不用非常早規(guī)劃好我們集群的規(guī)模，我們可以讓集群規(guī)模在需要的時候自動的做一些伸縮的動作。但是你做了這些動作之后，我們做了這些把真正的放在容器里面的這些動作之后，引入了一些新的門檻：docker-outside-of-docker 和 docker in docker。

我們在 Docker 中運行 Jenkins 時，通常有兩種方式，一個是把宿主機的 docker.sock 掛載到容器里面，讓 Jenkins 通過這個文件來和本機的 docker daemon 做一個通信，然后它在這里面做 docker build 構(gòu)建鏡像，或者把這些鏡像 push 到遠程的倉庫里面，所以它中間產(chǎn)生的所有鏡像都會堆積在本機上，這是一個問題。

在一些 serverless 的那些場景上使用，它就會有一些限制，因為 serverless 本身就不允許把 socket 文件給掛在進去。另外一個就是 docker in docker 這種方式，它的優(yōu)點就在于在容器里面它啟動一個新的 Docker daemon，它所有的中間產(chǎn)物、構(gòu)建產(chǎn)物隨著容器都一起銷毀，但是它有問題，它就是需要 privilege 的權(quán)限。

很多時候我們是盡量不要用它。另外一個就是說你做 docker build 的時候能在宿主機上做的時候，它如果有已經(jīng)有鏡像了，它會直接就使用這個鏡像，但是你用 docker in docker 這種方式來使用的，它每次都會重新拉進項，拉鏡像也是需要一定時間，這個取決于我們各個使用場景來判斷。

新的構(gòu)建工具——Kaniko

這時又引入了一個谷歌開源的新工具——Kaniko。它做的東西是 docker in docker 的方式。它有一個非常大的好處就是不依賴 Docker，而且所以它不需要 privilege 權(quán)限就可以在容器里面用用戶態(tài)的模式，來完全構(gòu)建 docker image。用戶態(tài)執(zhí)行 Dockerfile 的命令，它把這個鏡像完全構(gòu)建出來。

這算是一個比較期望的彈性的 CI/CD 系統(tǒng)。然后這個時候就是說從真正的節(jié)點到底層的計算資源全部是彈性擴縮的，而且滿足交付的需求，可以非常精細化地管理我們的資源。

Demo 演示

然后我們可以看一下 Demo 演示：

https://github.com/hymian/webdemo 這里是我準備好的一個例子，重點在這個 Jenkinsfile 文件，里面定義了agent 的 pod template，包含兩個容器，一個用來做 golang 的 build，一個用來做 image 的 build。
然后我們現(xiàn)在構(gòu)建它。開始構(gòu)建了，剛開始的，因為是現(xiàn)在我們在這環(huán)境里面只有一個，只有一個 master，所以他就是沒有不會有構(gòu)建節(jié)點。大家可以看到，它現(xiàn)在新啟動了一個 Pod，這個 Pod 是作為節(jié)點加進來的，但是因為我在這個 Pod 模板里面定義了一個 label，所以它沒有這個節(jié)點，所以它 Pod 狀態(tài)是 pending 的。所以我們在構(gòu)建日志里面顯示的這個是 agent 節(jié)點是離線的。 
但是我們在這個集群里面定義了一個彈性伸縮的一個東西，當沒有節(jié)點的時候，它會自動做一個新節(jié)點分配加入，可以看到有一個節(jié)點正在加入，這個我就可以稍等一下。就是說這段時間可能會有個一分鐘兩分鐘的時間。
節(jié)點不夠的時候，它可以自動擴容然后加入集群，這個要稍微等一下。因為這個時間會稍微久一點，是因為首先它觸發(fā)到我這個擴容，它有一個輪詢的時間差。整個過程下來可能有三分鐘左右。我看一下我這個服務(wù)器，這個服務(wù)器剛才是三個，現(xiàn)在這個服務(wù)器是剛剛加入了，這是搶占，這是我剛剛加入的一個東西。

這個是異常，是因為這個節(jié)點正在向集群加入，所以它顯示是異常，這是我們從命令行看一下，好，已經(jīng)是四個節(jié)點了，加了一個節(jié)點，這時候我們看 Pod，這時候在 agent 正在創(chuàng)建，這時候大家可能有一個小的細節(jié)，大家可以看一下，就是 0/3 是顯示 Pod，它有三個容器，但是我剛才在這個里面定義的，它實際上是 Pod 里面只有兩個容器，這就是我們剛才 PPT 上寫的一個地方。 
JNLP 那個容器，是 plugin 自動注入的一個容器，它通過這個容器實時的向 master 匯報構(gòu)建的一個中間的狀態(tài)，我把它的日志給發(fā)送出去。這個是 agent 的節(jié)點在初始化的一個過程一個事情這時候 slave節(jié)點已經(jīng)在運行了。我這邊已經(jīng)輸出完了，構(gòu)建完成。

上述內(nèi)容就是Kubernetes實踐彈性的CI/CD系統(tǒng)現(xiàn)狀分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

新聞標題：Kubernetes實踐彈性的CI/CD系統(tǒng)現(xiàn)狀分析
網(wǎng)頁鏈接：http://jinyejixie.com/article38/ggeesp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、企業(yè)網(wǎng)站制作、網(wǎng)站策劃、虛擬主機、自適應(yīng)網(wǎng)站、品牌網(wǎng)站設(shè)計

廣告

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