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

從Rust模塊化探索到DLB 2.0實踐

開發 前端
當前成果驗證了Rust在負載均衡產品中改造中的工程價值:依托線程安全的運行時結構(如 Arc<Mutex<T>> )、高效前綴樹路由( HostSelector )及最長前綴匹配,性能與可維護性均突破傳統方案邊界。

一、前言

二、Nginx+Rust 的模塊化探索

三、全面擁抱Rust進入DLB2.0階段

    1. 配置體系

    2. 流量處理    

四、總結

一、前言

在云原生架構高速迭代的背景下,基礎設施的性能瓶頸與安全隱患成為技術演進的關鍵挑戰。本文系統記錄了團隊基于Rust語言改造Nginx組件的完整技術路徑:從接觸Cloudflare的quiche庫,引發對Rust安全特性的探索,到通過FFI實現核心邏輯的跨語言調用;從突破傳統C模塊開發范式自研 ngx_http_rust_module SDK ,到全面采用Pingora框架構建新一代DLB 2.0流量調度平臺。

實踐表明,Rust的內存安全機制與異步高并發能力可顯著提升負載均衡組件的性能邊界與可靠性,為超大規模流量調度場景提供全新解決方案。本技術演進過程將詳述架構設計、核心模塊實現及性能優化策略,為同類基礎設施升級提供可復用的工程經驗。

二、Nginx+Rust 的模塊化探索

探索的起點源于和quiche(cloudflare開發的高效quic實現)的初次邂逅,這扇門將項目組成員引入了 Rust 語言的世界。Rust 以其卓越的內存安全、無懼并發的特性以及出色的性能潛力,迅速展示了其作為系統級編程語言的優勢。這份吸引力促使我們思考:能否將 Rust 的安全與性能注入我們更廣泛的基礎設施中?作為核心組件的 Nginx 自然成為了探索的焦點。

我們首先聚焦于FFI(外部函數接口)技術,通過它構建Rust與C語言的交互橋梁。借助FFI,我們將核心業務邏輯以Rust實現,并將Rust代碼編譯為符合C-ABI規范的動態鏈接庫。這種設計使得Nginx能夠像調用原生C模塊一樣無縫集成Rust編寫的庫,在保障系統穩定性的同時提升性能。

圖片圖片

采用該方案的限流模塊示例如下:

圖片圖片

鑒于單向調用模式在應用場景上的局限性,如果僅僅支持上面的單向調用流,使用的場景將大打折扣,目前Nginx 中大量的功能以三方模塊的形式呈現,C module的開發難度較高,需要理解的組件概念頗多,團隊嘗試開發了ngx_http_rust_module模塊作為一個探索期的折中方案。

圖片圖片

ngx_http_rust_module本質上是一個Rust SDK,是對傳統C模塊開發模式的一種現代化補充嘗試。SDK層封裝好的膠水function極大便利了rust module上層開發,可以實現純Rust編碼來實現業務功能,實踐驗證具備較高工程價值。

目前已封裝的部分SDK展示以及設置響應header方法示例:

圖片圖片

圖片圖片

三、全面擁抱Rust進入DLB2.0階段

完成Nginx模塊的初步探索后,團隊技術路線轉向Cloudflare開源的Pingora框架,該高性能Rust框架專為構建可編程、高可靠的流量調度平臺而設計。

核心優勢

  • 云原生架構 :通過異步任務調度消除Nginx的進程隔離瓶頸,實現CPU負載均衡與高效連接復用。
  • 性能突破 :實測每秒可處理10萬請求,資源消耗降至傳統方案的三分之一。
  • 協議生態 :原生支持HTTP/1-2、Websocket端到端代理。
  • 安全演進 :基于Rust內存安全特性,集成FIPS認證的加密模塊解決C/C++方案的安全隱患。
  • 擴展能力 :提供可編程負載均衡API與熱升級機制,滿足超大規模流量調度需求。

在原型驗證其技術可行性之后,團隊決定在該框架骨干上構建了DLB 2.0產品體系:

圖片圖片

核心能力設計

  • 聲明式配置管理

提供基于YAML的聲明式配置接口,顯著提升配置可讀性與維護效率。

支持熱加載機制,實現流量無損的配置更新,徹底規避傳統代理重載導致的503服務中斷。

  • 流量處理

支持單一端口多域名TLS證書托管能力,簡化HTTPS服務部署。

提供與Nginx完全兼容的server/path路由匹配邏輯,確保無縫遷移。

實現路徑重寫引擎,滿足復雜流量調度需求。

采用模塊化Filter鏈設計,支持按需插拔流量處理組件。

  • 服務發現

集成靜態資源配置與動態DNS服務發現雙模式。

支持sylas注冊中心。

企業級監控。

提供增強型訪問日志。

輸出完全兼容DLB 1.0的監控指標(VTS格式)。

保留流量錄制數據規范,確保監控體系平滑升級。

每個模塊的設計均遵循"高內聚低耦合"原則,在保障生產環境穩定性的前提下,為超大規模流量調度場景提供可擴展的技術支撐,后續將逐一拆解部分關鍵模塊的技術實現細節與性能優化策略。

配置體系

靜態配置

DLB 2.0在配置層面按類型拆分成多個細粒度的yaml文件,其中最核心的是 server.yaml 以及 upstream.yaml ,為了對標Nginx核心概念、這部分不引入新的術語,繼續沿用 server 、 location 、 upstream 三大基礎模塊。

  • 通過 server 模塊聲明虛擬主機,支持多域名監聽及端口綁定,兼容 server_name 的泛域名解析能力,同時實現單端口多域名 TLS 證書的精準匹配。
  •  location 模塊完整繼承 Nginx 的路徑匹配邏輯(含精確匹配 = 、正則匹配 ~ 等模式),支持基于路徑的請求路由與正則表達式重寫規則,確保策略遷移的零成本適配。同時支持 proxy_pass 、 if 、 proxy_headers 、 return 等核心指令。
  •  upstream 動態服務發現機制支持權重負載均衡,通過 YAML 結構化配置實現后端集群的聲明式管理,并與DNS的服務發現深度集成,徹底消除傳統配置中硬編碼 IP 的維護負擔。
- id: "hjob.shizhuang-inc.com"
  server_name: "hjob.shizhuang-inc.com"
  service_in:
  - "default_80"
  - "default_443"
  redirect: true
  location:
  - path: "/"
    access_rule_names:
    - "access_allow_d803a06f39ad4dcd8dfe517359a33a61"
    - "access_deny_all"
    client_max_body_size: "100M"
    proxy_headers:
    - "clientport:$remote_port"
    - "Upgrade:$http_upgrade"
    - "Connection:$http_connection"
    - "Host:$host"
    - "X-Forwarded-For:$proxy_add_x_forwarded_for"
    - "X-Forwarded-Proto:$scheme"
    proxy_pass: "http://hangzhou-csprd-hjob-8899"


 - name: "hangzhou-csprd-hjob-8899"
  peers:
  - server: "1.1.1.1:8899"
    weight: 100
    backup: false
    down: false
  - server: "2.2.2.2:8899"
    weight: 1
    backup: false
    down: false
  max_fails: 3
  fail_timeout: "10s"
  max_connections: 1000

配置解析

在DLB 2.0的配置模型中, server 、 location 、 upstream 三者構成層次化路由架構:

圖片圖片

  •  server 作為虛擬服務單元,通過 Vec<LocationConf> 聚合任意數量的 location 路由規則。
  •  location 作為請求路徑處理器,可獨立關聯至不同的 upstream 服務組。
  •  upstream 采用原子引用計數機制( Arc )封裝配置,通過Arc::strong_count() 實時監控引用狀態,避免冗余配置拷貝,基于Rust的并發安全特性,最終設計為 Arc<Mutex<UpstreamConf>> 結構:

 Mutex 保障多線程環境下的內部可變性,支撐配置熱更新需求。

 Arc 維持跨線程的只讀共享能力,確保訪問高效性。

main thread解析完server.yaml與upstream.yaml后,將生成兩個核心哈希映射:

  •  server 配置映射表:關聯域名與路由規則集。
  •  upstream 線程安全容器:托管負載均衡服務組狀態。
/// A map of server names to their respective configurations.
#[serde(skip)]
pub servers: HashMap<String, Arc<Mutex<ServerConf>>>,
/// A map of upstream names to their respective configurations.
#[serde(skip)]
pub upstreams: HashMap<String, Arc<Mutex<UpstreamConf>>>,

運行時配置轉化

上述的 ServerConf 與 UpstreamConf 面向的是用戶,特點是易于理解與維護、支持YAML反序列化。

而為了專注運行時效率(比如負載均衡策略中的字符串轉化為枚舉類型),我們會將 UpstreamConf 轉化為 RunTimeUpStream 結構, ServerConf 同理。

impl TryFrom<&UpstreamConf> for RunTimeUpStream {
    type Error = Error;
    fn try_from(value: &UpstreamConf) -> std::result::Result<Self, Self::Error> {
    }
}

轉化之后得到全局唯一的 GlobalConf :

pub static GLOBAL_CONF: Lazy<RwLock<GlobalConf>> = Lazy::new(|| {
    RwLock::new(GlobalConf {
        main_conf: MainConf::default(),
        runtime_upstreams: HashMap::with_capacity(16),
        runtime_servers: HashMap::with_capacity(16),
        host_selectors: HashMap::with_capacity(16),
    })
});


#[derive(Default)]
pub struct GlobalConf {
    // main static configuration
    pub main_conf: MainConf,
    //one-to-one between upstreams and runtime_upstreams
    pub runtime_upstreams: HashMap<String, Arc<RunTimeUpStream>>,
    //one-to-one between servers and runtime_servers;
    pub runtime_servers: HashMap<String, Arc<RunTimeServer>>,
    //one service one host selector
    pub host_selectors: HashMap<String, Arc<HostSelector>>,
}

流量處理

域名匹配

如果僅有上面的 runtime_servers 這一個哈希表,還不能實現復雜的Nginx域名匹配規則,Nginx域名匹配的優先級機制包括:精確匹配>前置通配符>正則匹配(后置通配符在1.0版本未使用,暫且忽略),為了確保無縫遷移,需要提供與Nginx完全兼容的server匹配邏輯,考慮到代碼可維護性,可以這樣組織運行時數據:

  • 為精確域名使用HashMap,實現O(1)查找。
  • 前置通配符匹配存儲為Vec,且確保最長匹配優先。
  • 正則表達式只能順序匹配,保持Vec<Regex>原順序。

最終得到這樣的結構體:

/// A struct to manage server selection based on host names.
///
/// This struct contains three fields: `equal`, `prefix`, and `regex`.
/// The `equal` field is a HashMap that stores server names and their corresponding IDs
/// when the server name exactly matches the host.
/// The `prefix` field is a Vec of tuples, where each tuple contains a prefix and its corresponding server ID.
/// The `regex` field is a Vec of tuples, where each tuple contains a Regex and its corresponding server ID.
///
/// The `HostSelector` struct provides methods to insert server names and IDs,
/// and to match a given host name with a server ID based on the rules defined in the struct.
#[derive(Clone)]
pub struct HostSelector {
    pub equal: HashMap<String, String>,
    pub prefixes: Vec<(String, String)>,  //原始前通配符數據
    pub prefix_nested_map: NestedHashMap, // 嵌套哈希結構優化匹配效率
    pub regex: Vec<(Regex, String)>,
}

其中需要留意的是成員 prefix_nested_map ,為了確保最長匹配優先,我們將 prefixes: Vec<(String, String)> 轉化為了 NestedHashMap 結構, NestedHashMap 為一個嵌套哈希結構,可基于域名分段實現高效檢索。

#[derive(Debug, Clone)]
pub struct NestedHashMap {
    data: HashMap<String, NestedHashMap>, //層級域名節點
    value: Option<String>, // 終端節點關聯服務器ID
}


impl NestedHashMap
{
    /// 基于域名分段實現高效檢索(從右向左匹配)
    pub(crate) fn find(&self, key: &str) -> Option<String> {
        let tokens = key.split('.').collect::<Vec<&str>>();
        let mut current_map = self;
        let mut result = None;
        // 遍歷域名層級(如 www.example.com → [com, example, www])
        for token in tokens.iter().rev() {
            // 優先記錄當前層級的有效值(實現最長匹配)
            if current_map.value.is_some() {
                result = Some(current_map.value.as_ref().unwrap());
            }
            // 向下一級域名跳轉
            let child = current_map.data.get(*token);
            match child{
                Some(child) => {
                    current_map = child;
                }
                None => {
                    break;
                }
            }
        }
        result.map(|value| value.to_owned())
    }
}

路由匹配

講完了域名匹配,我們再深入路由匹配,在開始之前,我們先回顧一下Nginx的location指令。

Syntax:location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default:—
Context:server, location

 location 通常在 server{} 塊內定義,也可以嵌套到 location{} 內,雖然這不是一種推薦的配置方式,但它確實是被語法規則支持的, localtion 語法主要有如下幾種形式:

※  修飾符語義及優先級(依匹配精度降序排列)
  1.  = :精確匹配(Exact Match),URI必須與模式完全一致時生效(最高優先級)。
  2.  ^~ :最佳前綴匹配(Prefix Match),選中最長非正則路徑后終止搜索(優先級次于=)。
  3.  ~ :區分大小寫的正則匹配(Case-Sensitive Regex)。
  4.  ~* :不區分大小寫的正則匹配(Case-Insensitive Regex)。
  5.  @ :內部定位塊(Named Location),僅限 try_files 或 error_page 指令調用,不對外暴露。

Nginx在解析完 location 之后會進行一系列的工作,主要包括:

  • 分類:  根據location的修飾符參數標識不同的類型,同時去除name前面的修飾符
  • 排序: 對一個server塊內的所有location進行排序,經過排序之后將location分為了3類

通用類型,通用類型的location將建立一棵最長前綴匹配樹

正則類型,順序為配置文件中定義的順序,正則會用pcre庫先進行編譯

內部跳轉類型,順序也為配置文件中定義的順序

  • 拆分:將分類的3種類型拆分,分門別類的處理

其中最復雜的是最長前綴匹配樹的構建,假設location規則如下,構造一棵最長前綴匹配樹會經過如下幾個步驟:

圖片圖片

  1. 把locations queue變化locations list,假設一個location的name是A的話,所有以A前綴開頭的路由節點都會放到A節點的list里(最長前綴匹配)。

圖片圖片

2.按照上述步驟遞歸初始化A節點的所有list節點,最終得到下面的list。

圖片圖片

3.在上述創建的list基礎上,確定中間節點,然后從中間節點把location分成兩部分,然后遞歸創建左右子樹,最后處理list隊列,list隊列創建的節點會加入到父節點的tree中,最終將生成一棵多叉樹。

圖片圖片

現在你應該已經明白了最長前綴匹配樹的構建流程,讓我們回到2.0的設計上來,這部分同樣維護了三個結構分別對應精確匹配、正則匹配以及最長前綴匹配。

#[derive(Clone, Default)]
#[allow(unused)]
/// A struct representing a shared runtime server configuration.
pub struct RunTimeServer {
    /// Unique identifier for the server.
    pub id: String,
    /// Name of the server.
    pub server_name: String,
    /// Indicates whether the server should redirect requests.
    pub redirect: bool,
    /// A HashMap storing equal-matched locations, where the key is the path and the value is the location.
    pub equal_match: HashMap<String, Arc<RunTimeLocation>>,// 精確匹配字典
    /// A Vec storing regex-matched locations, where each tuple contains a Regex and the location.// 正則匹配隊列
    pub regex_match: Vec<(Regex, Arc<RunTimeLocation>)>,
    /// The root node of the static location tree.
    pub prefix_root: Option<Arc<static_location_tree::TreeNode>>,
}

精確匹配、正則匹配比較簡單,我們重點介紹最長前綴匹配,最長前綴匹配樹的構建基本上是把Nginx代碼原原本本的翻譯過來,通過 create_list() 分組節點、 create_tree() 生成多叉樹。通過 find_location 遍歷樹結構查找最長有效路徑,其中路徑比較函數 path_cmp() 確保按字典序定位子樹,匹配成功時返回( need_stop, location ),其中 need_stop 標志是否中止搜索(模擬 ^~ 行為)。

pub fn find_location(path: &str, node: &Arc<TreeNode>) -> Option<(bool, Arc<RunTimeLocation>)> {
    let mut node = Some(node);
    let mut uri_len = 0;
    let mut search_node = None;


    while let Some(current) = node {
        let n = std::cmp::min(current.path.len(), path.len() - uri_len);
        let node_path = ¤t.path[..n];
        let temp_path = &path[uri_len..uri_len + n];


        match path_cmp(node_path, temp_path) {
            std::cmp::Ordering::Equal => {
                uri_len += n;
                search_node = Some((current.need_stop, current.val.clone()));
                node = current.tree.as_ref();
                if uri_len >= path.len() { break; }
            }
            std::cmp::Ordering::Greater => node = current.left.as_ref(),
            std::cmp::Ordering::Less => node = current.right.as_ref(),
        }
    }
    search_node
}

路由重寫

路由重寫是實現請求路徑動態轉換的核心能力,在語義層面,我們完全兼容Nginx的配置語義。

 regex replacement [flag] ,同時采用預編譯正則引擎,在路由加載期完成規則編譯。

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub enum RewriteFlags {
    Break,
    Last,
    Redirect,
    Permanent,
    NONE,
}


pub struct RewriteRule {
    pub reg_source: String,
    pub reg: Regex,
    pub target: String,
    pub flag: RewriteFlags,
}

模塊化Filter鏈

Pingora 引擎已經將請求生命周期劃分了足夠細的各個階段,為了更精細化控制同一phase執行的各個Filter,可通過自定義的 ProxyFilter trait,與 Pingora 引擎的phase關聯起來。

#[async_trait]
pub trait ProxyFilter: Sync + Send {
    fn phase(&self) -> ProxyFilterPhase;
    
    fn name(&self) -> ProxyFilterName;
    
    fn order(&self) -> i32;
    
    async fn handle(&self, _session: &mut Session, _ctx: &mut ProxyContext) -> HandleResult {
        HandleResult::Continue
    }
}

 ProxyFilter 主要包含四個方法:

  •  phase : Filter 的執行階段, 生命周期階段錨點,可以根據實際需要進行擴展插入更細粒度的階段進行請求處理。
  •  name : Filter的名稱。
  •  order : 在同一個phase內Filter的執行順序。
  •  handle : Filter 的執行邏輯,若返回的是 HandleResult::Continue ,則表示當前filter執行完成,繼續執行下一個 filter,否則停止filter chain 的執行動作。
#[derive(Debug, PartialEq, Clone, EnumString)]
pub enum HandleResult {
    /// 表示當前filter執行完成,繼續執行下一個 filter。
    Continue,
    /// 表示當前filter操作被中斷,停止filter chain 的執行動作。
    Break,
}

目前我們已經實現的Filter包括但不限于:

圖片圖片

四、總結

作為《從Rust模塊化探索到DLB 2.0實踐》系列的第一篇,本文介紹了開發DLB 2.0的背景以及詳述了DLB 2.0如何通過聲明式配置管理、分層路由架構及與Nginx完全兼容的匹配邏輯,實現億級流量調度場景下的高可用與零遷移成本。

當前成果驗證了Rust在負載均衡產品中改造中的工程價值:依托線程安全的運行時結構(如 Arc<Mutex<T>> )、高效前綴樹路由( HostSelector )及最長前綴匹配,性能與可維護性均突破傳統方案邊界。

在后續篇章中,我們將繼續深入剖析服務發現、監控與日志等核心模塊,為超大規模云原生架構提供完整的參考實踐。

責任編輯:武曉燕 來源: 得物技術
相關推薦

2017-05-18 11:43:41

Android模塊化軟件

2017-04-10 14:23:01

typescriptjavascriptwebpack

2025-02-27 01:00:00

AI編程代碼

2016-12-14 14:50:26

CSS預處理語言模塊化實踐

2010-02-03 09:01:01

Java動態模塊化

2017-02-13 18:46:38

Android模塊化組件化

2019-08-28 16:18:39

JavaScriptJS前端

2022-11-02 18:47:46

場景模塊化跨棧

2017-08-11 16:10:36

微信Android實踐

2017-08-08 16:07:57

Android 模塊化架構

2016-11-08 20:31:19

同方服務器模塊化

2025-05-12 08:45:00

模塊化FastAPI路由分發

2017-05-18 10:23:55

模塊化開發RequireJsJavascript

2020-09-17 10:30:21

前端模塊化組件

2013-08-20 15:31:18

前端模塊化

2022-03-11 13:01:27

前端模塊

2015-10-10 11:29:45

Java模塊化系統初探

2020-09-18 09:02:32

前端模塊化

2022-09-16 07:40:17

CloudWeGo開源Rust

2021-12-16 22:02:28

webpack原理模塊化
點贊
收藏

51CTO技術棧公眾號

91久久香蕉国产日韩欧美9色| 国产一二精品视频| 亚洲日本成人网| 香蕉视频网站入口| 国产精品成久久久久三级| 国产精品天天av精麻传媒| 中文字幕日本在线观看| 国产麻豆一精品一av一免费| 97人人做人人爱| 精品亚洲aⅴ无码一区二区三区| 国产精品**亚洲精品| 天天色天天操综合| 一区视频二区视频| 欧美在线精品一区二区三区| 久久一区二区三区四区五区| 蜜臀久久99精品久久久久久宅男| 国产人妻人伦精品1国产丝袜| 最新日韩一区| 欧美日韩久久久久| 亚洲色图都市激情| 搞黄视频免费在线观看| 成人免费看的视频| 国产精品一区av| 国产又色又爽又黄的| 99热精品久久| 亚洲人午夜精品| 国产a级片视频| 亚洲a成人v| 色成年激情久久综合| 国产精品视频二| 欧美黑人激情| 国产亚洲综合色| 国产一区二区三区高清| 国产乱码久久久久| 奇米影视7777精品一区二区| 欧美激情综合色综合啪啪五月| 欧美a级片免费看| 欧美丝袜激情| 亚洲欧美日韩中文在线| 视频免费在线观看| 欧美日韩黄色| 日韩视频不卡中文| 久久久福利影院| 欧美成人黄色| 欧美性一二三区| 欧美伦理视频在线观看| 秋霞伦理一区| 疯狂做受xxxx高潮欧美日本| 男人天堂av片| 在线不卡日本v二区707| 中文字幕一区二区三区乱码在线 | 天堂在线资源8| 国产精品一区二区三区乱码 | 亚洲一区二区影视| 丝瓜av网站精品一区二区 | 免费日韩成人| 欧美日韩电影在线播放| 日本 片 成人 在线| 亚洲性受xxx喷奶水| 欧美日韩国产一区中文午夜| 少妇人妻在线视频| 在线天堂中文资源最新版| 欧美日韩国产中文字幕 | 国产美女高潮在线观看| 偷偷要91色婷婷| 日本免费不卡一区二区| 在线看片国产福利你懂的| 一本色道a无线码一区v| 午夜dv内射一区二区| 97欧美成人| 欧美日韩国产高清一区二区| 色婷婷一区二区三区在线观看| 精品国产乱码一区二区三区| 日韩精品中文字幕在线一区| 五月天丁香社区| 欧美sss在线视频| 亚洲欧美在线看| 亚洲高潮女人毛茸茸| 日韩在线二区| 欧美国产欧美亚洲国产日韩mv天天看完整| 久久久久久久9999| 在线亚洲精品| 国产精品久久久久久久久久久不卡| 中国一级片黄色一级片黄| 久久 天天综合| 国产精品国产三级国产专区53| 亚洲av成人精品日韩在线播放| 久久精品欧美日韩| 男同互操gay射视频在线看| 国产精品蜜臀| 欧美影院一区二区三区| 欧美成人手机在线视频| 欧美jizz19性欧美| www.欧美精品一二三区| 日韩女同强女同hd| 男人的j进女人的j一区| 99r国产精品视频| 视频二区在线| 亚洲日本在线视频观看| www.99热这里只有精品| 日韩成人在线电影| 亚洲电影第1页| 一本色道久久88| 亚洲性感美女99在线| 国产精品成人av在线| 国产av精国产传媒| 久久精品一区二区三区av| 国产精品久久久影院| 天天免费亚洲黑人免费| 日韩丝袜美女视频| 精品人伦一区二区| 最新国产拍偷乱拍精品| 成人午夜小视频| 久热av在线| 亚洲图片欧美综合| 视频免费1区二区三区| 亚洲大片精品免费| 久久91精品国产| 一级二级三级视频| 久久综合久久综合久久综合| 91网站在线观看免费| 色猫猫成人app| 国产午夜精品久久久| 岛国毛片在线观看| 麻豆精品视频在线观看免费| 久久草.com| 国产亚av手机在线观看| 777精品伊人久久久久大香线蕉| 精品无码一区二区三区| 亚洲特色特黄| 999热视频| 黄色动漫在线观看| 欧美日韩精品一区二区三区蜜桃| 精品无码一区二区三区| 一本色道久久综合亚洲精品不| 91传媒视频在线观看| aiai在线| 欧美日韩综合在线免费观看| 国产全是老熟女太爽了| 亚洲欧美日韩一区在线观看| 国产精品久久久久久久久久久久午夜片| 国产精品一区二区三区视频网站| 在线视频国内自拍亚洲视频| 中文字幕5566| 国产欧美一区二区色老头 | 热99在线视频| 五月天激情婷婷| 图片区小说区区亚洲影院| 亚洲色图欧美日韩| 精品99视频| 国产美女在线精品免费观看| 黄页网站大全在线免费观看| 精品国产凹凸成av人导航| 久久久国产精华液| 成人免费视频国产在线观看| 国产二区视频在线| 久久精品福利| 欧美中文在线视频| 欧美在线一卡| 欧美色成人综合| 亚洲少妇xxx| 国产美女在线精品| 日韩精品一区二区免费| 亚洲性视频在线| 国外成人性视频| 四虎影视精品成人| 91精品福利视频| 黄色裸体一级片| 国产乱对白刺激视频不卡| 国内自拍中文字幕| 加勒比视频一区| 欧美在线观看一区二区三区| 国产视频精选在线| 欧美日韩在线一区二区| 国产一区二区播放| 成人免费视频视频在线观看免费 | 亚洲精品二三区| 极品国产91在线网站| 国产精品色一区二区三区| 亚洲一级片av| 亚洲国产国产亚洲一二三| 久久久久久精| 91精品国产自产观看在线| 久久999免费视频| 青青草免费在线| 欧美日韩国产123区| 久久久久无码国产精品| 91免费视频大全| 成 人 黄 色 小说网站 s色| 欧美欧美全黄| 日韩精品国内| 欧美视频三区| 日韩美女免费视频| 在线观看的网站你懂的| 亚洲男人第一网站| 国产日韩精品suv| 欧美小视频在线| 精品国产视频在线观看| 99精品热视频| 爱豆国产剧免费观看大全剧苏畅| 亚洲大胆在线| 成年人免费观看的视频| 精品视频自拍| 91精品久久久久久久久青青| a天堂资源在线| 精品国偷自产在线| 欧美黄色小说| 精品久久久久99| 亚洲视频在线免费播放| 午夜精品成人在线视频| 91麻豆免费视频网站| 国产午夜精品在线观看| 偷偷色噜狠狠狠狠的777米奇| 黄色小说综合网站| 欧美性猛交久久久乱大交小说| 激情91久久| 免费在线观看污污视频| 美女久久久久| 国产亚洲精品自在久久| 色综合久久久| 国产精品视频资源| 在线观看欧美日韩电影| 久久久久国产一区二区三区| 日本激情视频在线观看| 亚洲欧美制服综合另类| 午夜成人鲁丝片午夜精品| 欧美大胆一级视频| 国产精品久久久久毛片| 欧美伊人精品成人久久综合97 | 18网站在线观看| 色多多国产成人永久免费网站 | 九九视频精品全部免费播放| 国产精品二区在线观看| 国产精品1区在线| 国产在线视频不卡| 日本.亚洲电影| 国产精品999999| 台湾佬中文娱乐久久久| 日韩av片永久免费网站| 91精品产国品一二三产区| 7777精品视频| 黄色漫画在线免费看| 久久久久久12| 污视频在线免费观看网站| 久久av资源网站| 国产黄网站在线观看| 俺去亚洲欧洲欧美日韩| 麻豆传媒在线观看| 最新亚洲国产精品| 在线观看免费版| 中文字幕一区二区精品| 午夜在线视频播放| 日韩在线国产精品| 暖暖日本在线观看| 欧美成年人网站| 日本乱理伦在线| 欧美激情一区二区久久久| 国产啊啊啊视频在线观看| 久久青草精品视频免费观看| 俺来也官网欧美久久精品| 国内精品久久久久久久久| а√在线中文网新版地址在线| 97精品视频在线观看| 筱崎爱全乳无删减在线观看 | 蜜桃精品一区二区三区| 99re热精品| 欧美精品国产白浆久久久久| 欧美激情第六页| 欧美亚洲国产一区| 中文字幕一区二区三区乱码| 欧美在线资源| 免费在线观看视频a| 天使萌一区二区三区免费观看| 91n.com在线观看| 国产一区二区不卡老阿姨| 中文字幕人妻一区| 久久精品亚洲国产奇米99| 亚洲欧美另类日本| 亚洲一区二区在线免费看| 性无码专区无码| 欧美午夜影院一区| 精品女同一区二区三区| 欧美成va人片在线观看| 久久99久久| 欧美成人精品三级在线观看| 国产污视频在线播放| 国产精品入口夜色视频大尺度| 国产一区二区av在线| 精品免费二区三区三区高中清不卡| 欧美**vk| 青青视频免费在线观看| 国产欧美三级| 成人性生交视频免费观看| 99精品欧美一区二区蜜桃免费| 久久久久久成人网| 亚洲自拍欧美精品| 中文字幕免费播放| 亚洲国产日韩欧美在线图片| 免费a级在线播放| 1769国产精品| 国产精品亚洲四区在线观看| 麻豆av福利av久久av| 91不卡在线观看| 日本精品一区二区三区四区| 国产在线一区二区综合免费视频| 日本少妇色视频| 尤物视频一区二区| 成人午夜淫片100集| 日韩精品资源二区在线| 成人欧美亚洲| 91av在线影院| 在线精品自拍| 中文字幕欧美人与畜| 丝袜国产日韩另类美女| 国产日韩欧美综合一区| 麻豆一区在线观看| 精品国产福利在线| www香蕉视频| 久久久91精品国产一区不卡| 视频二区不卡| 国产一区二区三区四区五区加勒比 | 欧美一区二区国产| 国产精品麻豆一区二区三区| 欧美精品福利在线| 精品一区二区三区视频在线播放 | 国产一级二级三级在线观看| 羞羞色国产精品| 中文字幕日韩在线| 精品日韩在线播放| 麻豆91在线观看| 手机看片福利视频| 欧美特黄级在线| 西西人体44www大胆无码| 欧美激情三级免费| 亚洲2区在线| 亚洲精品国产suv一区88| 久久国产夜色精品鲁鲁99| 国产123在线| 欧美亚一区二区| av在线三区| 国产精品日韩在线| 精品视频亚洲| 国产精品拍拍拍| 国产免费久久精品| 波多野结衣午夜| 国产亚洲精品久久久优势 | 尤物网精品视频| 久草视频福利在线| 五月天激情小说综合| 天堂中文字幕在线| 国产91精品不卡视频| 伊人久久大香线蕉综合网站| 欧美激情成人网| 亚洲国产经典视频| 在线免费观看日韩视频| 日韩中文字幕在线精品| 成人黄色理论片| 日本一区午夜艳熟免费| 99热这里都是精品| 日本午夜视频在线观看| 亚洲欧美国产一本综合首页| 色豆豆成人网| 欧美aaa在线观看| 国产999精品久久久久久| 国产精品500部| 国产亚洲视频在线观看| 欧洲午夜精品| 成人精品视频在线播放| 久久这里都是精品| 伊人免费在线观看| 操人视频在线观看欧美| h视频久久久| 亚洲欧美另类动漫| 亚洲欧美激情一区二区| 免费看国产片在线观看| 日本在线观看天堂男亚洲| 欧美高清视频手机在在线| 欧美体内she精高潮| 欧美日韩午夜剧场| 一广人看www在线观看免费视频| 亚洲综合国产精品| 99视频精品免费观看| 婷婷综合在线视频| 欧美v日韩v国产v| 日本精品不卡| 超碰10000| 久久久精品国产免大香伊| 国产免费高清av| 日本精品久久电影| 一区二区三区在线| 99久久久久久久久久| 欧美视频你懂的| 波多野结衣在线高清| 国产精品亚洲一区二区三区| 欧美久久综合| 国产精品情侣呻吟对白视频| 日韩三级精品电影久久久| 嫩草伊人久久精品少妇av杨幂| 国产又大又长又粗又黄| 久久色在线视频|