999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

基于微服務(wù)架構(gòu)的電力公司管理信息系統(tǒng)

2020-10-13 09:37:40姚振王萍宮政劉濤唐軼軒
微型電腦應(yīng)用 2020年9期

姚振 王萍 宮政 劉濤 唐軼軒

摘 要: 針對電力公司管理信息系統(tǒng)所存在的可拓展性、可維護性較差以及在敏捷開發(fā)和快速部署方面的劣勢,提出采用Spring Cloud平臺、微服務(wù)架構(gòu)和輕量級容器技術(shù)相結(jié)合的以提升電力信息系統(tǒng)的持續(xù)集成和擴展能力的解決方案。其中微服務(wù)架構(gòu)是一種具有靈活的技術(shù)選擇、可獨立地按需擴展和高可用性的先進(jìn)架構(gòu);Spring Cloud作為開源技術(shù)架構(gòu)則為信息系統(tǒng)的微服務(wù)化提供全面的技術(shù)支持;而Dockers所代表的容器技術(shù)則為微服務(wù)架構(gòu)提供了一個獨立且不受干擾的部署環(huán)境。試驗表明,該解決方案具有計算效率好和運行穩(wěn)定的優(yōu)點。

關(guān)鍵詞: 微服務(wù); 管理信息系統(tǒng); Spring Cloud; Dockers

中圖分類號: TP 315 ? ? ?文獻(xiàn)標(biāo)志碼: A

Abstract: In view of the scalability, poor maintainability and disadvantages of agile development and rapid deployment of power company management information systems, this paper tries to improve the combination of Spring Cloud platform, micro service architecture and lightweight container technology. A solution for continuous integration and expansion capabilities of power information systems is proposed. The microservices architecture is an advanced architecture with flexible technology choices, independent on-demand scalability and high availability; Spring Cloud as an open source technology architecture provides comprehensive technical support for micro-services of information systems, and represented by Dockers the container technology provides an independent and undisturbed deployment environment for the microservices architecture. Tests have shown that this solution has the advantages of good computational efficiency and stable operation.

Key words: microservice; management information system; Spring Cloud; Dockers

0 引言

電力公司在信息化建設(shè)過程中,致力于通過將業(yè)務(wù)流程與信息技術(shù)的結(jié)合來提高管理效率。然而由于缺乏整體規(guī)劃和理論支持,導(dǎo)致電力公司管理信息系統(tǒng)的架構(gòu)出現(xiàn)以下三個特征:(1) 單片架構(gòu)成為主要的部署模式[1-3]。單片架構(gòu)軟件系統(tǒng)在開發(fā)的早期階段易于調(diào)試,運行簡單,易于部署。電力公司我們需要做的只是將打包的信息系統(tǒng)復(fù)制到服務(wù)器上。通過在負(fù)載均衡器的后端運行多個無狀態(tài)服務(wù)副本,可以很容易地實現(xiàn)應(yīng)用程序的橫向擴展,并且操作或維護的門檻很低。(2) 隨著需求的變化,電力公司管理信息系統(tǒng)逐漸變得復(fù)雜得多,新的開發(fā)人員無法弄清楚業(yè)務(wù)邏輯。因此,修復(fù)錯誤和添加新功能非常困難且耗時。最終,電力公司管理信息系統(tǒng)將陷入一個巨大的、難以理解的泥潭。(3) 傳統(tǒng)的系統(tǒng)開發(fā)模式在成本和效率上沒有優(yōu)勢,限制了電力公司的信息化發(fā)展。單片架構(gòu)的管理信息系統(tǒng)也使得采用新的體系結(jié)構(gòu)和編程語言變得非常困難。最終,電力公司無法通過非擴展,低可靠性應(yīng)用程序?qū)崿F(xiàn)敏捷開發(fā)甚至快速部署。為此,本文提出基于微服務(wù)架構(gòu)和輕量級容器技術(shù)進(jìn)行電力公司管理信息系統(tǒng)的開發(fā)以解決上述問題。

1 相關(guān)研究

微服務(wù)體系結(jié)構(gòu)(MSA)是一個提供了用于構(gòu)建復(fù)雜軟件系統(tǒng)的細(xì)粒度、自包含的服務(wù)組件(微服務(wù))的新興云軟件系統(tǒng)。基于SDLC(軟件開發(fā)生命周期)原則開發(fā)的電力公司管理信息系統(tǒng)所缺乏可擴展、可維護等諸多問題,促使電力公司管理信息系統(tǒng)從傳統(tǒng)的單片體系結(jié)構(gòu)遷移到MSA。文獻(xiàn)[4]提出了基于SDLC的遷移過程,包括設(shè)計、開發(fā)和實現(xiàn)過程中所需的所有方法和工具。

設(shè)計良好的微服務(wù)架構(gòu)和更好的質(zhì)量依賴于對相關(guān)質(zhì)量屬性的清晰理解。然而,目前對微服務(wù)體系結(jié)構(gòu)中質(zhì)量屬性的理解還不夠全面。文獻(xiàn)[5]通過系統(tǒng)文獻(xiàn)綜述(SLR)、探索性案例研究和解釋性調(diào)查構(gòu)建了建筑質(zhì)量屬性知識。通過分析相關(guān)質(zhì)量屬性的影響因素及相應(yīng)策略,旨在為微服務(wù)體系結(jié)構(gòu)的質(zhì)量改進(jìn)提供全面的指導(dǎo)。

文獻(xiàn)[8]介紹了使用相同的可擴展場景開發(fā)和部署的Web應(yīng)用程序與單片架構(gòu)、私有云運營的微服務(wù)架構(gòu)和由云提供商運營的微服務(wù)架構(gòu)三種不同方法的成本比較。測試結(jié)果表明,與標(biāo)準(zhǔn)單片式架構(gòu)相比,微服務(wù)可以幫助降低基礎(chǔ)架構(gòu)成本。此外,使用專門用于部署和擴展微服務(wù)的服務(wù)可將基礎(chǔ)架構(gòu)成本降低70%或更多。該研究還描述了實施和部署微服務(wù)信息系統(tǒng)的挑戰(zhàn)。

容器虛擬化以其能夠以靈活的方式部署和管理物聯(lián)網(wǎng)設(shè)備中的微服務(wù)正在成為一種被普遍使用的技術(shù)。文獻(xiàn)[6]關(guān)注物聯(lián)網(wǎng)設(shè)備中的微服務(wù)可靠性,并提出了一種基于容器虛擬化的系統(tǒng),該系統(tǒng)提供了物聯(lián)網(wǎng)云上所運行的微服務(wù)的故障容錯機制。

2 基于微服務(wù)架構(gòu)的信息系統(tǒng)

2.1 基本思路

為了減少電力公司信息系統(tǒng)中子系統(tǒng)之間的耦合,通常將系統(tǒng)分成多個組件,這有助于分離組件邊界和職責(zé)。程序員可以通過獨立地升級或維護系統(tǒng)。面向服務(wù)功能組件的主要目的是將不同編程語言實現(xiàn)的功能組件封裝到服務(wù)中。然后,用不同編程語言編寫的客戶端程序?qū)Ψ?wù)接口進(jìn)行跨語言和跨環(huán)境調(diào)用,功能組件服務(wù)和跨語言服務(wù)接口調(diào)用的效果,如圖1所示。

2.2 微服務(wù)架構(gòu)的設(shè)計原則

在電力公司管理信息系統(tǒng)開發(fā)的早期階段,信息系統(tǒng)通常采用提供服務(wù)列表的單片架構(gòu)S(s1,s2,…,sx),單片架構(gòu)示意圖如圖2所示。

由一組開發(fā)人員開發(fā)代碼。隨著應(yīng)用程序的擴展,將添加更多的服務(wù)或開發(fā)人員,從而增加了啟動新功能或改進(jìn)所需的復(fù)雜性和時間。

面向服務(wù)的體系結(jié)構(gòu)(SOA)[7]解決了電力公司管理信息系統(tǒng)復(fù)雜性所導(dǎo)致的可運維性、可拓展性較差的問題。電力公司管理信息系統(tǒng)由一系列單片架構(gòu)的信息系統(tǒng)(S1,S2,…,Sn)組成,每個信息系統(tǒng)通過不同的標(biāo)準(zhǔn)提供服務(wù)(如簡單對象訪問協(xié)議)。一些管理信息系統(tǒng)使用路由機制,例如企業(yè)服務(wù)總線(Enterprise Service Bus,ESB)[8]在各個電力公司管理信息系統(tǒng)之間路由和發(fā)送消息。SOA允許每個信息系統(tǒng)由按業(yè)務(wù)功能分組的不同開發(fā)團隊進(jìn)行獨立開發(fā),最后獨立開發(fā)的各個系統(tǒng)向SOA發(fā)布各自的服務(wù)接口,并由SOA向各個系統(tǒng)提供消息訂閱功能。

雖然SOA實現(xiàn)可以滿足某些電力公司管理信息系統(tǒng)的需求,但SOA存在非常復(fù)雜、昂貴,甚至耗時的問題[6]。SOA的一個典型實現(xiàn)是ESB,其被設(shè)計用于有效地支持具有大量用戶的電力公司管理信息系統(tǒng)。當(dāng)面臨將ESB擴展到數(shù)十萬或數(shù)百萬用戶的挑戰(zhàn)時,SOA將成為創(chuàng)建高延遲和增加單一故障點可能性的瓶頸。因此,根據(jù)需要向ESB添加或刪除服務(wù)器是很復(fù)雜的。至于敏捷性,在ESB中需要大量的配置來滿足最終用戶的新需求,這將耗費大量的時間。

作為SOA的一個輕量級子集,MSA(Micro Service Architecture)吸收了SOA體系結(jié)構(gòu)的優(yōu)點,避免了單片架構(gòu)的相應(yīng)問題。MSA是使用一組微服務(wù)構(gòu)建信息系統(tǒng)的解決方案。MSA由多個服務(wù)以單獨的業(yè)務(wù)單元的形式組成,并通過適當(dāng)?shù)募夹g(shù)圍繞指定的業(yè)務(wù)實現(xiàn)。每個微服務(wù)運行在一個獨立的進(jìn)程中,依賴于獨立的自動部署機制,形成一個邊界清晰、內(nèi)聚性高的自治單元;微服務(wù)通過一些輕量級的通信機制進(jìn)行通信,如RPC、HTTP等[9-10]。

為此,建議將管理信息轉(zhuǎn)換為一組微服務(wù)MS(MS1,MS2…msn),每個微服務(wù)都是提供服務(wù)的子集(s1,s2…sx)。開發(fā)團隊使用技術(shù)棧(包括表示層、服務(wù)層和持久層)獨立地開發(fā)和測試這些微服務(wù),以便更適用于微服務(wù)提供的服務(wù)。開發(fā)團隊還負(fù)責(zé)在云計算iaas/paas解決方案上部署、擴展、操作和升級微服務(wù)[11-13]。在表示層中,使用表示狀態(tài)轉(zhuǎn)移(rest)發(fā)布服務(wù)[14]。微服務(wù)架構(gòu)如圖3所示。

Spring Cloud是一個旨在簡化信息系統(tǒng)的開發(fā)和部署過程的全新Web框架。Spring Cloud包含一組功能良好、基于Spring Boot的輕量級微服務(wù)組件。Spring Cloud的主要特性有服務(wù)發(fā)現(xiàn)管理、服務(wù)容錯、服務(wù)網(wǎng)關(guān)和服務(wù)配置、負(fù)載平衡和消息傳遞。在總線和服務(wù)跟蹤方面,Spring Cloud框架也有經(jīng)過良好測試和成熟的組件。

Spring Cloud完整架構(gòu)圖,如圖4所示。

Eureka實現(xiàn)了Spring Cloud中微服務(wù)的自動注冊和發(fā)布。Zuul用于動態(tài)路由和請求過濾。功能區(qū)是基于HTTP和TCP的客戶端負(fù)載平衡,從Eureka Registry獲取服務(wù)列表。 HyStrix是一種可以提高系統(tǒng)容錯能力的斷路器。Turbine是一種用于監(jiān)控微服務(wù)集群的工具。 Feign集成了Ribbon,為客戶端提供聲明性HTTP API。Spring Cloud Config為Spring Cloud框架系統(tǒng)提供統(tǒng)一的配置管理,并為服務(wù)器(Config Server)和客戶端(Config Client)提供支持。Spring Cloud總線的作用是將服務(wù)節(jié)點與輕量級消息代理(例如RabbitMQ)連接,并廣播配置文件的動態(tài)信息與服務(wù)之間的通信。Spring Cloud Sleuth集成了ZipKin,實現(xiàn)了微服務(wù)的監(jiān)控鏈路分析[15]。

微服務(wù)是一種先進(jìn)的體系結(jié)構(gòu),但在系統(tǒng)復(fù)雜性和服務(wù)的持續(xù)集成方面存在著不可避免的缺陷。因此,本文引入了Docker技術(shù)來彌補微服務(wù)架構(gòu)的上述缺陷。Docker是一個符合Apache2.0協(xié)議開源容器引擎,其使用輕量級虛擬化技術(shù)來實現(xiàn)資源隔離,并打包各種環(huán)境依賴項和應(yīng)用程序,以促進(jìn)應(yīng)用程序的移植和部署。本研究將微服務(wù)打包成單獨的Docker鏡像,然后將它們推入私有鏡像數(shù)據(jù)庫。每次部署服務(wù)時,都會從私有鏡像庫中提取相應(yīng)的鏡像,并根據(jù)預(yù)定的微服務(wù)運行鏡像。

2.3 實施技術(shù)

Spring Cloud框架是以Java語言為基礎(chǔ),以統(tǒng)一的通信標(biāo)準(zhǔn),將不同語言(如C++、.NET、Python、Matlab等)編寫的程序發(fā)布到微服務(wù)中。本文使用JNI(解決C++和Java通信問題)、進(jìn)程間通信和RPC(遠(yuǎn)程過程調(diào)用)等技術(shù)將底層系統(tǒng)通信接口作為Java程序的補充,從而解決了功能組件服務(wù)的通信問題。

一個簡單的服務(wù)組合示例,該示例由四個服務(wù)A、B、C和D組成。如圖5所示。

服務(wù)A獲取輸入數(shù)據(jù),數(shù)據(jù)可以由多個基本數(shù)據(jù)類型(整數(shù)、浮點數(shù))和復(fù)雜數(shù)據(jù)類型(數(shù)組)的組合;輸出(X,Y)是兩個基本數(shù)據(jù)類型的組合。在客戶端遠(yuǎn)程調(diào)用該服務(wù)組合之后,服務(wù)的內(nèi)部調(diào)用過程如下:

1) 服務(wù)A調(diào)用B.handle(數(shù)據(jù));

2) 服務(wù)B異步調(diào)用c.handle(data);

3) 服務(wù)B異步調(diào)用d.handle(data);

4) 服務(wù)C返回響應(yīng)X;

5) 服務(wù)D返回響應(yīng)Y;

6) 服務(wù)B在服務(wù)C和D都返回響應(yīng)之后返回響應(yīng)(x,y)。

構(gòu)建上述微服務(wù)的算法如下:

微服務(wù)構(gòu)建算法

1: mS ← 初始微服務(wù)列表

2: ts ← 微服務(wù)的時間閾值

3: S ← 功能列表

4: C ← 代碼庫

5: for s in S

6: c ← 在C中完成的代碼

7: mS.add(c)

8: end for

9: for mSi,mSj in mS

10: if correlation(mSi,mSj) > ts

11: mSi = merge(mSi,mSj)

12: end if

13: end for

使用Docker后微服務(wù)框圖,如圖6所示。

這四個微服務(wù)A、B、C和D獨立部署在Docker容器中,微服務(wù)A發(fā)起調(diào)用微服務(wù)B的請求,微服務(wù)B異步調(diào)用微服務(wù)C和D。這創(chuàng)建了一個復(fù)雜而完整的業(yè)務(wù)處理流程。將復(fù)雜的應(yīng)用系統(tǒng)拆分為多個服務(wù),每個服務(wù)具有單一功能和簡單的業(yè)務(wù)邏輯。每個微服務(wù)都在Eureka Server中注冊,微服務(wù)可以通過聲明性RESTful API調(diào)用。

3 實驗分析

實驗環(huán)境包括:配置Xeon處理器、16GB RAM的運行微服務(wù)的主機,在Linux3.9上運行Docker 1.6和Spring Cloud Dalston.SR5的主機,以及單獨運行每個容器的主機。試驗選擇了WSO2產(chǎn)品作為試驗環(huán)境的服務(wù)總線。測試和比較單片架構(gòu)、ESB和本文所提的微服務(wù)架構(gòu)這三種體系結(jié)構(gòu)的性能。試驗所測量到服務(wù)時間的消耗包括(1) 用于請求服務(wù)的時間,(2) 用于接收響應(yīng)消息的時間(3) 用于解析服務(wù)響應(yīng)消息和描述的時間。為了獲得準(zhǔn)確的數(shù)據(jù),試驗啟動了多個重復(fù)調(diào)用請求。

如前所述,使用SpringCloud框架將電力公司管理信息系統(tǒng)重構(gòu)為未耦合的微服務(wù),并通過Docker技術(shù)將它們部署到服務(wù)器上。在本試驗中,使用四個微服務(wù)作為實驗條件。微服務(wù)A負(fù)責(zé)購電成本和銷電價格的查詢。微服務(wù)B用于統(tǒng)計售電量。微服務(wù)C為購電合同的概述,如季度購電成本等。微服務(wù)D根據(jù)損益信息指定下一季度的購電計劃。

為了從中準(zhǔn)確評估這些微服務(wù)的運行性能,試驗在沒有加載管理系統(tǒng)的前提下反復(fù)運行這些微服務(wù),性能試驗結(jié)果,如表1所示。

試驗對不同系統(tǒng)架構(gòu)下管理信息系統(tǒng)的運行性能的反復(fù)測試的結(jié)果,如表2所示。

在不同服務(wù)調(diào)用數(shù)量下,三個系統(tǒng)架構(gòu)的運行性能的試驗數(shù)據(jù)對比如圖7所示。

通過分析表1、表2和圖7的試驗數(shù)據(jù),可以得出結(jié)論:由于內(nèi)部通信成本幾乎為零,單片架構(gòu)的平均時間開銷最小,平均運行時間為63.24 ms;對于微服務(wù)架構(gòu)和ESB,微服務(wù)架構(gòu)的平均時間損失為54.25 ms,優(yōu)于ESB的 65.42 ms,這使得使用微服務(wù)架構(gòu)重建電力公司管理信息非常合理。由圖7可知,隨著服務(wù)調(diào)用數(shù)量增長,微服務(wù)架構(gòu)沒有明顯下降,因此可以預(yù)見采用微服務(wù)架構(gòu)構(gòu)建電力公司管理信息系統(tǒng)將具有良好的運行穩(wěn)定性。

4 總結(jié)

隨著電力公司管理系統(tǒng)的規(guī)模越來越龐大,對快速響應(yīng)功能需求的要求越來越嚴(yán)格,傳統(tǒng)的軟件系統(tǒng)架構(gòu)已經(jīng)不能滿足需求。微服務(wù)架構(gòu)作為新興的系統(tǒng)架構(gòu)為軟件開發(fā)人員提供靈活的軟件構(gòu)建方法,可以有效應(yīng)對更頻繁的軟件更新和滿足更短的交付周期的需求,成為電力公司部署管理系統(tǒng)新的架構(gòu)選擇。本文闡述了Spring Cloud和Docker所構(gòu)建的系統(tǒng)架構(gòu)能夠?qū)崿F(xiàn)面向組件和面向服務(wù)的服務(wù)管理,增強了服務(wù)的持續(xù)集成和擴展能力。試驗也表明了該系統(tǒng)架構(gòu)具有計算效率良好,運行穩(wěn)定的優(yōu)勢。因此基于Spring Cloud和Docker的微服務(wù)架構(gòu)具有成為電力公司重構(gòu)管理信息系統(tǒng)的最佳解決方案的潛力。

參考文獻(xiàn)

[1] 李慧春,王成喜,朱曉旭.基于Docker的Linux在線實驗環(huán)境[J].實驗技術(shù)與管理,2019,36(3):47-50.

[2] 徐曉耘,左松林,倪妍妍.基于微服務(wù)架構(gòu)的電力營銷信息系統(tǒng)研究[J].信息技術(shù),2019(2):160-166.

[3] 劉曉東,趙曉芳,陳雅靜,等.基于服務(wù)能力模型的微服務(wù)彈性資源供給機制[J].高技術(shù)通訊,2019,29(1):1-11.

[4] 方意,朱永強,宮學(xué)慶.微服務(wù)架構(gòu)下的分布式事務(wù)處理[J].計算機應(yīng)用與軟件,2019,36(1):152-158.

[5] 趙子晨,朱志祥,蔣來好.構(gòu)建基于Dubbo框架的Spring Boot微服務(wù)[J].計算機與數(shù)字工程,2018,46(12):2539-2543.

[6] 張琦.基于Docker的CaaS管理平臺架構(gòu)研究與設(shè)計[J].計算機應(yīng)用與軟件,2018,35(11):33-41.

[7] 馮顯力,韋化,韋洪波,等.含微服務(wù)的調(diào)度自動化系統(tǒng)分布式實時數(shù)據(jù)庫[J].電力系統(tǒng)保護與控制,2018,46(21):138-144.

[8] 程偉華,周捷,趙亞.基于微服務(wù)架構(gòu)的電力系統(tǒng)拆分方法[J].信息技術(shù),2018,42(10):115-119.

[9] 徐琛杰,周翔,彭鑫,等.面向微服務(wù)系統(tǒng)的運行時部署優(yōu)化[J].計算機應(yīng)用與軟件,2018,35(10):85-93.

[10] 承林,王海寧,高春成.微服務(wù)在電力交易系統(tǒng)中的應(yīng)用研究[J].電網(wǎng)技術(shù),2018,42(2):441-446.

[11] 龍新征,彭一明,李若淼.基于微服務(wù)框架的信息服務(wù)平臺[J].東南大學(xué)學(xué)報(自然科學(xué)版),2017,47(S1):48-52.

[12] 張松,疏官勝,李京.容器微云監(jiān)控系統(tǒng)的設(shè)計和實現(xiàn)[J].中國科學(xué)技術(shù)大學(xué)學(xué)報,2017,47(8):627-634.

[13] 畢小紅,劉淵,陳飛.微服務(wù)應(yīng)用平臺的網(wǎng)絡(luò)性能研究與優(yōu)化[J].計算機工程,2018,44(5):53-59.

[14] 郝庭毅,吳恒,吳國全,等.面向微服務(wù)架構(gòu)的容器級彈性資源供給方法[J].計算機研究與發(fā)展,2017,54(3):597-608.

[15] 歐陽榮彬,王倩宜,龍新征.基于微服務(wù)的數(shù)據(jù)服務(wù)框架設(shè)計[J].華中科技大學(xué)學(xué)報(自然科學(xué)版),2016,44(S1):126-130.

(收稿日期: 2019.06.25)

主站蜘蛛池模板: 91视频国产高清| 中文字幕乱妇无码AV在线| 99久久精品美女高潮喷水| 精品少妇人妻av无码久久| 欧美日韩中文国产va另类| 88av在线| 亚洲不卡网| 亚洲免费毛片| 国模私拍一区二区| 一区二区三区国产精品视频| 国产亚洲精品91| 尤物精品视频一区二区三区| 91成人在线观看| 午夜天堂视频| 2021国产精品自产拍在线观看 | 国产在线91在线电影| 国产日韩欧美精品区性色| 亚洲国产精品日韩av专区| 亚洲欧美另类日本| 国产人人射| 国产精品网拍在线| a色毛片免费视频| 亚洲欧美成人| 69综合网| 欧美视频二区| 国产Av无码精品色午夜| 久久无码av一区二区三区| 亚洲国产91人成在线| 国产丰满成熟女性性满足视频| 亚洲av日韩av制服丝袜| 精品无码一区二区在线观看| 国产va在线观看免费| 精品第一国产综合精品Aⅴ| 真实国产精品vr专区| 亚洲无码电影| 亚洲国产AV无码综合原创| 91精品国产自产在线观看| 99草精品视频| 国产在线视频福利资源站| 一区二区三区四区日韩| 婷婷久久综合九色综合88| 国产无码在线调教| 久久这里只有精品66| 亚洲日本精品一区二区| 亚洲国产精品人久久电影| 久久久精品国产SM调教网站| 成年av福利永久免费观看| 最新午夜男女福利片视频| 精品久久久久久久久久久| 久久国产精品影院| 久久永久免费人妻精品| 先锋资源久久| 国内毛片视频| 国产第一页第二页| 日韩人妻精品一区| 国产女人综合久久精品视| 这里只有精品免费视频| 欧美一区福利| 人人艹人人爽| 一区二区理伦视频| 国产一级在线观看www色| 2048国产精品原创综合在线| 国产美女免费网站| 日韩美一区二区| 精品国产三级在线观看| 91午夜福利在线观看精品| 色久综合在线| 综合久久久久久久综合网| 国产69精品久久久久妇女| 色老头综合网| 日本尹人综合香蕉在线观看 | 国产一区三区二区中文在线| 亚亚洲乱码一二三四区| 免费A∨中文乱码专区| 亚欧美国产综合| 伊人久久综在合线亚洲91| 蜜臀av性久久久久蜜臀aⅴ麻豆 | 国产乱视频网站| 少妇人妻无码首页| 日韩欧美国产三级| 欧美区在线播放| 亚洲精品桃花岛av在线|