本篇內(nèi)容介紹了“web服務(wù)器分布式系統(tǒng)有什么特點(diǎn)”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)是專業(yè)的蕭縣網(wǎng)站建設(shè)公司，蕭縣接單;提供網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(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)隊(duì),希望更多企業(yè)前來合作!

分布式系統(tǒng)基礎(chǔ)知識(shí)

一個(gè)tomcat打天下的時(shí)代，不能說完全淘汰了，在一個(gè)管理系統(tǒng)，小型項(xiàng)目中還經(jīng)常使用，這并不過分，出于成本的考慮，這反而值得提倡。但如果要延伸到高并發(fā)場景下就必然要了解分布式系統(tǒng)：

分布式系統(tǒng)特點(diǎn)

分布式系統(tǒng)：一個(gè)硬件或軟件組件分布在不同的網(wǎng)絡(luò)計(jì)算機(jī)上，彼此之間僅僅通過消息傳遞進(jìn)行通信和協(xié)調(diào)的系統(tǒng)
這是分布式系統(tǒng)，在不同的硬件，不同的軟件，不同的網(wǎng)絡(luò)，不同的計(jì)算機(jī)上，僅僅通過消息來進(jìn)行通訊與協(xié)調(diào)
這是他的特點(diǎn)，更細(xì)致的看這些特點(diǎn)又可以有：分布性、對等性、并發(fā)性、缺乏全局時(shí)鐘、故障隨時(shí)會(huì)發(fā)生。

1. 分布性

既然是分布式系統(tǒng)，最顯著的特點(diǎn)肯定就是分布性，從簡單來看，如果我們做的是個(gè)電商項(xiàng)目，整個(gè)項(xiàng)目會(huì)分成不同的功能，專業(yè)點(diǎn)就不同的微服務(wù)，比如用戶微服務(wù)，產(chǎn)品微服務(wù)，訂單微服務(wù)，這些服務(wù)部署在不同的tomcat中，不同的服務(wù)器中，甚至不同的集群中，整個(gè)架構(gòu)都是分布在不同的地方的，在空間上是隨意的，而且隨時(shí)會(huì)增加，刪除服務(wù)器節(jié)點(diǎn)，這是第一個(gè)特性。

2. 對等性

對等性是分布式設(shè)計(jì)的一個(gè)目標(biāo)，還是以電商網(wǎng)站為例，來說明下什么是對等性，要完成一個(gè)分布式的系統(tǒng)架構(gòu)，肯定不是簡單的把一個(gè)大的單一系統(tǒng)拆分成一個(gè)個(gè)微服務(wù)，然后部署在不同的服務(wù)器集群就夠了，其中拆分完成的每一個(gè)微服務(wù)都有可能發(fā)現(xiàn)問題，而導(dǎo)致整個(gè)電商網(wǎng)站出現(xiàn)功能的丟失。
比如訂單服務(wù)，為了防止訂單服務(wù)出現(xiàn)問題，一般情況需要有一個(gè)備份，在訂單服務(wù)出現(xiàn)問題的時(shí)候能頂替原來的訂單服務(wù)。這就要求這兩個(gè)（或者2個(gè)以上）訂單服務(wù)完全是對等的，功能完全是一致的，其實(shí)這就是一種服務(wù)副本的冗余。
還一種是數(shù)據(jù)副本的冗余，比如數(shù)據(jù)庫，緩存等，再比如大數(shù)據(jù)HDFS中的三個(gè)副本，都和上面說的訂單服務(wù)一樣，為了安全考慮需要有完全一樣的備份存在，這就是對等性的意思。

3. 并發(fā)性

并發(fā)性其實(shí)對我們來說并不模式，在學(xué)習(xí)多線程的時(shí)候已經(jīng)或多或少學(xué)習(xí)過，多線程是并發(fā)的基礎(chǔ)。但是以前都是在一個(gè)JVM上實(shí)現(xiàn)的并發(fā)，但現(xiàn)在我們要接觸的不是多線程的角度，而是更高一層，從多進(jìn)程，多JVM的角度，例如在一個(gè)分布式系統(tǒng)中的多個(gè)節(jié)點(diǎn)，可能會(huì)并發(fā)地操作一些共享資源，如何準(zhǔn)確并高效的協(xié)調(diào)分布式并發(fā)操作。分布式鎖就是干這個(gè)事的。

4. 缺乏全局時(shí)鐘

在分布式系統(tǒng)中，節(jié)點(diǎn)是可能反正任意位置的，而每個(gè)位置，每個(gè)節(jié)點(diǎn)都有自己的時(shí)間系統(tǒng)，因此在分布式系統(tǒng)中，很難定義兩個(gè)事務(wù)糾結(jié)誰先誰后，原因就是因?yàn)槿狈σ粋€(gè)全局的時(shí)鐘序列進(jìn)行控制，當(dāng)然，現(xiàn)在這已經(jīng)不是什么大問題了，已經(jīng)有大把的時(shí)間服務(wù)器給系統(tǒng)調(diào)用

5. 故障隨時(shí)會(huì)發(fā)生

任何一個(gè)節(jié)點(diǎn)都可能出現(xiàn)停電，死機(jī)等現(xiàn)象，服務(wù)器集群越多，出現(xiàn)故障的可能性就越大，隨著集群數(shù)目的增加，出現(xiàn)故障甚至都會(huì)成為一種常態(tài)，怎么樣保證在系統(tǒng)出現(xiàn)故障，而系統(tǒng)還是正常的訪問者是作為系統(tǒng)搭建者應(yīng)該考慮的。

大型網(wǎng)站架構(gòu)圖

知道什么是分布式系統(tǒng)，接下來具體來看下大型網(wǎng)站架構(gòu)圖，首先整個(gè)架構(gòu)分成很多個(gè)層，應(yīng)用層，服務(wù)層，基礎(chǔ)設(shè)施層與數(shù)據(jù)服務(wù)層，每一層都由若干節(jié)點(diǎn)組成，這是典型的分布式架構(gòu)，后面一大把的時(shí)間就是系統(tǒng)的學(xué)習(xí)里面的每一個(gè)部分。

那么zookeeper在其中又是扮演什么角色呢，如果可以把zk扮演成交警的角色，而各個(gè)節(jié)點(diǎn)就是馬路上的各種汽車（汽車，公交車），為了保證整個(gè)交通（系統(tǒng)）的可用性，zookeeper必須知道每一節(jié)點(diǎn)的健康狀態(tài)（公交車是否出了問題，要派新的公交【服務(wù)注冊與發(fā)現(xiàn)】），公路在上下班高峰是否擁堵，在某一條很窄的路上只允許單獨(dú)一個(gè)方向的汽車通過【分布式鎖】。
如果交通警察是交通系統(tǒng)的指揮官，而zookeeper就是各個(gè)節(jié)點(diǎn)組成分布式系統(tǒng)的指揮官。

分布式系統(tǒng)問題

如果把分布式系統(tǒng)和平時(shí)的交通系統(tǒng)進(jìn)行對比，哪怕再穩(wěn)健的交通系統(tǒng)也會(huì)有交通事故，分布式系統(tǒng)也有很多需要攻克的問題，比如：通訊異常、網(wǎng)絡(luò)分區(qū)、三態(tài)、節(jié)點(diǎn)故障等。

1. 通信異常

通訊異常其實(shí)就是網(wǎng)絡(luò)異常，網(wǎng)絡(luò)系統(tǒng)本身是不可靠的，由于分布式系統(tǒng)需要通過網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳輸，網(wǎng)絡(luò)光纖，路由器等硬件難免出現(xiàn)問題。只要網(wǎng)絡(luò)出現(xiàn)問題，也就會(huì)影響消息的發(fā)送與接受過程，因此數(shù)據(jù)消息的丟失或者延長就會(huì)變得非常普遍。

2. 網(wǎng)絡(luò)分區(qū)

網(wǎng)絡(luò)分區(qū)，其實(shí)就是腦裂現(xiàn)象(參考Hadoop NameNode)，舉例來說：本來有一個(gè)交通警察，來管理整個(gè)片區(qū)的交通情況，一切井然有序，突然出現(xiàn)了停電，或者出現(xiàn)地震等自然災(zāi)難，某些道路接受不到交通警察的指令，可能在這種情況下，會(huì)出現(xiàn)一個(gè)零時(shí)工，片警來指揮交通。但注意，原來的交通警察其實(shí)還在，只是通訊系統(tǒng)中斷了，這時(shí)候就會(huì)出現(xiàn)問題了，在同一個(gè)片區(qū)的道路上有不同人在指揮，這樣必然引擎交通的阻塞混亂。這種由于種種問題導(dǎo)致同一個(gè)區(qū)域（分布式集群）有兩個(gè)相互沖突的負(fù)責(zé)人的時(shí)候就會(huì)出現(xiàn)這種精神分裂的情況，在這里稱為腦裂，也叫網(wǎng)絡(luò)分區(qū)。

3. 三態(tài)

三態(tài)是什么？三態(tài)其實(shí)就是成功，與失敗以外的第三種狀態(tài)，當(dāng)然，肯定不叫變態(tài)，而叫超時(shí)態(tài)。
在一個(gè)jvm中，應(yīng)用程序調(diào)用一個(gè)方法函數(shù)后會(huì)得到一個(gè)明確的相應(yīng)，要么成功，要么失敗，而在分布式系統(tǒng)中，雖然絕大多數(shù)情況下能夠接受到成功或者失敗的相應(yīng)，但一旦網(wǎng)絡(luò)出現(xiàn)異常，就非常有可能出現(xiàn)超時(shí)，當(dāng)出現(xiàn)這樣的超時(shí)現(xiàn)象，網(wǎng)絡(luò)通訊的發(fā)起方，是無法確定請求是否成功處理的。

4. 節(jié)點(diǎn)故障

這個(gè)其實(shí)前面已經(jīng)說過了，節(jié)點(diǎn)故障在分布式系統(tǒng)下是比較常見的問題，指的是組成服務(wù)器集群的節(jié)點(diǎn)會(huì)出現(xiàn)的宕機(jī)或僵死的現(xiàn)象，這種現(xiàn)象經(jīng)常會(huì)發(fā)生。

CAP 理論

前面說了分布式的特點(diǎn)以及會(huì)碰到很多會(huì)讓人頭疼的問題，這些問題肯定會(huì)有一定的理論思想來解決問題的。接下來花點(diǎn)時(shí)間來談?wù)勥@些理論，其中CAP和BASE理論是基礎(chǔ)，也是面試的時(shí)候經(jīng)常會(huì)問到的
首先看下CAP，CAP其實(shí)就是一致性，可用性，分區(qū)容錯(cuò)性這三個(gè)詞的縮寫

一致性

一致性是事務(wù)ACID的一個(gè)特性【原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）】。

這里講的一致性其實(shí)大同小異，只是現(xiàn)在考慮的是分布式環(huán)境中，還是不單一的數(shù)據(jù)庫。

在分布式系統(tǒng)中，一致性是數(shù)據(jù)在多個(gè)副本之間是否能夠保證一致的特性，這里說的一致性和前面說的對等性其實(shí)差不多。如果能夠在分布式系統(tǒng)中針對某一個(gè)數(shù)據(jù)項(xiàng)的變更成功執(zhí)行后，所有用戶都可以馬上讀取到最新的值，那么這樣的系統(tǒng)就被認(rèn)為具有強(qiáng)一致性。

可用性

可用性指系統(tǒng)提供服務(wù)必須一直處于可用狀態(tài)，對于用戶的操作請求總是能夠在有限的時(shí)間內(nèi)訪問結(jié)果。這里的重點(diǎn)是有限的時(shí)間和返回結(jié)果。為了做到有限的時(shí)間需要用到緩存，需要用到負(fù)載，這個(gè)時(shí)候服務(wù)器增加的節(jié)點(diǎn)是為性能考慮；

為了返回結(jié)果，需要考慮服務(wù)器主備，當(dāng)主節(jié)點(diǎn)出現(xiàn)問題的時(shí)候需要備份的節(jié)點(diǎn)能最快的頂替上來，千萬不能出現(xiàn)OutOfMemory或者其他500，404錯(cuò)誤，否則這樣的系統(tǒng)我們會(huì)認(rèn)為是不可用的。

分區(qū)容錯(cuò)性

分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然需要能夠?qū)ν馓峁M足一致性和可用性的服務(wù)，除非是整個(gè)網(wǎng)絡(luò)環(huán)境都發(fā)生了故障。不能出現(xiàn)腦裂的情況。

PS:

一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性這三個(gè)基本需求，最多只能同時(shí)滿足其中的兩項(xiàng)。設(shè)計(jì)者的精力往往就花在怎么樣根據(jù)業(yè)務(wù)場景在A和C直接尋求平衡；

BASE理論

根據(jù)前面的CAP理論，設(shè)計(jì)者應(yīng)該從一致性·和可用性之間找平衡，系統(tǒng)短時(shí)間完全不可用肯定是不允許的，那么根據(jù)CAP理論，在分布式環(huán)境下必然也無法做到強(qiáng)一致性。

BASE理論：

即使無法做到強(qiáng)一致性，但分布式系統(tǒng)可以根據(jù)自己的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終的一致性；

Basically Avaliable 基本可用

當(dāng)分布式系統(tǒng)出現(xiàn)不可預(yù)見的故障時(shí)，允許損失部分可用性，保障系統(tǒng)的基本可用；體現(xiàn)在時(shí)間上的損失和功能上的損失；

e.g：部分用戶雙十一高峰期淘寶頁面卡頓或降級(jí)處理；

Soft state 軟狀態(tài)

其實(shí)就是前面講到的三態(tài),既允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，既系統(tǒng)的不同節(jié)點(diǎn)的數(shù)據(jù)副本之間的數(shù)據(jù)同步過程存在延時(shí)，并認(rèn)為這種延時(shí)不會(huì)影響系統(tǒng)可用性；

e.g：12306網(wǎng)站賣火車票，請求會(huì)進(jìn)入排隊(duì)隊(duì)列；

Eventually consistent 最終一致性

所有的數(shù)據(jù)在經(jīng)過一段時(shí)間的數(shù)據(jù)同步后，最終能夠達(dá)到一個(gè)一致的狀態(tài)；

e.g：理財(cái)產(chǎn)品首頁充值總金額短時(shí)不一致；

常見名詞

服務(wù)雪崩

假設(shè)存在如下調(diào)用鏈

而此時(shí)，Service A的流量波動(dòng)很大，流量經(jīng)常會(huì)突然性增加！那么在這種情況下，就算Service A能扛得住請求，Service B和Service C未必能扛得住這突發(fā)的請求。
此時(shí)，如果Service C因?yàn)榭共蛔≌埱?，變得不可用。那?code>Service B的請求也會(huì)阻塞，慢慢耗盡Service B的線程資源，Service B就會(huì)變得不可用。緊接著，Service A也會(huì)不可用，這一過程如下圖所示

如上圖所示，一個(gè)服務(wù)失敗，導(dǎo)致整條鏈路的服務(wù)都失敗的情形，我們稱之為服務(wù)雪崩。

那么，服務(wù)熔斷和服務(wù)降級(jí)就可以視為解決服務(wù)雪崩的手段之一。

服務(wù)熔斷

服務(wù)熔斷：當(dāng)下游的服務(wù)因?yàn)槟撤N原因突然變得不可用或響應(yīng)過慢，上游服務(wù)為了保證自己整體服務(wù)的可用性，不再繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，快速釋放資源。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。
需要說明的是熔斷其實(shí)是一個(gè)框架級(jí)的處理，那么這套熔斷機(jī)制的設(shè)計(jì)，基本上業(yè)內(nèi)用的是斷路器模式，如Martin Fowler提供的狀態(tài)轉(zhuǎn)換圖如下所示

1. 最開始處于closed狀態(tài)，一旦檢測到錯(cuò)誤到達(dá)一定閾值，便轉(zhuǎn)為open狀態(tài)。

2. 這時(shí)候會(huì)有個(gè) reset timeout，到了這個(gè)時(shí)間了，會(huì)轉(zhuǎn)移到half open狀態(tài)。

3. 嘗試放行一部分請求到后端，一旦檢測成功便回歸到closed狀態(tài)，即恢復(fù)服務(wù)。

業(yè)內(nèi)目前流行的熔斷器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix，在Hystrix中，對應(yīng)配置如下

//滑動(dòng)窗口的大小，默認(rèn)為20
circuitBreaker.requestVolumeThreshold 
//過多長時(shí)間，熔斷器再次檢測是否開啟，默認(rèn)為5000，即5s鐘
circuitBreaker.sleepWindowInMilliseconds 
//錯(cuò)誤率，默認(rèn)50%
circuitBreaker.errorThresholdPercentage

每當(dāng)20個(gè)請求中，有50%失敗時(shí)，熔斷器就會(huì)打開，此時(shí)再調(diào)用此服務(wù)，將會(huì)直接返回失敗，不再調(diào)遠(yuǎn)程服務(wù)。直到5s之后，重新檢測該觸發(fā)條件，判斷是否把熔斷器關(guān)閉，或者繼續(xù)打開。

這些屬于框架層級(jí)的實(shí)現(xiàn)，我們只要實(shí)現(xiàn)對應(yīng)接口就好！

服務(wù)降級(jí)

什么是服務(wù)降級(jí)呢？這里有兩種場景:

1. 當(dāng)下游的服務(wù)因?yàn)槟撤N原因響應(yīng)過慢，下游服務(wù)主動(dòng)停掉一些不太重要的業(yè)務(wù)，釋放出服務(wù)器資源，增加響應(yīng)速度！

2. 當(dāng)下游的服務(wù)因?yàn)槟撤N原因不可用，上游主動(dòng)調(diào)用本地的一些降級(jí)邏輯，避免卡頓，迅速返回給用戶！

其實(shí)乍看之下，很多人還是不懂熔斷和降級(jí)的區(qū)別，其實(shí)應(yīng)該要這么理解:

1. 服務(wù)降級(jí)有很多種降級(jí)方式！如開關(guān)降級(jí)、限流降級(jí)、熔斷降級(jí)!

2. 服務(wù)熔斷屬于降級(jí)方式的一種！

可能有的人不服，覺得熔斷是熔斷、降級(jí)是降級(jí)，分明是兩回事啊！其實(shí)不然，因?yàn)閺膶?shí)現(xiàn)上來說，熔斷和降級(jí)必定是一起出現(xiàn)。因?yàn)楫?dāng)發(fā)生下游服務(wù)不可用的情況，這個(gè)時(shí)候?yàn)榱藢ψ罱K用戶負(fù)責(zé)，就需要進(jìn)入上游的降級(jí)邏輯了。因此，將熔斷降級(jí)視為降級(jí)方式的一種，也是可以說的通的！

撇開框架，以最簡單的代碼來說明！上游代碼如下

try{
   
   
   //調(diào)用下游的helloWorld服務(wù)xxRpc.helloWorld();}catch(Exception e){
   
   
   //因?yàn)槿蹟?，所以調(diào)不通doSomething();}

注意看，下游的helloWorld服務(wù)因?yàn)槿蹟喽{(diào)不通。此時(shí)上游服務(wù)就會(huì)進(jìn)入catch里頭的代碼塊，那么catch里頭執(zhí)行的邏輯，你就可以理解為降級(jí)邏輯！
什么，你跟我說你不捕捉異常，直接丟頁面？OK，那我甘拜下風(fēng)，當(dāng)我理解錯(cuò)誤!

服務(wù)降級(jí)大多是屬于一種業(yè)務(wù)級(jí)別的處理。當(dāng)然，我這里要講的是另一種降級(jí)方式，也就是開關(guān)降級(jí) 這也是我們生產(chǎn)上常用的另一種降級(jí)方式！

做法很簡單，做個(gè)開關(guān)，然后將開關(guān)放配置中心！在配置中心更改開關(guān)，決定哪些服務(wù)進(jìn)行降級(jí)。至于配置變動(dòng)后，應(yīng)用怎么監(jiān)控到配置發(fā)生了變動(dòng)，這就不是本文該討論的范圍。
那么，在應(yīng)用程序中部下開關(guān)的這個(gè)過程，業(yè)內(nèi)也有一個(gè)名詞，稱為埋點(diǎn)！

那接下來最關(guān)鍵的一個(gè)問題，哪些業(yè)務(wù)需要埋點(diǎn)？
一般有以下方法

1. 簡化執(zhí)行流程
   自己梳理出核心業(yè)務(wù)流程和非核心業(yè)務(wù)流程。然后在非核心業(yè)務(wù)流程上加上開關(guān)，一旦發(fā)現(xiàn)系統(tǒng)扛不住，關(guān)掉開關(guān)，結(jié)束這些次要流程。

2. 關(guān)閉次要功能
   一個(gè)微服務(wù)下肯定有很多功能，那自己區(qū)分出主要功能和次要功能。然后次要功能加上開關(guān)，需要降級(jí)的時(shí)候，把次要功能關(guān)了吧！

3. 降低一致性
   假設(shè)，你在業(yè)務(wù)上發(fā)現(xiàn)執(zhí)行流程沒法簡化了，愁??！也沒啥次要功能可以關(guān)了，桑心?。∧侵荒芙档鸵恢滦粤?，即將核心業(yè)務(wù)流程的同步改異步，將強(qiáng)一致性改最終一致性！

可是這些都是手動(dòng)降級(jí)，有辦法自動(dòng)降級(jí)么？
在生產(chǎn)上沒弄自動(dòng)降級(jí)！因?yàn)橐话阈枰导?jí)的場景，都是可以預(yù)見的，例如某某活動(dòng)。假設(shè)，平時(shí)真的有突發(fā)事件，流量異常，也有監(jiān)控系統(tǒng)發(fā)郵件通知，提醒我們?nèi)ソ导?jí)！
當(dāng)然，這并不代表自動(dòng)降級(jí)不能做，只是頭腦大概想了下，如果讓我來做自動(dòng)降級(jí)我會(huì)怎么實(shí)現(xiàn)：

1. 自己設(shè)一個(gè)閾值，例如幾秒內(nèi)失敗多少次，就啟動(dòng)降級(jí)

2. 自己做接口監(jiān)控(有興趣的可以了解一下Rxjava)，達(dá)到閾值就走推送邏輯。怎么推呢？比如你配置是放在git上，就用jgit去改配置中心的配置。如果配置放數(shù)據(jù)庫，就用jdbc去改。

3. 改完配置中心的配置后，應(yīng)用就可以自動(dòng)檢測到配置的變化，進(jìn)行降級(jí)！(這句不了解的，了解一下配置中心的熱刷新功能)

“web服務(wù)器分布式系統(tǒng)有什么特點(diǎn)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

名稱欄目：web服務(wù)器分布式系統(tǒng)有什么特點(diǎn)
文章路徑：http://sd-ha.com/article14/ghdege.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、電子商務(wù)、商城網(wǎng)站、關(guān)鍵詞優(yōu)化、手機(jī)網(wǎng)站建設(shè)、服務(wù)器托管

廣告

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