精品欧美一区二区三区在线观看 _久久久久国色av免费观看性色_国产精品久久在线观看_亚洲第一综合网站_91精品又粗又猛又爽_小泽玛利亚一区二区免费_91亚洲精品国偷拍自产在线观看 _久久精品视频在线播放_美女精品久久久_欧美日韩国产成人在线

寫給Go開發者的gRPC教程-服務發現與負載均衡

開發 前端
用通俗易懂的方式來解釋下什么是服務發現。通常情況下客戶端需要知道服務端的IP+端口號才能建立連接,但服務端的IP和端口號并不是那么容易記憶。還有更重要的,在云部署的環境中,服務端的IP和端口可能隨時會發生變化。

對于一個客戶端創建請求的過程

conn, err := grpc.Dial("example:8009", grpc.WithInsecure())
if err != nil {
  panic(err)
}
  1. gRPC客戶端通過服務發現解析請求,將名稱解析為一個或多個IP地址,以及服務配置
  2. 客戶端使用上一步的服務配置、ip列表、實例化負載均衡策略
  3. 負載均衡策略為每個服務器地址創建一個子通道(channel),并監測每一個子通道狀態
  4. 當有rpc請求時,負載均衡策略決定那個子通道即gRPC服務器將接收請求,當可用服務器為空時客戶端的請求將被阻塞

gRPC官方提供了基本的服務發現和負載均衡邏輯,并提供了接口供擴展用于開發自定義的服務發現與負載均衡

服務發現

用通俗易懂的方式來解釋下什么是服務發現。通常情況下客戶端需要知道服務端的IP+端口號才能建立連接,但服務端的IP和端口號并不是那么容易記憶。還有更重要的,在云部署的環境中,服務端的IP和端口可能隨時會發生變化。

所以我們可以給某一個服務起一個名字,客戶端通過名字創建與服務端的連接,客戶端底層使用服務發現系統,解析這個名字來獲取真正的IP和端口,并在服務端的IP和端口發生變化時,重新建立連接。這樣的系統通常也會被叫做name-system(名字服務)

gRPC 中的默認name-system是 DNS,同時在客戶端以插件形式提供了自定義name-system的機制。

名字格式

gRPC采用的名字格式遵循的RFC 3986中定義的URI語法

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

例如

URI示例URI示例

gRPC關注其中兩部分

  • URI scheme:第一個:前面的標識。對于gRPC客戶端來說,它指示要使用的服務發現解析器,如果未指定前綴或方案未知,則默認使用DNS方案
  • URI path:指示要解析的名字

大部分gRPC實現默認支持以下的URI schemes

  • dns:[//authority/]host[:port] -- DNS (default)
  • unix:path, unix://absolute_path -- Unix domain sockets (Unix systems only)
  • unix-abstract:abstract_path -- Unix domain socket in abstract namespace (Unix systems only)

服務的服務注冊

如果gRPC服務端的地址是靜態的,可以在客戶端服務發現時直接解析為靜態的地址

如果gRPC服務端的地址是動態的,可以有兩種選擇

  • 自注冊:當gRPC的服務啟動后,向一個集中的注冊中心進行注冊
  • 平臺的服務發現:使用k8s平臺時,平臺會感知gPRC實例的變化

關于服務注冊這里不在做更多介紹了

客戶端的服務發現

自定義服務發現需要在客戶端啟動前,注冊一個服務解析器(Resolve)

Golang中使用google.golang.org/grpc/resolver.Register(resolver.Builder)注冊,這個函數不是直接接收一個解析器,而是使用工廠模式接收一個解析器的構造器

type Builder interface {
 // Build creates a new resolver for the given target.
 //
 // gRPC dial calls Build synchronously, and fails if the returned error is
 // not nil.
 Build(target Target, cc ClientConn, opts BuildOptions) (Resolver, error)
 // Scheme returns the scheme supported by this resolver.
 // Scheme is defined at https://github.com/grpc/grpc/blob/master/doc/naming.md.
 Scheme() string
}

? Scheme()需要返回的就是名字格式中提到的URI scheme

? Build(...)需要返回一個服務發現解析器google.golang.org/grpc/resolver.Resolver

??cc ClientConn代表客戶端與服務端的連接,其擁有的cc.UpdateState(State) error可以讓我們更新鏈接的狀態

type Resolver interface {
 // ResolveNow will be called by gRPC to try to resolve the target name
 // again. It's just a hint, resolver can ignore this if it's not necessary.
 //
 // It could be called multiple times concurrently.
  // ResolveNow 嘗試再一次對域名進行解析,在個人實踐中,服務端進程掛掉會觸發該調用
 ResolveNow(ResolveNowOptions)
  // Close closes the resolver.
  // 資源釋放。
 Close()
}

解析器需要有能力從注冊中心獲取解析結果,并更新客戶端中連接(cc ClientConn)的信息。還可以持續watch一個名字的解析結果,實時的更新客戶端中連接的信息

  • 解析出來的地址列表(包含ip和port)
  • 針對連接的服務配置,如負載均衡等,來想覆蓋全局的負責均衡配置
  • 每一個地址可以包含一系列的屬性(kv),他們可以用來支持后續的負載均衡策略

示例代碼

gRPC resolver 原理

?? 在 init() 階段時

  • 創建并注冊Builder 實例,將其注冊到 grpc 內部的 resolveBuilder 表中(其實是一個全局 map,key 為協議名;value 為構造的 resolveBuilder)

?? 客戶端啟動時通過自定義Dail()方法構造grpc.ClientConn單例

  • grpc.DialContext() 方法內部解析 URI,分析協議類型,并從 resolveBuilder 表中查找協議對應的 resolverBuilder
  • 將地址作為 Target 、conn單例作為resolver.ClientConn參數調用 resolver.Build 方法實例化出 Resolver
  • 用戶 Resolver實現中調用 cc.UpdateState 傳入 State.Addresses 地址,gRPC使用這個地址建立連接,傳入State.ServiceConfig,gRPC使用這份服務配置覆蓋默認配置

name-reslover原理name-reslover原理

代碼

# builder.go
package resolver

import "google.golang.org/grpc/resolver"

var _ resolver.Builder = Builder{}

type Builder struct {
 addrsStore map[string][]string
}

func NewResolverBuilder(addrsStore map[string][]string) *Builder {
 return &Builder{addrsStore: addrsStore}
}

func (b Builder) Build(target resolver.Target, cc resolver.ClientConn, opts resolver.BuildOptions) (resolver.Resolver, error) {
 r := &Resolver{
  target:     target,
  cc:         cc,
  addrsStore: b.addrsStore,
 }
 r.Start()
 return r, nil
}

func (b Builder) Scheme() string {
 return "example"
}
# resolver.go
package resolver

import (
 "google.golang.org/grpc/resolver"
)

var _ resolver.Resolver = &Resolver{}

// impl google.golang.org/grpc/resolver.Resolver
type Resolver struct {
 target resolver.Target
 cc     resolver.ClientConn

 addrsStore map[string][]string
}

func (r *Resolver) Start() {
 // 在靜態路由表中查詢此 Endpoint 對應 addrs
 var addrs []resolver.Address
 for _, addr := range r.addrsStore[r.target.URL.Opaque] {
  addrs = append(addrs, resolver.Address{Addr: addr})
 }

 r.cc.UpdateState(resolver.State{
  Addresses: addrs,
    // 設置負載均衡策略為round_robin
  ServiceConfig: r.cc.ParseServiceConfig(
    `{"loadBalancingPolicy":"round_robin"}`),
 })
}

func (r *Resolver) ResolveNow(resolver.ResolveNowOptions) {

}

func (r *Resolver) Close() {

}
# main.go
package main

import (
 "context"
 "log"

 rs "github.com/liangwt/note/grpc/name_resolver_lb_example/client/resolver"
 pb "github.com/liangwt/note/grpc/name_resolver_lb_example/ecommerce"
 "google.golang.org/grpc"
 "google.golang.org/grpc/resolver"
)

func main() {
 resolver.Register(rs.NewResolverBuilder(map[string][]string{
  "cluster@callee": {
   "127.0.0.1:8009",
  },
 }))

 conn, err := grpc.Dial("example:cluster@callee", grpc.WithInsecure())
 if err != nil {
  panic(err)
 }
  
 // ...
}

負載均衡

同樣來通俗易懂的解釋下什么負載均衡。為了提高系統的負載能力和穩定性,我們的服務端往往具有多臺服務器,負載均衡的目的就是希望請求能分散到不同的服務器,從服務器列表中選擇一臺服務器的算法就是負載均衡的策略,常見的輪循、加權輪詢等

負載均衡器要在多臺服務器之間選擇,所以通常情況下負載均衡器是具備服務發現的能力的

根據負載均衡實現所在的位置不同,通常可分為以下三種解決方案:

1、集中式負載均衡(Proxy Model)

在客戶端和服務端之間有一個獨立的LB,通常是專門的硬件設備如 F5,或者基于軟件如 LVS,HAproxy,Nginx等實現。LB使用負載均衡策略將請求轉發到目標服務

因為所有服務調用流量都經過LB,當服務數量和調用量大的時候,LB容易成為瓶頸;一旦LB發生故障影響整個系統;客戶端、服務端之間增加了一級,有一定性能開銷

圖片集中式負載均衡

2、客戶端負載均衡(Balancing-aware Client)

客戶端負載將LB的功能集成到客戶端進程里,然后使用負載均衡策略選擇一個目標服務地址,向目標服務發起請求。LB能力被分散到每一個服務消費者的進程內部,同時服務消費方和服務提供方之間是直接調用,沒有額外開銷,性能比較好。

但如果有多種不同的語言棧,就要配合開發多種不同的客戶端,有一定的研發和維護成本;后續如果要對客戶庫進行升級,勢必要求服務調用方修改代碼并重新發布,升級較復雜。

圖片客戶端負載均衡

3、獨立負載均衡進程(External Load Balancing Service)

將LB從進程內移出來,變成主機上的一個獨立進程。主機上的一個或者多個服務要訪問目標服務時,他們都通過同一主機上的獨立LB進程做負載均衡

此方案有兩種模式

第一種是直接由LB進行轉發請求,被稱為sidecar方案

第二種是從LB獲取到IP后依舊由客戶端發起請求,gRPC曾經支持過此方案叫lookaside方案,目前已廢棄

該方案也是一種分布式方案沒有單點問題,一個LB進程掛了只影響該主機上的客戶端;客戶端和LB之間是本地調用調用性能好;同時該方案還簡化了客戶端,不需要為不同語言開發客戶庫,LB的升級不需要服務調用方改代碼。該方案主要問題:部署較復雜,環節多,出錯調試排查問題不方便

獨立負載均衡進程獨立負載均衡進程


gRPC的負載均衡

上文介紹的三種負載均衡方式,集中式負載均衡和gRPC無關,屬于外部的基礎設施,因此我們不再介紹

gRPC中的負載平衡是以每次調用為基礎,而不是以每個連接為基礎。換句話說,即使所有的請求都來自一個客戶端,它仍能在所有的服務器上實現負載平衡

gRPC目前內置四種策略

?? pick_first:默認策略,選擇第一個

?? round_robin:輪詢

使用默認的負載均衡器很簡單,只需要在建立連接的時候指定負載均衡策略即可。

?? 注意

舊版本gRPC使用 grpc.WithBalancerName("round_robin"),已經被廢棄,使用grpc.WithDefaultServiceConfig。

grpc.WithDefaultServiceConfig可以被上文服務發現中提到的cc.UpdateState(State) error覆蓋配置

conn, err := grpc.Dial("example:cluster@callee",
  grpc.WithInsecure(),
  grpc.WithDefaultServiceConfig(
   `{"loadBalancingPolicy":"round_robin"}`,
  ),
 )

?? grpclb:已廢棄

它屬于上文介紹的負載均衡中獨立負載均衡進程第二種。不必直接在客戶端中添加新的LB策略,而只實現諸如round-robin之類的簡單算法,任何更復雜的算法都將由lookaside負載平衡器提供

gRPC的grpclb方案gRPC的grpclb方案

?? xDS

如果接觸過servicemesh那么對xDS并不會陌生,xDS 本身是Envoy中的概念,現在已經發展為用于配置各種數據平面軟件的標準,最新版本的gRPC已經支持xDS。不同于單純的負載均衡策略,xDS在gRPC包含了服務發現和負載均衡的概念

這里簡單的理解下xDS,本質上xDS就是一個標準的協議

它規定了xDS客戶端和xDS服務端的交互流程,即API調用的順序

我們在xDS 服務端實現服務發現,配置負載均衡策略等等,支持xDS的客戶端連接到xDS 服務端并通過xDS api來獲取各種需要的數據和配置

xDS主要應用于servicemesh中,在mesh中由sidecar連接到xDS server進行數據交互,同時由sidecar來控制流量的分發。也就是上文提到的獨立負載均衡進程的第一種模式

servicemesh的負載均衡servicemesh的負載均衡

gRPC使用xDS是一種無proxy的客戶端負載均衡方案。對比Mesh方案,性能更好。我們把servicemesh的負載均衡和grpc的xds負載均衡放在一起感受下區別

gRPC的xDS的方案

?? 這意味著,grpclb廢棄后,gRPC內置的pick_first、round_robin、xDS三種模式都屬于客戶端的負載均衡模式。pick_first、round_robin是單純的負載均衡策略;xDS包含了服務發現等一系列能力,并且還在不斷拓展中,而我們控制gRPC的行為也被轉移到了xDS server上了。

xDS模式的使用

xDS內容較多,又比較新,單獨開個章節介紹下xDS的使用

gRPC xDS架構中出現了三個服務

  • xDS server:它是我們的控制面
  • gRPC client:它既是gRPC服務的客戶端,同時也是xDS的客戶端
  • gRPC server:它是gRPC服務的服務端,它需要具備被xDS server發現的能力

我們可以使用 Envoy go-control-plane庫來實現xDS server,這部分的開發類似于servicemesh,就不介紹太多了,如果位于k8s平臺內可以參考下istio中控制面的實現

gRPC server需要自注冊或者托管到k8s平臺,如果托管到k8s則可以繼續參考istio中控制面的實現

因為xDS也包含了服務發現的部分,因此對于client來說第一步需要先開發自定義的服務發現和負載均衡配置。幸運的是gRPC官方已經為我們開發了對應實現,只需要引入包即可,在init階段會注冊xDS的解析器和負載均衡器

_ "google.golang.org/grpc/xds" // To install the xds resolvers and balancers.

隨后只需要把gRPC client連接到xDs server即可,這部分與非xDS并無不同。只是目標服務的地址的URI scheme為xds

conn, err := grpc.Dial("xds:///localhost:50051", grpc.WithTransportCredentials(creds))
if err != nil {
  panic(err)
}

ctx, cancelFn := context.WithCancel(context.Background())
defer cancelFn()

c := pb.NewOrderManagementClient(conn)
res, err := c.AddOrder(ctx, &order)

完整代碼可以參考:https://github.com/grpc/grpc-go/tree/master/examples/features/xds

自定義負載均衡器

自定義負載均衡器需要使用google.golang.org/grpc/balancer.Register提前注冊,此函數和服務發現一樣接受工廠函數

// Builder creates a balancer.
type Builder interface {
 // Build creates a new balancer with the ClientConn.
 Build(cc ClientConn, opts BuildOptions) Balancer
 // Name returns the name of balancers built by this builder.
 // It will be used to pick balancers (for example in service config).
 Name() string
}

? Name()是負載均衡策略的名字

? Build(...)需要返回負載均衡器

?? cc ClientConn代表客戶端與服務端的連接,其擁有一系列函數可以讓我們更新鏈接的狀態

type Balancer interface {
 // UpdateClientConnState is called by gRPC when the state of the ClientConn
 // changes.  If the error returned is ErrBadResolverState, the ClientConn
 // will begin calling ResolveNow on the active name resolver with
 // exponential backoff until a subsequent call to UpdateClientConnState
 // returns a nil error.  Any other errors are currently ignored.
 UpdateClientConnState(ClientConnState) error
 // ResolverError is called by gRPC when the name resolver reports an error.
 ResolverError(error)
 // UpdateSubConnState is called by gRPC when the state of a SubConn
 // changes.
 UpdateSubConnState(SubConn, SubConnState)
 // Close closes the balancer. The balancer is not required to call
 // ClientConn.RemoveSubConn for its existing SubConns.
 Close()
}

負載均衡器需要實現一系列的函數用于gRPC在不同場景下調用

類RR算法負載均衡器

如果要實現一個類round_robin的負載均衡策略,gRPC官方實現提供了一個baseBuilder,它已經實現了大部Balancer接口,可以大幅簡化了我們創建RR策略的邏輯。使用google.golang.org/grpc/balancer/base.NewBalancerBuilder創建負載均衡的工廠

func NewBalancerBuilder(name string, pb PickerBuilder, config Config) balancer.Builder
  • name string負載均衡器的名字
  • pb PickerBuilder是我們要實現的負載均衡策略邏輯的地方
  • config Config可以配置是否要進行健康檢查
// PickerBuilder creates balancer.Picker.
type PickerBuilder interface {
 // Build returns a picker that will be used by gRPC to pick a SubConn.
 Build(info PickerBuildInfo) balancer.Picker
}
type Picker interface {
  // 子連接選擇
 Pick(info PickInfo) (PickResult, error)
}

于是借助base.NewBalancerBuilder我們僅需要實現Picker一個函數即可實現類RR的負載均衡策略了

代碼

利用Picker接口來實現一個隨機選擇策略

# builder.go
package balancer

import (
 "google.golang.org/grpc/balancer"
 "google.golang.org/grpc/balancer/base"
)

var _ base.PickerBuilder = &Builder{}

type Builder struct {
}

func NewBalancerBuilder() balancer.Builder {
 return base.NewBalancerBuilder("random_picker", &Builder{}, base.Config{HealthCheck: true})
}

func (b *Builder) Build(info base.PickerBuildInfo) balancer.Picker {
 if len(info.ReadySCs) == 0 {
  return base.NewErrPicker(balancer.ErrNoSubConnAvailable)
 }

 var scs []balancer.SubConn
 for subConn := range info.ReadySCs {
  scs = append(scs, subConn)
 }

 return &Picker{
  subConns: scs,
 }
}
// picker.go
package balancer

import (
 "math/rand"

 "google.golang.org/grpc/balancer"
)

var _ balancer.Picker = &Picker{}

type Picker struct {
 subConns []balancer.SubConn
}

func (p *Picker) Pick(info balancer.PickInfo) (balancer.PickResult, error) {
 index := rand.Intn(len(p.subConns))
 sc := p.subConns[index]
 return balancer.PickResult{SubConn: sc}, nil
}
#client.go
package main

import (
 "context"
 "log"

 bl "github.com/liangwt/note/grpc/name_resolver_lb_example/client/balancer"
 rs "github.com/liangwt/note/grpc/name_resolver_lb_example/client/resolver"
 pb "github.com/liangwt/note/grpc/name_resolver_lb_example/ecommerce"
 "google.golang.org/grpc"
 "google.golang.org/grpc/balancer"
 "google.golang.org/grpc/resolver"
)

func main() {
 resolver.Register(rs.NewResolverBuilder(map[string][]string{
  "cluster@callee": {
   "127.0.0.1:8009",
   "127.0.0.1:8010",
  },
 }))

 balancer.Register(bl.NewBalancerBuilder())

 conn, err := grpc.Dial("example:cluster@callee",
  grpc.WithInsecure(),
  grpc.WithDefaultServiceConfig(
   `{"loadBalancingPolicy":"random_picker"}`,
  ),
 )
 if err != nil {
  panic(err)
 }
 
  ....
}

參考資料

[1]URI語法: https://zh.wikipedia.org/wiki/%E7%BB%9F%E4%B8%80%E8%B5%84%E6%BA%90%E6%A0%87%E5%BF%97%E7%AC%A6

[2]go-control-plane: https://github.com/envoyproxy/go-control-plane

[3]gRPC Name Resolution: https://github.com/grpc/grpc/blob/master/doc/naming.md

[4]Load Balancing in gRPC: https://github.com/grpc/grpc/blob/master/doc/load-balancing.md

[5]https://github.com/grpc/grpc-go: https://github.com/grpc/grpc-go

[6]gRPC Go 服務發現與負載均衡: https://blog.cong.moe/post/2021-03-06-grpc-go-discovery-lb/

[7][轉]gRPC服務發現&負載均衡: https://colobu.com/2017/03/25/grpc-naming-and-load-balance/

[8]淺淡 xDS 協議在 gRPC 中的應用: http://limeng.org/2020/03/08/xds-in-grpc.html

責任編輯:武曉燕 來源: 涼涼的知識庫
相關推薦

2020-04-15 22:18:55

架構負載均衡分布式

2011-02-22 14:07:52

2013-11-26 09:43:36

開發日志博客

2019-09-19 09:03:13

Docker負載均衡服務

2022-01-12 18:20:36

GoJava開發

2025-07-31 06:00:00

Go后端開發

2013-03-28 10:22:33

數據庫關系型數據庫數據庫設計

2019-09-19 14:57:27

Docker語言技術

2012-06-13 01:23:30

開發者程序員

2021-12-16 20:12:37

后端開發Sentry

2012-11-03 21:03:37

2019-11-29 08:05:26

連接池負載均衡互聯網架構

2023-10-27 12:36:37

gRPCKubernetes

2023-10-17 08:08:37

Dubbo服務注冊中心

2019-02-21 09:18:27

服務路由負載均衡微服務

2022-04-22 14:15:59

Go開發者受訪者

2019-06-09 09:13:14

Istio負載均衡架構

2011-04-18 15:38:15

喬布斯佩奇開發者

2011-11-16 13:47:05

點贊
收藏

51CTO技術棧公眾號

久久精品人人做人人爽电影| 欧美激情一级二级| 国产乱码一区二区三区四区| 高清全集视频免费在线| 高清视频一区二区| 人人澡人人澡人人看欧美| 你懂得视频在线观看| 日韩中文字幕视频网| 一本色道久久综合狠狠躁的推荐| 亚洲欧美综合一区| 免费a视频在线观看| 日日摸夜夜添夜夜添国产精品 | 好吊色视频一区二区三区| 中国色在线日|韩| 亚洲天堂成人在线观看| 欧美xxxx黑人又粗又长精品| 国产精品无码一区二区桃花视频 | 亚洲综合图色| 日韩欧美国产精品| 日本免费观看网站| tube8在线hd| 1区2区3区欧美| 欧美日韩亚洲在线| 精品人妻无码一区二区 | 特级西西444www| 色偷偷偷在线视频播放| 成人免费一区二区三区视频 | 激情小视频在线| 大白屁股一区二区视频| 国产精品色午夜在线观看| 男人天堂中文字幕| 68国产成人综合久久精品| 亚洲毛片一区二区| 亚洲一区二区三区综合| 日本在线一区二区三区| 欧美精品一二三| 亚洲男人天堂色| 一区二区精品伦理...| 亚洲精品高清在线观看| 一区不卡字幕| 高清性色生活片在线观看| 99精品久久只有精品| 99re国产| 亚洲成人中文字幕在线| 国产二区国产一区在线观看| 国产日韩欧美在线播放| 亚洲精品91天天久久人人| 久久久久久9| 欧美最近摘花xxxx摘花| 日本午夜小视频| 亚洲电影成人| 午夜精品福利在线观看| 久久精品99国产精| 欧美日韩91| 欧美高清视频在线观看| 免费在线一级片| 国产综合亚洲精品一区二| 久久99精品久久久久久青青91| 国产探花在线视频| 国产大片一区| 久久av在线播放| 五月天婷婷色综合| 女人天堂亚洲aⅴ在线观看| 久久精品影视伊人网| 免费观看特级毛片| 香蕉综合视频| 欧美成人高清视频| 久久免费视频6| 亚洲精品免费观看| 日本久久精品视频| 男操女视频网站| 免费欧美在线视频| 成人免费直播live| www.精品久久| 99精品久久99久久久久| 欧美日韩三区四区| 欧美日韩欧美| 亚洲综合免费观看高清在线观看| 男人日女人视频网站| 亚洲午夜天堂| 欧美日韩一区三区| 色哟哟在线观看视频| 精品av导航| 亚洲人午夜精品免费| 一级免费黄色录像| 欧美午夜精品| 国产成人极品视频| 97精品久久人人爽人人爽| 国产盗摄女厕一区二区三区| 久久精品国产精品青草色艺 | 中文字幕自拍偷拍| 国产精品91一区二区| 久久亚洲高清| 免费在线你懂的| 一区二区三区国产精品| 欧美色图另类小说| 婷婷激情成人| 日韩av中文在线| 99精品中文字幕| 激情欧美日韩| 国产噜噜噜噜噜久久久久久久久 | 国产情侣自拍av| 麻豆91精品视频| 狠狠色综合色区| 黄色免费在线观看网站| 狠狠躁夜夜躁久久躁别揉| 日本在线播放一区二区| 丝袜连裤袜欧美激情日韩| 色一情一乱一区二区| 日韩aaaaaa| 久久99精品久久只有精品| 久久国产精品-国产精品| 顶级网黄在线播放| 91国模大尺度私拍在线视频| 欧美日韩一区二区区| 红桃成人av在线播放| 久久久久久久久久久成人| 中文字幕一区二区人妻| 97aⅴ精品视频一二三区| eeuss中文| 精品视频在线一区二区在线| 亚洲精品国产精品国自产观看浪潮| 1024在线看片| 久久xxxx精品视频| 国产精品久久久对白| 91caoporn在线| 一本大道久久a久久综合婷婷 | 久久精品网站免费观看| 性一交一乱一伧国产女士spa| 日本免费成人| 一个人看的www久久| 精品成人久久久| 国产成人综合在线播放| 中文有码久久| 久久av影院| 中文字幕av日韩| 五月婷婷激情视频| 91亚洲永久精品| 免费毛片网站在线观看| 亚洲国产精品免费视频| 久久精品成人一区二区三区 | 蜜臀av性久久久久蜜臀aⅴ四虎 | 欧美精品成人| 亚洲精品欧美日韩| 精品国产丝袜高跟鞋| 在线视频你懂得一区| 玖玖爱在线观看| 性8sex亚洲区入口| 久久国产一区二区| 亚洲欧洲美洲av| 亚洲品质视频自拍网| 亚洲日本视频在线观看| 2021国产精品久久精品| 欧美国产激情视频| 一区二区美女| 国产精品aaaa| 日本成人在线播放| 在线不卡一区二区| 在线免费观看亚洲视频| 国产乱子伦视频一区二区三区| 日韩国产精品毛片| 亚洲高清在线一区| 孩xxxx性bbbb欧美| 色天堂在线视频| 91精品91久久久中77777| 男人的天堂av网| 精品在线观看视频| 青青草视频在线视频| 黄色免费大全亚洲| 78色国产精品| 国产1区2区3区在线| 欧美精品aⅴ在线视频| 丰满少妇被猛烈进入一区二区| 国产福利一区二区三区视频在线 | 极品在线视频| 亚洲视频在线看| 国产精品久久免费| 亚洲综合视频网| a级片在线观看| 久久精品国产99国产| 日本成人在线不卡| 亚洲精品**不卡在线播he| 国产精品中文在线| sm在线观看| 最新中文字幕亚洲| 亚洲产国偷v产偷v自拍涩爱| 日韩欧美在线观看| 操她视频在线观看| av中文字幕不卡| 色综合天天色综合| 亚洲小说欧美另类婷婷| 色一情一乱一伦一区二区三区丨| 国产精品xnxxcom| 午夜精品一区二区三区av| 成年人在线观看网站| 欧美xingq一区二区| 黄色片视频免费| 一区二区三区四区国产精品| 中文幕无线码中文字蜜桃| 国产资源精品在线观看| 精品人妻一区二区三区四区在线| 欧美高清在线| 久久久久国产精品视频| 精品国产三区在线| 国产成+人+综合+亚洲欧洲| 亚洲精品天堂| 一本色道久久综合狠狠躁篇的优点 | 国产精品无码无卡无需播放器| 国产大陆a不卡| 天天视频天天爽| 亚洲免费在线| 欧美一二三不卡| 日韩亚洲一区在线| 免费久久99精品国产自| 99re8这里有精品热视频免费| 国产精品高精视频免费| 成年女人在线看片| 免费av一区二区| 在线免费观看黄| 亚洲欧美变态国产另类| 人妻无码中文字幕免费视频蜜桃| 91麻豆精品国产91久久久资源速度| 青青草av在线播放| 亚洲精品中文在线影院| 中文字幕美女视频| 国产日韩一级二级三级| 97人妻精品一区二区三区免 | caopeng在线| 在线观看亚洲区| 九色在线播放| 精品伊人久久97| 无码精品视频一区二区三区| 日韩女优视频免费观看| 99热这里只有精品在线观看| 欧美丰满嫩嫩电影| 91theporn国产在线观看| 欧美午夜精品一区二区三区| 国产一区免费看| 色婷婷一区二区| 综合网在线观看| 色综合激情五月| 免费污污视频在线观看| 色欧美乱欧美15图片| 五月天激情四射| 色综合咪咪久久| 中文字幕一区在线播放| 日韩欧美第一页| 69国产精品视频免费观看| 欧美日韩色婷婷| 免费的毛片视频| 在线视频你懂得一区| 国产偷人爽久久久久久老妇app| 日本韩国欧美一区| 天堂免费在线视频| 欧美人xxxx| 国产喷水吹潮视频www| 日韩一区二区在线观看视频播放| av一级黄色片| 亚洲高清在线观看| 日韩电影网址| 尤物精品国产第一福利三区 | 国产日韩一区二区在线观看| 日韩精品一级中文字幕精品视频免费观看| 成人在线看视频| 青草av.久久免费一区| 国产成人美女视频| 国产成人av资源| 国产三级视频网站| 国产精品污www在线观看| 99鲁鲁精品一区二区三区| 亚洲精选在线视频| 日韩欧美三级视频| 在线观看国产精品网站| 国产精品女人久久久| 欧美精品一区二区三区蜜桃视频| 天天操天天插天天射| 国产亚洲精品日韩| 最新国产在线拍揄自揄视频| 国产做受69高潮| 国产私拍福利精品视频二区| 成人精品久久久| 另类图片第一页| 亚洲国产成人不卡| 国产在线成人| 欧美丰满熟妇xxxxx| 国产美女视频一区| 亚洲av无码一区二区三区观看| 久久精品视频免费| 国产人妻精品一区二区三区不卡 | 中文字幕一区二区三区四区视频| 日韩一区二区免费视频| 欧美美女色图| 久久成人精品一区二区三区| 色是在线视频| 96pao国产成视频永久免费| 日韩激情毛片| 在线视频一二三区| 美女诱惑一区| 最新国产精品自拍| 中文在线免费一区三区高中清不卡 | av影片在线一区| 免费在线观看视频a| 久久精品国产精品亚洲精品| 国内精品久久99人妻无码| 中文字幕一区二区视频| 成人午夜视频精品一区| 7799精品视频| 欧美一区二区少妇| 久久av资源网站| 午夜精品成人av| 国产另类自拍| 最新国产精品| 最近中文字幕一区二区| 99久久精品国产一区| www色aa色aawww| 在线观看视频一区| 污视频网站在线播放| 欧美成人精品一区二区| 欧美日韩国产网站| 六月婷婷久久| 在线观看日韩av电影| 岛国av免费在线| 国产欧美日本一区二区三区| 国产情侣自拍av| 亚洲国产欧美一区二区丝袜黑人| 黄色小网站在线观看| 国产精品一区二区女厕厕| 亚洲精品国产动漫| 99热亚洲精品| 粉嫩av一区二区三区粉嫩| 日本黄色片免费观看| 欧美色综合网站| 国产福利第一视频在线播放| 日本国产一区二区三区| 乱亲女h秽乱长久久久| 日韩中文字幕在线不卡| 国产在线精品免费av| 最新黄色av网址| 欧美日韩国产在线观看| 天天在线视频色| 国产精品极品尤物在线观看| 久久最新网址| 妓院一钑片免看黄大片| 国产午夜精品一区二区三区四区| 你懂的国产在线| 亚洲人成电影在线播放| 综合日韩av| 奇米精品在线| 视频一区欧美精品| 欧美激情久久久久久久| 欧美在线制服丝袜| 99免在线观看免费视频高清| 国产精品流白浆视频| 99视频精品全国免费| 国产在线a视频| 亚洲小说欧美激情另类| 色婷婷综合视频| 欧美在线观看视频| 私拍精品福利视频在线一区| 欧美成人免费高清视频| 国产嫩草影院久久久久| 亚洲熟女乱色一区二区三区久久久| www.精品av.com| 日韩欧美激情电影| 国产极品在线视频| 国产午夜亚洲精品不卡| 亚洲影院一区二区三区| 欧美成人免费播放| 国产精品自在线拍| wwwxxx黄色片| 成人免费一区二区三区在线观看| 亚洲精品国产一区二| 国内揄拍国内精品| 国产麻豆一区二区三区精品视频| 538在线视频观看| 亚洲欧美另类久久久精品| 人妻视频一区二区三区| 国产盗摄xxxx视频xxx69| 91视频综合| 成年人看片网站| 欧美性生交xxxxx久久久| 午夜伦理在线| 国产麻豆日韩| 欧美aa在线视频| 豆国产97在线 | 亚洲| 国产午夜精品视频免费不卡69堂| 国产美女视频一区二区| 免费看又黄又无码的网站| 国产欧美视频一区二区| 国产黄a三级三级看三级| 日本免费久久高清视频| 综合久久99| 国产小视频自拍| 精品国产一区久久| 福利精品在线| 99在线精品免费视频| 中文字幕一区免费在线观看| 亚洲日本在线播放| 成人女保姆的销魂服务| 久久福利影视|