Istio使用過(guò)程中出現(xiàn)的問(wèn)題怎么解決

157次閱讀

共計(jì) 11074 個(gè)字符，預(yù)計(jì)需要花費(fèi) 28 分鐘才能閱讀完成。

今天丸趣 TV 小編給大家分享一下 Istio 使用過(guò)程中出現(xiàn)的問(wèn)題怎么解決的相關(guān)知識(shí)點(diǎn)，內(nèi)容詳細(xì)，邏輯清晰，相信大部分人都還太了解這方面的知識(shí)，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來(lái)了解一下吧。

失敗的 Eureka 心跳通知

在上一篇文章中，我們介紹了 Headless Service 和普通 Service 的區(qū)別。由于 Headless Service 的特殊性，在 Istio 下發(fā)給 Envoy Sidecar 的配置中，此類服務(wù)的配置參數(shù)和其他服務(wù)的參數(shù)有所不同。除了我們上次遇到的 mTLS 故障之外，這些差異可能還會(huì)導(dǎo)致應(yīng)用出現(xiàn)一些其他意想不到的情況。

這次遇到的問(wèn)題現(xiàn)象是：在 Spring Cloud 應(yīng)用遷移到 Istio 中后，服務(wù)提供者向 Eureka Server 發(fā)送心跳失敗。

備注：Eureka Server 采用心跳機(jī)制來(lái)判定服務(wù)的健康狀態(tài)。服務(wù)提供者在啟動(dòng)后，周期性（默認(rèn) 30 秒）向 Eureka Server 發(fā)送心跳，以證明當(dāng)前服務(wù)是可用狀態(tài)。Eureka Server 在一定的時(shí)間（默認(rèn) 90 秒）未收到客戶端的心跳，則認(rèn)為服務(wù)宕機(jī)，注銷該實(shí)例。

查看應(yīng)用程序日志，可以看到 Eureka 客戶端發(fā)送心跳失敗的相關(guān)日志信息。

2020-09-24 13:32:46.533 ERROR 1 --- [tbeatExecutor-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client - was unable to send heartbeat!
com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
 at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:112) ~[eureka-client-1.9.13.jar!/:1.9.13]
 at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.13.jar!/:1.9.13]
 at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$3.execute(EurekaHttpClientDecorator.java:92) ~[eureka-client-1.9.13.jar!/:1.9.13]
 at com.netflix.discovery.shared.transport.decorator.SessionedEurekaHttpClient.execute(SessionedEurekaHttpClient.java:77) ~[eureka-client-1.9.13.jar!/:1.9.13]
 at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.13.jar!/:1.9.13]
 at com.netflix.discovery.DiscoveryClient.renew(DiscoveryClient.java:864) ~[eureka-client-1.9.13.jar!/:1.9.13]
 at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1423) ~[eureka-client-1.9.13.jar!/:1.9.13]
 at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[na:na]
 at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
 at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
 at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
 at java.base/java.lang.Thread.run(Thread.java:832) ~[na:na]

過(guò)期的 IP 地址

對(duì)于請(qǐng)求失敗類的故障，我們首先可以通過(guò) Envoy 的訪問(wèn)日志查看失敗原因。通過(guò)下面的命令查看客戶端 Envoy Sidecar 的日志：

k logs -f eureka-client-66f748f84f-vvvmz -c eureka-client -n eureka

從 Envoy 日志中可以查看到客戶端通過(guò) HTTP PUT 向服務(wù)器發(fā)出的心跳請(qǐng)求。該請(qǐng)求的 Response 狀態(tài)碼為 UF,URX，表示其 Upstream Failure，即連接上游服務(wù)失敗。在日志中還可以看到，在連接失敗后，Envoy 向客戶端應(yīng)用返回了一個(gè) 503 HTTP 錯(cuò)誤碼。

[2020-09-24T13:31:37.980Z]  PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP lastDirtyTimestamp=1600954114925 HTTP/1.1  503 UF,URX  -   -  0 91 3037 -  -   Java-EurekaClient/v1.9.13   1cd54507-3f93-4ff3-a93e-35ead11da70f   eureka-server:8761   172.16.0.198:8761  outbound|8761||eureka-server.eureka.svc.cluster.local - 172.16.0.198:8761 172.16.0.169:53890 - default

從日志中可以看到訪問(wèn)的 Upstream Cluster 是 outbound|8761||eureka-server.eureka.svc.cluster.local，Envoy 將該請(qǐng)求轉(zhuǎn)發(fā)到了 IP 地址為 172.16.0.198 的 Upstream Host。

查看集群中部署的服務(wù)，可以看到 eureka-server 是一個(gè) Headless Service。

HUABINGZHAO-MB0:eureka-istio-test huabingzhao$ k get svc -n eureka -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
eureka-server ClusterIP None  none  8761/TCP 17m app=eureka-server

在本系列的上一篇文章『Istio 運(yùn)維實(shí)戰(zhàn)系列（2）：讓人頭大的『無(wú)頭服務(wù)』- 上』中，我們了解到 Headless Service 并沒(méi)有 Cluster IP，DNS 會(huì)直接將 Service 名稱解析到 Service 后端的多個(gè) Pod IP 上。Envoy 日志中顯示連接 Eureka Server 地址 172.16.0.198 失敗，我們來(lái)看看這個(gè) IP 來(lái)自哪一個(gè) Eureka Server 的 Pod。

HUABINGZHAO-MB0:eureka-istio-test huabingzhao$ k get pod -n eureka -o wide | grep eureka-server
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
eureka-server-0 1/1 Running 0 6h65m 172.16.0.59 10.0.0.15  none   none 
eureka-server-1 1/1 Running 0 6m1s 172.16.0.200 10.0.0.7  none   none 
eureka-server-2 1/1 Running 0 6h66m 172.16.1.3 10.0.0.14  none   none

從上面的命令輸出中可以看到 Eureka 集群中有三個(gè)服務(wù)器，但沒(méi)有哪一個(gè)服務(wù)器的 Pod IP 是 Envoy 日志中顯示的 172.16.0.198。進(jìn)一步分析發(fā)現(xiàn) eureka-server-1 Pod 的啟動(dòng)時(shí)間比客戶端的啟動(dòng)時(shí)間晚很多，初步懷疑 Envoy 采用了一個(gè)已經(jīng)被銷毀的 Eureka Server 的 IP 進(jìn)行訪問(wèn)，導(dǎo)致訪問(wèn)失敗。

通過(guò)查看 Envoy dump 文件中 outbound|8761||eureka-server.eureka.svc.cluster.local 的相關(guān)配置，進(jìn)一步加深了我對(duì)此的懷疑。從下面的 yaml 片段中可以看到該 Cluster 的類型為“ORIGINAL_DST”。

{
  version_info :  2020-09-23T03:57:03Z/27 ,
  cluster : {
  @type :  type.googleapis.com/envoy.api.v2.Cluster ,
  name :  outbound|8761||eureka-server.eureka.svc.cluster.local ,
  type :  ORIGINAL_DST , #  該選項(xiàng)表明  Enovy  在轉(zhuǎn)發(fā)請(qǐng)求時(shí)會(huì)直接采用  downstream  原始請(qǐng)求中的地址。  connect_timeout :  1s ,
  lb_policy :  CLUSTER_PROVIDED ,
 ...
}

根據(jù) Envoy 的文檔說(shuō)明，“ORIGINAL_DST”的解釋為：

In these cases requests routed to an original destination cluster are forwarded to upstream hosts as addressed by the redirection metadata, without any explicit host configuration or upstream host discovery.

即對(duì)于“ORIGINAL_DST”類型的 Cluster，Envoy 在轉(zhuǎn)發(fā)請(qǐng)求時(shí)會(huì)直接采用 downstream 請(qǐng)求中的原始目的地 IP 地址，而不會(huì)采用服務(wù)發(fā)現(xiàn)機(jī)制。Istio 中 Envoy Sidecar 的該處理方式和 K8s 對(duì) Headless Service 的處理是類似的，即由客戶端根據(jù) DNS 直接選擇一個(gè)后端的 Pod IP，不會(huì)采用負(fù)載均衡算法對(duì)客戶端的請(qǐng)求進(jìn)行重定向分發(fā)。但讓人疑惑的是：為什么客戶端通過(guò) DNS 查詢得到的 Pod 地址 172.16.0.198 訪問(wèn)失敗了呢？這是由于客戶端查詢 DNS 時(shí)得到的地址在訪問(wèn)期間已經(jīng)不存在了。下圖解釋了導(dǎo)致該問(wèn)題的原因：

Client 查詢 DNS 得到 eureka-server 的三個(gè) IP 地址。

Client 選擇 Server-1 的 IP 172.16.0.198 發(fā)起連接請(qǐng)求，請(qǐng)求被 iptables rules 攔截并重定向到了客戶端 Pod 中 Envoy 的 VirtualInbound 端口 15001。

在收到 Client 的連接請(qǐng)求后，根據(jù) Cluster 的配置，Envoy 采用請(qǐng)求中的原始目的地址 172.16.0.198 連接 Server-1，此時(shí)該 IP 對(duì)應(yīng)的 Pod 是存在的，因此 Envoy 到 Server-1 的鏈接創(chuàng)建成功，Client 和 Envoy 之間的鏈接也會(huì)建立成功。Client 在創(chuàng)建鏈接時(shí)采用了 HTTP Keep Alive 選項(xiàng)，因此 Client 會(huì)一直保持該鏈接，并通過(guò)該鏈接以 30 秒間隔持續(xù)發(fā)送 HTTP PUT 服務(wù)心跳通知。

由于某些原因，該 Server-1 Pod 被 K8s 重建為 Server-1?，IP 發(fā)生了變化。

當(dāng) Server-1 的 IP 變化后，Envoy 并不會(huì)立即主動(dòng)斷開(kāi)和 Client 端的鏈接。此時(shí)從 Client 的角度來(lái)看，到 172.16.0.198 的 TCP 鏈接依然是正常的，因此 Client 會(huì)繼續(xù)使用該鏈接發(fā)送 HTTP 請(qǐng)求。同時(shí)由于 Cluster 類型為“ORIGINAL_DST”，Envoy 會(huì)繼續(xù)嘗試連接 Client 請(qǐng)求中的原始目的地址 172.16.0.198，如圖中藍(lán)色箭頭所示。但是由于該 IP 上的 Pod 已經(jīng)被銷毀，Envoy 會(huì)連接失敗，并在失敗后向 Client 端返回一個(gè)這樣的錯(cuò)誤信息：“upstream connect error or disconnect/reset before headers. reset reason: connection failure HTTP/1.1 503”。如果 Client 在收到該錯(cuò)誤后不立即斷開(kāi)并重建鏈接，那么直到該鏈接超時(shí)之前，Client 都不會(huì)重新查詢 DNS 獲取到 Pod 重建后的正確地址。

為 Headless Service 啟用 EDS

從前面的分析中我們已經(jīng)知道出錯(cuò)的原因是由于客戶端 HTTP 長(zhǎng)鏈接中的 IP 地址過(guò)期導(dǎo)致的。那么一個(gè)最直接的想法就是讓 Envoy 采用正確的 IP 地址去連接 Upstream Host。在不修改客戶端代碼，不重建客戶端鏈接的情況下，如何才能實(shí)現(xiàn)呢？

如果對(duì)比一個(gè)其他服務(wù)的 Cluster 配置，可以看到正常情況下，Istio 下發(fā)的配置中，Cluster 類型為 EDS（Endopoint Discovery Service），如下面的 yaml 片段所示：

 {
  version_info :  2020-09-23T03:02:01Z/2 ,
  cluster : {
  @type :  type.googleapis.com/envoy.config.cluster.v3.Cluster ,
  name :  outbound|8080||http-server.default.svc.cluster.local ,
  type :  EDS , #  普通服務(wù)采用  EDS  服務(wù)發(fā)現(xiàn)，根據(jù)  LB  算法從  EDS  下發(fā)的  endpoint  中選擇一個(gè)進(jìn)行連接
  eds_cluster_config : {
  eds_config : {  ads : {},
  resource_api_version :  V3 
 },
  service_name :  outbound|8080||http-server.default.svc.cluster.local 
 },
 ...
 }

在采用 EDS 的情況下，Envoy 會(huì)通過(guò) EDS 獲取到該 Cluster 中所有可用的 Endpoint，并根據(jù)負(fù)載均衡算法（缺省為 Round Robin）將 Downstream 發(fā)來(lái)的請(qǐng)求發(fā)送到不同的 Endpoint。因此只要把 Cluster 類型改為 EDS，Envoy 在轉(zhuǎn)發(fā)請(qǐng)求時(shí)就不會(huì)再采用請(qǐng)求中錯(cuò)誤的原始 IP 地址，而會(huì)采用 EDS 自動(dòng)發(fā)現(xiàn)到的 Endpoint 地址。采用 EDS 的情況下，本例的中的訪問(wèn)流程如下圖所示：

通過(guò)查閱 Istio 源碼，可以發(fā)現(xiàn) Istio 對(duì)于 Headless Service 缺省采用了 ORIGINAL_DST 類型的 Cluster，但我們也可以通過(guò)設(shè)置一個(gè) Istiod 的環(huán)境變量 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 為 Headless Service 強(qiáng)制啟用 EDS。

func convertResolution(proxy *model.Proxy, service *model.Service) cluster.Cluster_DiscoveryType {
 switch service.Resolution {
 case model.ClientSideLB:
 return cluster.Cluster_EDS
 case model.DNSLB:
 return cluster.Cluster_STRICT_DNS
 case model.Passthrough: // Headless Service  的取值為  model.Passthrough
 if proxy.Type == model.SidecarProxy {
 //  對(duì)于  Sidecar Proxy，如果  PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES  的值設(shè)為  True，則啟用  EDS，否則采用  ORIGINAL_DST
 if service.Attributes.ServiceRegistry == string(serviceregistry.Kubernetes)   features.EnableEDSForHeadless {
 return cluster.Cluster_EDS
 return cluster.Cluster_ORIGINAL_DST
 return cluster.Cluster_EDS
 default:
 return cluster.Cluster_EDS
}

在將 Istiod 環(huán)境變量 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 設(shè)置為 true 后，再查看 Envoy 的日志，可以看到雖然請(qǐng)求原始 IP 地址還是 172.16.0.198，但 Envoy 已經(jīng)把請(qǐng)求分發(fā)到了實(shí)際可用的三個(gè) Server 的 IP 上。

[2020-09-24T13:35:28.790Z]  PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP lastDirtyTimestamp=1600954114925 HTTP/1.1  200 -  -   -  0 0 4 4  -   Java-EurekaClient/v1.9.13   d98fd3ab-778d-42d4-a361-d27c2491eff0   eureka-server:8761   172.16.1.3:8761  outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:39934 172.16.0.198:8761 172.16.0.169:53890 - default
[2020-09-24T13:35:58.797Z]  PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP lastDirtyTimestamp=1600954114925 HTTP/1.1  200 -  -   -  0 0 1 1  -   Java-EurekaClient/v1.9.13   7799a9a0-06a6-44bc-99f1-a928d8576b7c   eureka-server:8761   172.16.0.59:8761  outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:45582 172.16.0.198:8761 172.16.0.169:53890 - default
[2020-09-24T13:36:28.801Z]  PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP lastDirtyTimestamp=1600954114925 HTTP/1.1  200 -  -   -  0 0 2 1  -   Java-EurekaClient/v1.9.13   aefb383f-a86d-4c96-845c-99d6927c722e   eureka-server:8761   172.16.0.200:8761  outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:60794 172.16.0.198:8761 172.16.0.169:53890 - default

神秘消失的服務(wù)

在將 Eureka Server Cluster 的類型從 ORIGINAL_DST 改為 EDS 之后，之前心跳失敗的服務(wù)正常了。但過(guò)了一段時(shí)間后，發(fā)現(xiàn)原來(lái) Eureka 中注冊(cè)的部分服務(wù)下線，導(dǎo)致服務(wù)之間無(wú)法正常訪問(wèn)。查詢 Eureka Server 的日志，發(fā)現(xiàn)日志中有如下的錯(cuò)誤：

2020-09-24 14:07:35.511 WARN 6 --- [eureka-server-3] c.netflix.eureka.cluster.PeerEurekaNode : EUREKA-SERVER-2/eureka-server-2.eureka-server.eureka.svc.cluster.local:eureka-server-2:8761:Heartbeat@eureka-server-0.eureka-server: missing entry.
2020-09-24 14:07:35.511 WARN 6 --- [eureka-server-3] c.netflix.eureka.cluster.PeerEurekaNode : EUREKA-SERVER-2/eureka-server-2.eureka-server.eureka.svc.cluster.local:eureka-server-2:8761:Heartbeat@eureka-server-0.eureka-server: cannot find instance

從日志中我們可以看到多個(gè) Eureka Server 之間的數(shù)據(jù)同步發(fā)生了錯(cuò)誤。當(dāng)部署為集群模式時(shí)，Eureka 集群中的多個(gè)實(shí)例之間會(huì)進(jìn)行數(shù)據(jù)同步，本例中的 Eureka 集群中有三個(gè)實(shí)例，這些實(shí)例之間的數(shù)據(jù)同步如下圖所示：

當(dāng)改用 EDS 之后，當(dāng)集群中的每一個(gè) Eureka Server 向集群中的其他 Eureka Server 發(fā)起數(shù)據(jù)同步時(shí)，這些請(qǐng)求被請(qǐng)求方 Pod 中的 Envoy Sidecar 采用 Round Robin 進(jìn)行了隨機(jī)分發(fā)，導(dǎo)致同步消息發(fā)生了紊亂，集群中每個(gè)服務(wù)器中的服務(wù)注冊(cè)消息不一致，導(dǎo)致某些服務(wù)被誤判下線。該故障現(xiàn)象比較隨機(jī)，經(jīng)過(guò)多次測(cè)試，我們發(fā)現(xiàn)在 Eureka 中注冊(cè)的服務(wù)較多時(shí)更容易出現(xiàn)改故障，當(dāng)只有少量服務(wù)時(shí)不容易復(fù)現(xiàn)。

找到原因后，要解決該問(wèn)題就很簡(jiǎn)單了，我們可以通過(guò)將 Eureka Server 的 Sidecar Injection 設(shè)置為 false 來(lái)規(guī)避該問(wèn)題，如下面的 yaml 片段所示：

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: eureka-server
spec:
 selector:
 matchLabels:
 app: eureka-server
 serviceName:  eureka-server 
 replicas: 3
 template:
 metadata:
 labels:
 app: eureka-server
 annotations:
 sidecar.istio.io/inject:  false  #  不為  eureka-server pod  注入  Envoy Siedecar
 spec:
 containers:
 - name: eureka-server
 image: zhaohuabing/eureka-test-service:latest
 ports:
 - containerPort: 8761
 name: http

反思

對(duì)于 Headless Service，Istio 缺省采用“ORIGINAL_DST”類型的 Cluster，要求 Envoy Sidecar 在轉(zhuǎn)發(fā)時(shí)采用請(qǐng)求原始目的 IP 地址的行為其實(shí)是合理的。如同我們?cè)诒鞠盗械纳弦黄恼隆篒stio 運(yùn)維實(shí)戰(zhàn)系列（2）：讓人頭大的『無(wú)頭服務(wù)』- 上』所介紹的，Headless Service 一般用于定義有狀態(tài)的服務(wù)。對(duì)于有狀態(tài)的服務(wù)，需要由客戶端根據(jù)應(yīng)用特定的算法來(lái)自行決定訪問(wèn)哪一個(gè)后端 Pod，因此不應(yīng)該在這些 Pod 前加一個(gè)負(fù)載均衡器。

在本例中，由于 Eureka 集群中各個(gè)節(jié)點(diǎn)之間會(huì)對(duì)收到的客戶端服務(wù)心跳通知進(jìn)行同步，因此對(duì)于客戶端來(lái)說(shuō)，將心跳通知發(fā)送到哪一個(gè) Eureka 節(jié)點(diǎn)并不重要，我們可以認(rèn)為 Eureka 集群對(duì)于外部客戶端而言是無(wú)狀態(tài)的。因此設(shè)置 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 環(huán)境變量，在客戶端的 Envoy Sidecar 中對(duì)客戶端發(fā)往 Eureka Server 的請(qǐng)求進(jìn)行負(fù)載均衡是沒(méi)有問(wèn)題的。但是由于 Eureka 集群內(nèi)部的各個(gè)節(jié)點(diǎn)之間的是有狀態(tài)的，修改后影響了集群中各個(gè) Eureka 節(jié)點(diǎn)之間的數(shù)據(jù)同步，導(dǎo)致了后面部分服務(wù)錯(cuò)誤下線的問(wèn)題。對(duì)于引發(fā)的該問(wèn)題，我們通過(guò)去掉 Eureka Server 的 Sidecar 注入來(lái)進(jìn)行了規(guī)避。

對(duì)于該問(wèn)題，更合理的處理方法是 Envoy Sidecar 在嘗試連接 Upstream Host 失敗一定次數(shù)后主動(dòng)斷開(kāi)和客戶端側(cè)的鏈接，由客戶端重新查詢 DNS，獲取正確的 Pod IP 來(lái)創(chuàng)建新的鏈接。經(jīng)過(guò)測(cè)試驗(yàn)證，Istio 1.6 及之后的版本中，Envoy 在 Upstream 鏈接斷開(kāi)后會(huì)主動(dòng)斷開(kāi)和 Downstream 的長(zhǎng)鏈接，建議盡快升級(jí)到 1.6 版本，以徹底解決本問(wèn)題。也可以直接采用騰訊云上的云原生 Service Mesh 服務(wù) TCM（Tencent Cloud Mesh），為微服務(wù)應(yīng)用快速引入 Service Mesh 的流量管理和服務(wù)治理能力，而無(wú)需再關(guān)注 Service Mesh 基礎(chǔ)設(shè)施自身的安裝、維護(hù)、升級(jí)等事項(xiàng)。

以上就是“Istio 使用過(guò)程中出現(xiàn)的問(wèn)題怎么解決”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，丸趣 TV 小編每天都會(huì)為大家更新不同的知識(shí)，如果還想學(xué)習(xí)更多的知識(shí)，請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道。

正文完