這篇文章主要講解了“Kubernetes網(wǎng)絡(luò)的四種場(chǎng)景是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“Kubernetes網(wǎng)絡(luò)的四種場(chǎng)景是什么”吧！

10多年的市中網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。營(yíng)銷(xiāo)型網(wǎng)站的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整市中建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)公司從事“市中網(wǎng)站設(shè)計(jì)”,“市中網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

在實(shí)際的業(yè)務(wù)場(chǎng)景中，業(yè)務(wù)組件之間的關(guān)系十分復(fù)雜，特別是微服務(wù)概念的提出，應(yīng)用部署的粒度更加細(xì)小和靈活。為了支持業(yè)務(wù)應(yīng)用組件的通信聯(lián)系，Kubernetes網(wǎng)絡(luò)的設(shè)計(jì)主要致力于解決以下場(chǎng)景：

(1)緊密耦合的容器到容器之間的直接通信;

(2)抽象的Pod到Pod之間的通信;

(3)Pod到Service之間的通信;

(4)集群外部與內(nèi)部組件之間的通信。

1. 容器到容器的通信

在同一個(gè)Pod內(nèi)的容器(Pod內(nèi)的容器是不會(huì)跨宿主機(jī)的)共享同一個(gè)網(wǎng)絡(luò)命名空間，共享同一個(gè)Linux協(xié)議棧。所以對(duì)于網(wǎng)絡(luò)的各類操作，就和它們?cè)谕慌_(tái)機(jī)器上一樣，它們甚至可以用localhost地址訪問(wèn)彼此的端口。這么做的結(jié)果是簡(jiǎn)單、安全和高效，也能減少將已經(jīng)存在的程序從物理機(jī)或者虛擬機(jī)移植到容器的難度。

如下圖中的陰影部分就是Node上運(yùn)行著的一個(gè)Pod實(shí)例。容器1和容器2共享了一個(gè)網(wǎng)絡(luò)的命名空間，共享一個(gè)命名空間的結(jié)果就是它們好像在一臺(tái)機(jī)器上運(yùn)行似的，它們打開(kāi)的端口不會(huì)有沖突，可以直接用Linux的本地IPC進(jìn)行通信。它們之間互相訪問(wèn)只需要使用localhost就可以。

容器到容器間通信

2. Pod之間的通信

每一個(gè)Pod都有一個(gè)真實(shí)的全局IP地址，同一個(gè)Node內(nèi)的不同Pod之間可以直接采用對(duì)房Pod的IP地址通信，而不需要使用其他發(fā)現(xiàn)機(jī)制，例如DNS、Consul或者etcd。Pod既有可能在同一個(gè)Node上運(yùn)行，也有可能在不用的Node上運(yùn)行，所以通信也分為兩類：同一個(gè)Node內(nèi)的Pod之間的通信和不同Node上的Pod之間的通信。

1)同一個(gè)Node內(nèi)的Pod之間的通信

如圖，可以看出，Pod1和Pod2都是通過(guò)Veth連接在同一個(gè)Docker0網(wǎng)橋上的，它們的IP地址IP1、IP2都是從Docker0的網(wǎng)段上自動(dòng)獲取的，它們和網(wǎng)橋本身的IP3是同一個(gè)網(wǎng)段的。另外，在Pod1、Pod2的Linux協(xié)議棧上，默認(rèn)路由都是Docker0的地址，也就是說(shuō)所有非本地的網(wǎng)絡(luò)數(shù)據(jù)，都會(huì)被默認(rèn)發(fā)送到Docker0網(wǎng)橋上，由Docker0網(wǎng)橋直接中轉(zhuǎn)，它們之間是可以直接通信的。

同一個(gè)Node內(nèi)的Pod關(guān)系

2)不同Node上的Pod之間的通信

Pod的地址是與Docker0在同一個(gè)網(wǎng)段內(nèi)的，我們知道Docker0網(wǎng)段與宿主機(jī)網(wǎng)卡是兩個(gè)完全不同的IP網(wǎng)段，并且不同Node之間的通信只能通過(guò)宿主機(jī)的物理網(wǎng)卡進(jìn)行，因此要想實(shí)現(xiàn)位于不同Node上的Pod容器之間的通信，就必須想辦法通過(guò)主機(jī)的這個(gè)IP地址來(lái)進(jìn)行尋址和通信。另外一方面，這些動(dòng)態(tài)分配且藏在Docker0之后的所謂“私有”IP地址也是可以找到的。Kubernetes會(huì)記錄所有正在運(yùn)行Pod的IP分配信息，并將這些信息保存在etcd中(作為Service的Endpoint)。這些私有IP信息對(duì)于Pod到Pod的通信也是十分重要的，因?yàn)槲覀兊木W(wǎng)絡(luò)模型要求Pod到Pod使用私有IP進(jìn)行通信。之前提到，Kubernetes的網(wǎng)絡(luò)對(duì)Pod的地址是平面的和直達(dá)的，所以這些Pod的IP規(guī)劃也很重要，不能有沖突。綜上所述，想要支持不同Node上的Pod之間的通信，就要達(dá)到兩個(gè)條件：

(1)在整個(gè)Kubernetes集群中對(duì)Pod分配進(jìn)行規(guī)劃，不能有沖突;

(2)找到一種辦法，將Pod的IP和所在Node的IP關(guān)聯(lián)起來(lái)，通過(guò)這個(gè)關(guān)聯(lián)讓Pod可以互相訪問(wèn)。

根據(jù)條件1的要求，我們需要在部署Kubernetes的時(shí)候，對(duì)Docker0的IP地址進(jìn)行規(guī)劃，保證每一個(gè)Node上的Docker0地址沒(méi)有沖突。我們可以在規(guī)劃后手工分配到每個(gè)Node上，或者做一個(gè)分配規(guī)則，由安裝的程序自己去分配占用。例如Kubernetes的網(wǎng)絡(luò)增強(qiáng)開(kāi)源軟件Flannel就能夠管理資源池的分配。

根據(jù)條件2的要求，Pod中的數(shù)據(jù)在發(fā)出時(shí)，需要有一個(gè)機(jī)制能夠知道對(duì)方Pod的IP地址掛在哪個(gè)具體的Node上。也就是說(shuō)要先找到Node對(duì)應(yīng)宿主機(jī)的IP地址，將數(shù)據(jù)發(fā)送到這個(gè)宿主機(jī)的網(wǎng)卡上，然后在宿主機(jī)上將相應(yīng)的數(shù)據(jù)轉(zhuǎn)到具體的Docker0上。一旦數(shù)據(jù)到達(dá)宿主機(jī)Node，則哪個(gè)Node內(nèi)部的Docker0便知道如何將數(shù)據(jù)發(fā)送到Pod。

具體情況，如下圖所示。

跨Node的Pod通信

在圖6中，IP1對(duì)應(yīng)的是Pod1，IP2對(duì)應(yīng)的是Pod2。Pod1在訪問(wèn)Pod2時(shí)，首先要將數(shù)據(jù)從源Node的eth0發(fā)送出去，找到并到達(dá)Node2的eth0。也就是說(shuō)先要從IP3到IP4，之后才是IP4到IP2的送達(dá)。

3. Pod 到Service之間的通信

為了支持集群的水平擴(kuò)展、高可用，Kubernetes抽象出Service的概念。Service是對(duì)一組Pod的抽象，它會(huì)根據(jù)訪問(wèn)策略(LB)來(lái)訪問(wèn)這組Pod。

Kubernetes在創(chuàng)建服務(wù)時(shí)會(huì)為服務(wù)分配一個(gè)虛擬的IP地址，客戶端通過(guò)訪問(wèn)這個(gè)虛擬的IP地址來(lái)訪問(wèn)服務(wù)，而服務(wù)則負(fù)責(zé)將請(qǐng)求轉(zhuǎn)發(fā)到后端的Pod上。這個(gè)類似于反向代理，但是，和普通的反向代理有一些不同：首先它的IP地址是虛擬的，想從外面訪問(wèn)需要一些技巧;其次是它的部署和啟停是Kubernetes統(tǒng)一自動(dòng)管理的。

Service在很多情況下只是一個(gè)概念，而真正將Service的作用落實(shí)的是背后的kube-proxy服務(wù)進(jìn)程。在Kubernetes集群的每個(gè)Node上都會(huì)運(yùn)行一個(gè)kube-proxy服務(wù)進(jìn)程，這個(gè)進(jìn)程可以看作Service的透明代理兼負(fù)載均衡器，其核心功能是將到某個(gè)Service的訪問(wèn)請(qǐng)求轉(zhuǎn)發(fā)到后端的多個(gè)Pod實(shí)例上。對(duì)每一個(gè)TCP類型的Kubernetes  Service，kube-proxy都會(huì)在本地Node上建立一個(gè)SocketServer來(lái)負(fù)責(zé)接收請(qǐng)求，然后均勻發(fā)送到后端某個(gè)Pod的端口上，這個(gè)過(guò)程默認(rèn)采用RoundRobin負(fù)載均衡算法。Kube-proxy和后端Pod的通信方式與標(biāo)準(zhǔn)的Pod到Pod的通信方式完全相同。另外，Kubernetes也提供通過(guò)修改Service的service.spec.-sessionAffinity參數(shù)的值來(lái)實(shí)現(xiàn)會(huì)話保持特性的定向轉(zhuǎn)發(fā)，如果設(shè)置的值為“ClientIP”，則將來(lái)自同一個(gè)ClientIP的請(qǐng)求都轉(zhuǎn)發(fā)到同一個(gè)后端Pod上。此外，Service的ClusterIP與NodePort等概念是kube-proxy通過(guò)Iptables和NAT轉(zhuǎn)換實(shí)現(xiàn)的，kube-proxy在運(yùn)行過(guò)程中動(dòng)態(tài)創(chuàng)建與Service相關(guān)的Iptables規(guī)則，這些規(guī)則實(shí)現(xiàn)了ClusterIP及NodePort的請(qǐng)求流量重定向到kube-proxy進(jìn)程上對(duì)應(yīng)服務(wù)的代理端口的功能。由于Iptables機(jī)制針對(duì)的是本地的kube-proxy端口，所以如果Pod需要訪問(wèn)Service，則它所在的那個(gè)Node上必須運(yùn)行kube-proxy，并且在每個(gè)Kubernetes的Node上都會(huì)運(yùn)行kube-proxy組件。在Kubernetes集群內(nèi)部，對(duì)Service  Cluster IP和Port的訪問(wèn)可以在任意Node上進(jìn)行，這個(gè)因?yàn)槊總€(gè)Node上的kube-proxy針對(duì)該Service都設(shè)置了相同的轉(zhuǎn)發(fā)規(guī)則。

綜上所述，由于kube-proxy的作用，在Service的調(diào)用過(guò)程中客戶端無(wú)需關(guān)心后端有幾個(gè)Pod，中間過(guò)程的通信、負(fù)載均衡及故障恢復(fù)都是透明的，如下圖所示。

Service的負(fù)載均衡轉(zhuǎn)發(fā)

訪問(wèn)Service的請(qǐng)求，不論是用Cluster IP+Target Port的方式，還是用節(jié)點(diǎn)機(jī)IP+Node  Port的方式，都會(huì)被節(jié)點(diǎn)機(jī)的Iptables規(guī)則重定向到kube-proxy監(jiān)聽(tīng)Service服務(wù)代理端口。Kube-proxy接收到Service的訪問(wèn)請(qǐng)求后，會(huì)如何選擇后端Pod?

首先，目前kube-proxy的負(fù)載均衡只支持Round  Robin算法。該算法按照成員列表逐個(gè)選取成員，如果一輪循環(huán)完，便從頭開(kāi)始下一輪，如此循環(huán)往復(fù)。Kube-proxy的負(fù)載均衡器在Round  Robin算法的基礎(chǔ)上還支持Session保持。如果Service在定義中指定了Session保持，則kube-proxy接收請(qǐng)求時(shí)會(huì)從本地內(nèi)存中查找是否存在來(lái)自該請(qǐng)求IP的affinityState對(duì)象，如果存在該對(duì)象，且Session沒(méi)有超時(shí)，則kube-proxy將請(qǐng)求轉(zhuǎn)向該affinityState所指向的后端Pod。如果本地存在沒(méi)有來(lái)自該請(qǐng)求IP的affinityState對(duì)象，記錄請(qǐng)求的IP和指向的Endpoint。后面的請(qǐng)求就會(huì)粘連到這個(gè)創(chuàng)建好的affinityState對(duì)象上，這就實(shí)現(xiàn)了客戶端IP會(huì)話保持的功能。

接下來(lái)我們深入分析kube-proxy的實(shí)現(xiàn)細(xì)節(jié)。kube-proxy進(jìn)程為每個(gè)Service都建立了一個(gè)“服務(wù)代理對(duì)象”，服務(wù)代理對(duì)象是kube-proxy程序內(nèi)部的一種數(shù)據(jù)結(jié)構(gòu)，它包括一個(gè)用于監(jiān)聽(tīng)此服務(wù)請(qǐng)求的Socket-Server，SocketServer的端口是隨機(jī)選擇的一個(gè)本地空閑端口。此外，kube-proxy內(nèi)部也建立了一個(gè)“負(fù)載均衡器組件”，用來(lái)實(shí)現(xiàn)SocketServer上收到的連接到后端多個(gè)Pod連接之間的負(fù)載均衡和會(huì)話保持能力。

kube-proxy通過(guò)查詢和監(jiān)聽(tīng)API  Server中Service與Endpoint的變化來(lái)實(shí)現(xiàn)其主要功能，包括為新創(chuàng)建的Service打開(kāi)一個(gè)本地代理對(duì)象(代理對(duì)象是kube-proxy程序內(nèi)部的一種數(shù)據(jù)結(jié)構(gòu)，一個(gè)Service端口是一個(gè)代理對(duì)象，包括一個(gè)用于監(jiān)聽(tīng)的服務(wù)請(qǐng)求的SocketServer)，接收請(qǐng)求，針對(duì)發(fā)生變化的Service列表，kube-proxy會(huì)逐個(gè)處理。下面是具體的處理流程：

(1)如果該Service沒(méi)有設(shè)置集群IP(ClusterIP)，則不做任何處理，否則，獲取該Service的所有端口定義列表(spec.ports域)

(2)逐個(gè)讀取服務(wù)端口定義列表中的端口信息，根據(jù)端口名稱、Service名稱和Namespace判斷本地是否已經(jīng)存在對(duì)應(yīng)的服務(wù)代理對(duì)象，如果不存在就新建，如果存在且Service端口被修改過(guò)，則先刪除Iptables中和該Service相關(guān)的的規(guī)則，關(guān)閉服務(wù)代理對(duì)象，然后走新建流程，即為該Service端口分配服務(wù)代理對(duì)象并為該Service創(chuàng)建相關(guān)的Iptables規(guī)則。

(3)更新負(fù)載均衡器組件中對(duì)應(yīng)Service的轉(zhuǎn)發(fā)地址表，對(duì)于新建的Service，確定轉(zhuǎn)發(fā)時(shí)的會(huì)話保持策略。

(4)對(duì)于已經(jīng)刪除的Service則進(jìn)行清理。

Kube-proxy與APIServer的交互過(guò)程

4. 外部到內(nèi)部的訪問(wèn)

Pod作為基本的資源對(duì)象，除了會(huì)被集群內(nèi)部的Pod訪問(wèn)，也會(huì)被外部使用。服務(wù)是對(duì)一組功能相同Pod的抽象，以它為單位對(duì)外提供服務(wù)是最合適的粒度。

由于Service對(duì)象在Cluster IP  Range池中分配到的IP只能在內(nèi)部訪問(wèn)，所以其他Pod都可以無(wú)障礙地訪問(wèn)到它。但如果這個(gè)Service作為前端服務(wù)，準(zhǔn)備為集群外的客戶端提供服務(wù)，就需要外部能夠看到它。

Kubernetes支持兩種對(duì)外服務(wù)的Service的Type定義：NodePort和LoadBalancer。

(1)NodePort

在定義Service時(shí)指定spec.type=NodePort，并指定spec.ports.nodePort的值，系統(tǒng)就會(huì)在Kubernetes集群中的每個(gè)Node上打開(kāi)一個(gè)主機(jī)上的真實(shí)端口號(hào)。這樣，能夠訪問(wèn)Node的客戶端就能通過(guò)這個(gè)端口號(hào)訪問(wèn)到內(nèi)部的Service了。

(2)LoadBalancer

如果云服務(wù)商支持外接負(fù)載均衡器，則可以通過(guò)spec.type=LoadBalancer定義Service，同時(shí)需要指定負(fù)載均衡器的IP地址。使用這種類型需要指定Service的NodePort和ClusterIP。

對(duì)于這個(gè)Service的訪問(wèn)請(qǐng)求將會(huì)通過(guò)LoadBalancer轉(zhuǎn)發(fā)到后端Pod上去，負(fù)載分發(fā)的實(shí)現(xiàn)方式依賴于云服務(wù)商提供的LoadBalancer的實(shí)現(xiàn)機(jī)制。

(3)外部訪問(wèn)內(nèi)部Service原理

我們從集群外部訪問(wèn)集群內(nèi)部，最終都是落在具體的Pod上。通過(guò)NodePort的方式就是將kube-proxy開(kāi)放出去，利用Iptables為服務(wù)的NodePort設(shè)置規(guī)則，將對(duì)Service的訪問(wèn)轉(zhuǎn)到kube-proxy上，這樣kube-proxy就可以使用和內(nèi)部Pod訪問(wèn)服務(wù)一樣的方式來(lái)訪問(wèn)后端的一組Pod了。這種模式就是利用kube-proxy作為負(fù)載均衡器，處理外部到服務(wù)進(jìn)一步到Pod的訪問(wèn)。而更常用的是外部均衡器模式。通常的實(shí)現(xiàn)是使用一個(gè)外部的負(fù)載均衡器，這些均衡器面向集群內(nèi)的所有節(jié)點(diǎn)。當(dāng)網(wǎng)絡(luò)流量發(fā)送到LoadBalancer地址時(shí)，它會(huì)識(shí)別出這是某個(gè)服務(wù)的一部分，然后路由到合適的后端Pod。

所以從外面訪問(wèn)內(nèi)部的Pod資源，就有了很多種不同的組合。

• 外面沒(méi)有負(fù)載均衡器，直接訪問(wèn)內(nèi)部的Pod

• 外面沒(méi)有負(fù)載均衡器，直接通過(guò)訪問(wèn)內(nèi)部的負(fù)載均衡器來(lái)訪問(wèn)Pod

• 外面有負(fù)載均衡器，通過(guò)外部負(fù)載均衡器直接訪問(wèn)內(nèi)部的Pod

• 外面有負(fù)載均衡器，通過(guò)訪問(wèn)內(nèi)部的負(fù)載均衡器來(lái)訪問(wèn)內(nèi)部的Pod

第一種情況的場(chǎng)景十分少見(jiàn)，只是在特殊的時(shí)候才需要。我們?cè)趯?shí)際的生產(chǎn)項(xiàng)目中需要逐一訪問(wèn)啟動(dòng)的Pod，給它們發(fā)送一個(gè)刷新指令。只有這種情況下才使用這種方式。這需要開(kāi)發(fā)額外的程序，讀取Service下的Endpoint列表，逐一和這些Pod進(jìn)行通信。通常要避免這種通信方式，例如可以采取每個(gè)Pod從集中的數(shù)據(jù)源拉命令的方式，而不是采取推命令給它的方式來(lái)避免。因?yàn)榫唧w到每個(gè)Pod的啟停本來(lái)就是動(dòng)態(tài)的，如果依賴了具體的Pod們就相當(dāng)于繞開(kāi)了Kubernetes的Service機(jī)制，雖然能夠?qū)崿F(xiàn)，但是不理想。

第二種情況就是NodePort的方式，外部的應(yīng)用直接訪問(wèn)Service的NodePort，并通過(guò)Kube-proxy這個(gè)負(fù)載均衡器訪問(wèn)內(nèi)部的Pod。

第三種情況是LoadBalancer模式，因?yàn)橥獠康腖oadBalancer是具備Kubernetes知識(shí)的負(fù)載均衡器，它會(huì)去監(jiān)聽(tīng)Service的創(chuàng)建，從而知曉后端的Pod啟停變化，所以它有能力和后端的Pod進(jìn)行通信。但是這里有個(gè)問(wèn)題需要注意，那就是這個(gè)負(fù)載均衡器需要有辦法直接和Pod進(jìn)行通信。也就是說(shuō)要求這個(gè)外部的負(fù)載均衡器使用和Pod到Pod一樣的通信機(jī)制。

第四種情況也很少使用，因?yàn)樾枰?jīng)歷兩級(jí)的負(fù)載均衡設(shè)備，而且網(wǎng)絡(luò)的調(diào)用被兩次隨機(jī)負(fù)載均衡后，更難跟蹤了。在實(shí)際生產(chǎn)環(huán)境中出了問(wèn)題排錯(cuò)時(shí)，很難跟蹤網(wǎng)絡(luò)數(shù)據(jù)的流動(dòng)過(guò)程。

(4)外部硬件負(fù)載均衡器模式

在很多實(shí)際的生產(chǎn)環(huán)境中，由于是在私有云環(huán)境中部署Kubernetes集群，所以傳統(tǒng)的負(fù)載均衡器都對(duì)Service無(wú)感知。實(shí)際上我們只需要解決兩個(gè)問(wèn)題，就可以將它變成Service可感知的負(fù)載均衡器，這也是實(shí)際系統(tǒng)中理想的外部訪問(wèn)Kubernetes集群內(nèi)部的模式。

• 通過(guò)寫(xiě)一個(gè)程序來(lái)監(jiān)聽(tīng)Service的變化，將變化按照負(fù)載均衡器的通信接口，作為規(guī)則寫(xiě)入負(fù)載均衡器。

• 給負(fù)載均衡器提供直接訪問(wèn)Pod的通信手段。

如下圖，說(shuō)明了這個(gè)過(guò)程。

自定義外部負(fù)載均衡器訪問(wèn)Service

這里提供了一個(gè)Service Agent來(lái)實(shí)現(xiàn)Service變化的感知。該Agent能夠直接從etcd中或者通過(guò)接口調(diào)用API  Server來(lái)監(jiān)控Service及Endpoint的變化，并將變化寫(xiě)入外部的硬件負(fù)載均衡器中。

同時(shí)，每臺(tái)Node上都運(yùn)行著有路由發(fā)現(xiàn)協(xié)議的軟件，該軟件負(fù)責(zé)將這個(gè)Node上所有的地址通過(guò)路由發(fā)現(xiàn)協(xié)議組播給網(wǎng)絡(luò)內(nèi)的其他主機(jī)，當(dāng)然也包含硬件負(fù)載均衡器。這樣硬件負(fù)載均衡器就能知道每個(gè)Pod實(shí)例的IP地址是在哪臺(tái)Node上了。通過(guò)上述兩個(gè)步驟，就建立起一個(gè)基于硬件的外部可感知Service的負(fù)載均衡器。

感謝各位的閱讀，以上就是“Kubernetes網(wǎng)絡(luò)的四種場(chǎng)景是什么”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)Kubernetes網(wǎng)絡(luò)的四種場(chǎng)景是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

分享標(biāo)題：Kubernetes網(wǎng)絡(luò)的四種場(chǎng)景是什么
文章分享：http://vcdvsql.cn/article44/jhehee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)公司、全網(wǎng)營(yíng)銷(xiāo)推廣、域名注冊(cè)、微信小程序、用戶體驗(yàn)

廣告

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