一、概述

1、Ribbon是什么

Ribbon是Netflix發(fā)布的開源項(xiàng)目，Spring Cloud Ribbon是基于Netflix Ribbon實(shí)現(xiàn)的一套客戶端負(fù)載均衡的框架。

2、Ribbon能干什么

LB負(fù)載均衡(Load Balance)是什么？

簡單的說就是將用戶的請求平攤的分配到多個服務(wù)上，從而達(dá)到系統(tǒng)的HA（高可用）。
常見的負(fù)載均衡有軟件Nginx，硬件 F5等。

什么情況下需要負(fù)載均衡？

現(xiàn)在Java非常流行微服務(wù)，也就是所謂的面向服務(wù)開發(fā)，將一個項(xiàng)目拆分成了多個項(xiàng)目，其優(yōu)點(diǎn)有很多，其中一個優(yōu)點(diǎn)就是：將服務(wù)拆分成一個一個微服務(wù)后，我們很容易的來針對性的進(jìn)行集群部署。例如訂單模塊用的人比較多，我就可以將這個模塊多部署幾臺機(jī)器，來分擔(dān)單個服務(wù)器的壓力。

這時候有個問題來了，前端頁面請求的時候到底請求集群當(dāng)中的哪一臺？既然是降低單個服務(wù)器的壓力，所以肯定全部機(jī)器都要利用起來，而不是說一臺用著，其他空余著。這時候就需要用負(fù)載均衡了，像這種前端頁面調(diào)用后端請求的，要做負(fù)載均衡的話，常用的就是Nginx。

Ribbon和Nginx負(fù)載均衡區(qū)別

• 當(dāng)后端服務(wù)是集群的情況下，前端頁面調(diào)用后端請求，要做負(fù)載均衡的話，常用的就是Nginx。
• Ribbon主要是在服務(wù)端內(nèi)做負(fù)載均衡，舉例：訂單后端服務(wù) 要調(diào)用 支付后端服務(wù)，這屬于后端之間的服務(wù)調(diào)用，壓根根本不經(jīng)過頁面，而支付后端服務(wù)是集群，這時候訂單服務(wù)就需要做負(fù)載均衡來調(diào)用支付服務(wù)，記住是訂單服務(wù)做負(fù)載均衡 來調(diào)用 支付服務(wù)。

負(fù)載均衡分類

• 集中式LB：即在服務(wù)的消費(fèi)方和提供方之間使用獨(dú)立的LB設(shè)施(可以是硬件，如F5, 也可以是軟件，如nginx)，由該設(shè)施負(fù)責(zé)把訪問請求通過某種策略轉(zhuǎn)發(fā)至服務(wù)的提供方；
• 進(jìn)程內(nèi)LB：將LB邏輯集成到消費(fèi)方，消費(fèi)方從服務(wù)注冊中心獲知有哪些地址可用，然后自己再從這些地址中選擇出一個合適的服務(wù)器。

Ribbon負(fù)載均衡

Ribbon就屬于進(jìn)程內(nèi)LB，它只是一個類庫，集成于消費(fèi)方進(jìn)程。

舉例：微服務(wù)經(jīng)常會涉及到A服務(wù)調(diào)用B服務(wù)的接口，這時候就需要用HTTP遠(yuǎn)程調(diào)用框架，常見的有Feign、RestTemplate、HttpClient，假如B服務(wù)只有一個節(jié)點(diǎn)，這時候我們可以在調(diào)用的時候?qū)懝潭╥p來進(jìn)行調(diào)用，假如B服務(wù)的節(jié)點(diǎn)存在多個（也就是集群），那A服務(wù)究竟調(diào)用B服務(wù)的哪個節(jié)點(diǎn)呢，這時候可以通過負(fù)載均衡框架來計(jì)算出調(diào)用哪個，比如輪詢調(diào)用B服務(wù)的多個節(jié)點(diǎn)，總不可能一直調(diào)用人家的一個服務(wù)，這樣B服務(wù)的集群有什么意義呢？或者也可以隨機(jī)調(diào)用任意節(jié)點(diǎn)，總之負(fù)載均衡的作用就是避免一直調(diào)用一個節(jié)點(diǎn)。

大概的流程：RestTemplate或者Feign可以通過注冊中心拿到服務(wù)提供方的IP+端口，假如提供者有多個，那他就會拿到多個地址，有了這些地址就差訪問的時候訪問哪個地址的服務(wù)了，而Ribbon可以很好的和RestTemplate或者Feign進(jìn)行集成，來決定調(diào)用哪個服務(wù)，具體是負(fù)載均衡還是隨機(jī)Ribbon都可以設(shè)置。

3、Ribbon現(xiàn)狀

項(xiàng)目處于維護(hù)狀態(tài) ，已經(jīng)一年多沒有更新過了。

https://github.com/Netflix/ribbon

4、未來替代方案

5、架構(gòu)說明

首先通過上圖一定要明白一點(diǎn)：ribbon一定是用在消費(fèi)方，而不是服務(wù)的提供方！

Ribbon在工作時分成兩步（這里以Eureka為例，consul和zk同樣道理）：

• 第一步先選擇 EurekaServer ,它優(yōu)先選擇在同一個區(qū)域內(nèi)負(fù)載較少的server.
• 第二步再根據(jù)用戶指定的策略，在從server取到的服務(wù)注冊列表中選擇一個地址。

其中Ribbon提供了多種策略：比如輪詢、隨機(jī)和根據(jù)響應(yīng)時間加權(quán)。

Spring Cloud Eureka服務(wù)注冊中心入門流程分析

http://www.dbjr.com.cn/article/204240.htm

之前寫樣例時候沒有引入spring-cloud-starter-ribbon也可以使用ribbon，這是為什么？

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>

猜測spring-cloud-starter-netflix-eureka-client自帶了spring-cloud-starter-ribbon引用

證明如下： 可以看到spring-cloud-starter-netflix-eureka-client 確實(shí)引入了Ribbon（zk和consul注冊中心同樣是如此）

二、RestTemplate 用法詳解

本篇涉及到的項(xiàng)目均使用RestTemplate結(jié)合Ribbon來完成遠(yuǎn)程負(fù)載均衡調(diào)用！

RestTemplate 用法詳解：http://www.dbjr.com.cn/article/256124.htm

三、Ribbon核心組件IRule

IRule：根據(jù)特定算法中從服務(wù)列表中選取一個要訪問的服務(wù)

Ribbon給提供了很多現(xiàn)成的算法類，IRule就是最頂層的算法類接口，Ribbon默認(rèn)是輪詢規(guī)則。假如我們想要修改算法，只需要將算法類注入到容器。然后通過簡單的配置就可以修改。

這些算法類都在如下包當(dāng)中，一般我們只要引入Eureka、zk、consul三個其中一個注冊中心的依賴，就會附帶Ribbon的依賴，Ribbon依賴就會依賴ribbon-loadbalancer包。

• ClientConfigEnabledRoundRobinRule：該策略較為特殊，我們一般不直接使用它。因?yàn)樗旧聿]有實(shí)現(xiàn)什么特殊的處理邏輯。一般都是可以通過繼承他重寫一些自己的策略，默認(rèn)的choose方法就實(shí)現(xiàn)了線性輪詢機(jī)制
• BestAvailableRule：繼承自ClientConfigEnabledRoundRobinRule，會先過濾掉由于多次訪問故障而處于斷路器跳閘狀態(tài)的服務(wù),然后選擇一個并發(fā)量最小的服務(wù)，該策略的特性是可選出最空閑的實(shí)例
• PredicateBasedRule：繼承自ClientConfigEnabledRoundRobinRule，抽象策略，需要重寫方法的，然后自己來自己定義過濾規(guī)則的
• AvailabilityFilteringRule：繼承PredicateBasedRule，先過濾掉故障實(shí)例,再選擇并發(fā)較小的實(shí)例
• ZoneAvoidanceRule：繼承PredicateBasedRule，默認(rèn)規(guī)則，復(fù)合判斷server所在區(qū)域的性能和server的可用性選擇服務(wù)器
• com.netflix.loadbalancer.RoundRobinRule：輪詢
• WeightedResponseTimeRule：對RoundRobinRule的擴(kuò)展,響應(yīng)速度越快的實(shí)例選擇權(quán)重越大,越容易被選擇
• ResponseTimeWeightedRule：對RoundRobinRule的擴(kuò)展,響應(yīng)時間加權(quán)
• com.netflix.loadbalancer.RandomRule：隨機(jī)
• com.netflix.loadbalancer.StickyRule：這個基本也沒人用
• com.netflix.loadbalancer.RetryRule：先按照RoundRobinRule的策略獲取服務(wù),如果獲取服務(wù)失敗則在指定時間內(nèi)會進(jìn)行重試,獲取可用的服務(wù)
• ZoneAvoidanceRule：默認(rèn)規(guī)則,復(fù)合判斷server所在區(qū)域的性能和server的可用性選擇服務(wù)器

四、實(shí)戰(zhàn)項(xiàng)目

1、回顧之前的項(xiàng)目

http://www.dbjr.com.cn/article/204240.htm

如下是項(xiàng)目當(dāng)中涉及到的微服務(wù)：

ribbon一定是用在消費(fèi)端，A調(diào)用B服務(wù)的接口，那么A就是消費(fèi)端

在這個項(xiàng)目示例當(dāng)中，在消費(fèi)者服務(wù)當(dāng)中通過RestTemplate+@LoadBalanced來完成負(fù)載均衡調(diào)用提供者。

這里調(diào)用提供者的時候不再是固定ip，而是通過服務(wù)名稱調(diào)用。相當(dāng)于通過服務(wù)名稱向注冊中心當(dāng)中去獲取注冊的服務(wù)，假如注冊了兩個名稱一樣的服務(wù)，那么就獲取到了兩個ip，RestTemplate內(nèi)部控制了訪問哪個ip的服務(wù)。他是如何負(fù)載均衡的？就是和Ribbon無縫結(jié)合，具體原理后續(xù)再說。

注意：RestTemplate想要通過服務(wù)名稱來調(diào)用，那么一定要配置@LoadBalanced注解，不然會報(bào)錯的，只有配置了這個注解，RestTemplate才會和Ribbon相結(jié)合。

服務(wù)名稱就是在提供者的application當(dāng)中配置的。

2、@RibbonClient注解用法

這個注解的意思就是，當(dāng)RestTemplate調(diào)用服務(wù)名稱為CLOUD-PAYMENT-SERVICE的時候，采用MySelfRule當(dāng)中注入的負(fù)載均衡算法。

@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration=MySelfRule.class)

官方文檔明確給出了警告：這個自定義配置類不能放在@ComponentScan所掃描的當(dāng)前包下以及子包下，否則我們自定義的這個配置類就會被所有的Ribbon客戶端所共享，達(dá)不到特殊化定制的目的了（也就是一旦被掃描到，RestTemplate直接不管調(diào)用哪個服務(wù)都會用指定的算法）。

springboot項(xiàng)目當(dāng)中的啟動類使用了@SpringBootApplication注解，這個注解內(nèi)部就有@ComponentScan注解，默認(rèn)是掃描啟動類包下所有的包，所以我們要達(dá)到定制化一定不要放在他能掃描到的地方。

cloud中文官網(wǎng)：https://www.springcloud.cc/spring-cloud-greenwich.html#netflix-ribbon-starter

3、配置文件用法

如下配置就可以取代@RibbonClient注解，注意一定要使用全類名，沒有@RibbonClient級別高：

CLOUD-PAYMENT-SERVICE:
  ribbon:
    NFLoadBalancerRuleClassName: com.gzl.myrule.MySelfRule

@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration=MySelfRule.class)

4、修改默認(rèn)算法

我們還是基于這個Eureka項(xiàng)目示例來進(jìn)行演示修改默認(rèn)算法：：http://www.dbjr.com.cn/article/204240.htm

1. 修改cloud-consumer-order80（ribbon一定是用在消費(fèi)端，A調(diào)用B服務(wù)的接口，那么A就是消費(fèi)端）

新建package，只要不和啟動類在同一個包下即可！

@Configuration
public class MySelfRule {
    @Bean
    public IRule myRule() {
        //定義為隨機(jī)
        return new RandomRule();
    }
}

2、主啟動類添加@RibbonClient（這個是一定要指定的，不然他不知道我們要修改算法，假如配置文件方式指定了就不需要添加這個注解了）

在啟動該微服務(wù)的時候就能去加載我們的自定義Ribbon配置類，從而使配置生效：

@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration= MySelfRule.class)

3、測試

這時候再測試訪問消費(fèi)者接口，會發(fā)現(xiàn)已經(jīng)不再是輪詢訪問了，成為了隨機(jī)訪問！

訪問：http://localhost/consumer/payment/get/1

五、Ribbon原理

1、負(fù)載均衡算法

以輪詢算法為例：rest接口第幾次請求數(shù) % 服務(wù)器集群總數(shù)量 = 實(shí)際調(diào)用服務(wù)器位置下標(biāo)

每次服務(wù)重啟動后rest接口計(jì)數(shù)從1開始。

為什么要獲取服務(wù)器下標(biāo)呢？

算法完全是基于DiscoveryClient來從注冊中心獲取到注冊的服務(wù)列表，獲取的是個List<ServiceInstance>，有了下標(biāo)，有了服務(wù)list集合，那我們自然就知道要訪問哪個服務(wù)了。

import org.springframework.cloud.client.discovery.DiscoveryClient;
@Resource
private DiscoveryClient discoveryClient;

List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
        for (ServiceInstance element : instances) {
            System.out.println(element.getServiceId() + "\t" + element.getHost() + "\t" + element.getPort() + "\t"
                    + element.getUri());
        }

輸出的結(jié)果：

如： List [0] instances = 127.0.0.1:8002
　　 List [1] instances = 127.0.0.1:8001

8001+ 8002 組合成為集群，它們共計(jì)2臺機(jī)器，集群總數(shù)為2， 按照輪詢算法原理：

• 當(dāng)總請求數(shù)為1時： 1 % 2 =1 對應(yīng)下標(biāo)位置為1 ，則獲得服務(wù)地址為127.0.0.1:8001
• 當(dāng)總請求數(shù)位2時： 2 % 2 =0 對應(yīng)下標(biāo)位置為0 ，則獲得服務(wù)地址為127.0.0.1:8002
• 當(dāng)總請求數(shù)位3時： 3 % 2 =1 對應(yīng)下標(biāo)位置為1 ，則獲得服務(wù)地址為127.0.0.1:8001
• 當(dāng)總請求數(shù)位4時： 4 % 2 =0 對應(yīng)下標(biāo)位置為0 ，則獲得服務(wù)地址為127.0.0.1:8002
• 如此類推…

2、源碼分析

我看的Cloud的Hoxton.SR1版本，版本之間源碼略有不同，但是大概思路差不多。

ribbon實(shí)現(xiàn)的關(guān)鍵點(diǎn)是為ribbon定制的RestTemplate，ribbon利用了RestTemplate的攔截器機(jī)制，在攔截器中實(shí)現(xiàn)ribbon的負(fù)載均衡。負(fù)載均衡的基本實(shí)現(xiàn)就是利用applicationName從服務(wù)注冊中心獲取可用的服務(wù)地址列表，然后通過一定算法負(fù)載，決定使用哪一個服務(wù)地址來進(jìn)行http調(diào)用。

1.Ribbon的RestTemplate

RestTemplate中有一個屬性是List<ClientHttpRequestInterceptor> interceptors，如果interceptors里面的攔截器數(shù)據(jù)不為空，在RestTemplate進(jìn)行http請求時，這個請求就會被攔截器攔截進(jìn)行，攔截器需要實(shí)現(xiàn)ClientHttpRequestInterceptor接口，接口就一個方法，需要實(shí)現(xiàn)以下方法：

也就是說攔截器需要完成http請求，并封裝一個標(biāo)準(zhǔn)的response返回。

2.Ribbon中的攔截器

在Ribbon 中就是通過名字為LoadBalancerInterceptor的攔截器，注入到RestTemplate中，進(jìn)行攔截請求，然后實(shí)現(xiàn)負(fù)載均衡調(diào)用的。

攔截器定義在：org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration

這個類是在這個包下，并不在Ribbon的包下：

攔截器的定義與攔截器注入器的定義：下面的bean是攔截器注入器

3.Ribbon中的攔截器注入到RestTemplate

定義了攔截器，自然需要把攔截器注入到、RestTemplate才能生效，那么Ribbon中是如何實(shí)現(xiàn)的？上面說了攔截器的定義與攔截器注入器的定義，那么肯定會有個地方使用注入器來注入攔截器的。

還是在這個類當(dāng)中：org.springframework.cloud.client.loadbalancer.LoadBalancerAutoConfiguration

遍歷context中的注入器，調(diào)用注入方法，為目標(biāo)RestTemplate注入攔截器，注入器和攔截器都是我們定義好的。

還有關(guān)鍵的一點(diǎn)是：需要注入攔截器的目標(biāo)restTemplates到底是哪一些？因?yàn)?code>RestTemplate實(shí)例在context中可能存在多個，不可能所有的都注入攔截器，這里就是@LoadBalanced注解發(fā)揮作用的時候了。

4.LoadBalanced注解

嚴(yán)格上來說，這個注解是spring cloud實(shí)現(xiàn)的，不是ribbon中的，它的作用是在依賴注入時，只注入實(shí)例化時被@LoadBalanced修飾的實(shí)例。

例如我們定義Ribbon的RestTemplate的時候是這樣的：

@Bean
@LoadBalanced
public RestTemplate rebbionRestTemplate(){
    return new RestTemplate();
}

因此才能為我們定義的RestTemplate注入攔截器。

那么@LoadBalanced是如何實(shí)現(xiàn)這個功能的呢？其實(shí)都是spring的原生操作，@LoadBalance的源碼如下

@Qualifier注解很重要：

@Autowired默認(rèn)是根據(jù)類型進(jìn)行注入的，因此如果有多個類型一樣的Bean候選者，則需要限定其中一個候選者，否則將拋出異常，@Qualifier限定描述符除了能根據(jù)名字進(jìn)行注入，更能進(jìn)行更細(xì)粒度的控制如何選擇候選者

@LoadBalanced很明顯，‘繼承’了注解@Qualifier，RestTemplates通過@Autowired注入，同時被@LoadBalanced修飾，所以只會注入@LoadBalanced修飾的RestTemplate，也就是我們的目標(biāo)RestTemplate。

5.攔截器邏輯實(shí)現(xiàn)

這里使用的是LoadBalancerInterceptor攔截器

當(dāng)我們每通過RestTemplate調(diào)用一個接口的時候都會經(jīng)過這個攔截器，通過攔截器當(dāng)中的intercept方法，然后執(zhí)行excute的時候，打斷點(diǎn)會發(fā)現(xiàn)他會執(zhí)行到這：

在這里就是根據(jù)對應(yīng)的負(fù)載均衡算法選擇對應(yīng)的服務(wù)，RibbonLoadBalancerClient就是Ribbon當(dāng)中的類了。由此可以看出框架有時候就是這樣，來回套用，cloud對外提供API，然后組件進(jìn)行真正的實(shí)現(xiàn)，假如感覺ribbon滿足不了我們，我們完全可以按照cloud的API來開發(fā)新的負(fù)載均衡框架，進(jìn)行無縫替換。

（1）getLoadBalancer(serviceId)：可以理解為，再第一次請求到來時，創(chuàng)建好IClientConfig（客戶端配置）、ServerList（從配置文件中加載的服務(wù)列表）、IRule（負(fù)載均衡策略）與IPing （探活策略）等Bean，是一種懶加載的模式。

（2）getServer(loadBalancer, hint)：則是通過以上的負(fù)載均衡策略與探活策略，從服務(wù)列表中選擇合適的服務(wù)實(shí)例（詳細(xì)代碼在ZoneAwareLoadBalancer的chooseServer方法中）。Server對象包含ip、端口與協(xié)議等信息。

重點(diǎn)看getServer方法，看看是如何選擇服務(wù)的

默認(rèn)就是ZoneAvoidanceRule負(fù)載均衡算法！

ZoneAvoidanceRule：繼承PredicateBasedRule，他是沒有重寫choose方法的，這時候就進(jìn)入到了父類的choose方法。

public Server choose(Object key) {
   ILoadBalancer lb = getLoadBalancer();
	// 這里就完成了服務(wù)的選擇
	// 而且我們可以看到，這里的lb.getAllServers 說明ILoadBalancer直接存儲或者間接存儲了服務(wù)列表
   Optional<Server> server = getPredicate().chooseRoundRobinAfterFiltering(lb.getAllServers(), key);
   if (server.isPresent()) {
       return server.get();
   } else {
       return null;
   }       
}

從上面可以看到chooseRoundRobinAfterFiltering 這個方法的意思就是在過濾之后，選擇輪詢的負(fù)載均衡方式。

而lb.getAllServers是獲取該服務(wù)的所有服務(wù)實(shí)例。

由此可見chooseRoundRobinAfterFiltering就是選擇的關(guān)鍵點(diǎn)了。

public Optional<Server> chooseRoundRobinAfterFiltering(List<Server> servers, Object loadBalancerKey) {
    // 過濾掉不復(fù)合條件的服務(wù)實(shí)例
	List<Server> eligible = getEligibleServers(servers, loadBalancerKey);
     if (eligible.size() == 0) {
         return Optional.absent();
     }
	// incrementAndGetModulo 這個就是輪詢的關(guān)鍵計(jì)算
     return Optional.of(eligible.get(incrementAndGetModulo(eligible.size())));
 }

其計(jì)算過程還是比較簡單的，使用了AtomicInteger來計(jì)算訪問的次數(shù)，cas+自旋鎖來控制多線程的安全性！

private final AtomicInteger nextIndex = new AtomicInteger();

六、手寫負(fù)載均衡器

1.RestTemplate去掉注解@LoadBalanced

2.LoadBalancer接口（在80消費(fèi)者添加）

這個接口相當(dāng)于是傳進(jìn)去多個服務(wù)，然后根據(jù)實(shí)現(xiàn)類，來選擇出一個服務(wù)，至于是輪詢還是隨機(jī)，我們自己實(shí)現(xiàn)。

import org.springframework.cloud.client.ServiceInstance;

import java.util.List;

public interface LoadBalancer {
    ServiceInstance instances(List<ServiceInstance> serviceInstances);
}

3.定義實(shí)現(xiàn)類（在80消費(fèi)者添加）

@Component
public class MyLB implements LoadBalancer {

    private AtomicInteger atomicInteger = new AtomicInteger(0);

    // 獲取服務(wù)的下標(biāo)
    public final int getAndIncrement() {
        int current;
        int next;
        do {
            current = this.atomicInteger.get();
            next = current >= 2147483647 ? 0 : current + 1;
        } while (!this.atomicInteger.compareAndSet(current, next));
        System.out.println("*****next: " + next);
        return next;
    }

    // 下標(biāo)和服務(wù)數(shù)進(jìn)行取模
    @Override
    public ServiceInstance instances(List<ServiceInstance> serviceInstances) {
        int index = getAndIncrement() % serviceInstances.size();
        return serviceInstances.get(index);
    }
}

4.調(diào)整8001服務(wù)和8002服務(wù)，這兩個服務(wù)是提供者，新增一個接口，來進(jìn)行測試使用！

@Value("${server.port}")
private String serverPort;

@GetMapping(value = "/payment/lb")
 public String getPaymentLB() {
     return serverPort;
 }

5.在消費(fèi)者80端添加測試接口

@GetMapping("/consumer/payment/lb")
public String getPaymentLB() {
    // 這個是利用的cloud自帶的DiscoveryClient，假如cloud項(xiàng)目使用了注冊中心都可以通過服務(wù)名稱來獲取對應(yīng)的服務(wù)信息
    List<ServiceInstance> instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");

    if (instances == null || instances.size() <= 0) {
        return null;
    }
    // 獲取要訪問的服務(wù)信息
    ServiceInstance serviceInstance = loadBalancer.instances(instances);
    URI uri = serviceInstance.getUri();

    return restTemplate.getForObject(uri + "/payment/lb", String.class);
}

6.測試

http://localhost/consumer/payment/lb

這樣我們就成功自己實(shí)現(xiàn)了一個負(fù)載均衡！

到此這篇關(guān)于Spring Cloud Ribbon的使用詳解的文章就介紹到這了,更多相關(guān)Spring Cloud Ribbon使用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論