• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 181, 文章 - 2, 評(píng)論 - 85, 引用 - 0
            數(shù)據(jù)加載中……

            FastSOA:用 XML、XQuery 和本機(jī) XML 數(shù)據(jù)庫(kù)技術(shù)加速 SOA-----中間層 SOA 緩沖體系結(jié)構(gòu)的作用

            很多 SOA 實(shí)現(xiàn)都依賴于用 XML 定義的消息格式。結(jié)果,消息模式可能變得非常復(fù)雜、不兼容、難以維護(hù),甚至造成嚴(yán)重的可伸縮性和性能問(wèn)題。在本文中,F(xiàn)rank Cohen 將介紹如何通過(guò)在 SOA 中間層使用 XML、XQuery 和本機(jī) XML 數(shù)據(jù)庫(kù)技術(shù)來(lái)提高 SOA 性能的戰(zhàn)略和技術(shù)。

            很多軟件架構(gòu)師在面向服務(wù)體系結(jié)構(gòu)(SOA)設(shè)計(jì)中使用 XML,雖然沒(méi)有一種 SOA 標(biāo)準(zhǔn)要求在 SOA 中使用 XML 或者提供相關(guān)指南。因此,軟件開(kāi)發(fā)社區(qū)做了很多實(shí)驗(yàn)和調(diào)查來(lái)發(fā)現(xiàn)定義服務(wù)端點(diǎn)和消息定義(模式)的最佳方式。這些方法大多數(shù)都會(huì)帶來(lái)了糟糕的性能和可伸縮性。

            比如,最早提出用 SOA 實(shí)現(xiàn) ebXML 的 General Motors Corp.,其最初的設(shè)計(jì)使用的是 Universal Business Language (UBL),建立的 XML 消息有 150,000 字節(jié)到 10 兆字節(jié)甚至更大。2004 年,我的性能測(cè)試公司 PushToTest 認(rèn)為當(dāng)時(shí)的 Java? 應(yīng)用程序服務(wù)器沒(méi)有提供足夠的吞吐量,在 GM Web Services Performance Benchmark 研究中提出了可伸縮性和性能問(wèn)題。

            當(dāng)時(shí)基于 XML 的 Web 服務(wù)技術(shù)還非常新,我認(rèn)為新一代應(yīng)用程序服務(wù)器技術(shù)會(huì)解決性能問(wèn)題。但大部分問(wèn)題仍然存在。

            Web 服務(wù)吞吐量問(wèn)題和復(fù)雜的 XML

            2005 年,PushToTest 完成了一項(xiàng)新的 SOA 性能研究(請(qǐng)參閱參考資料)表明,在處理復(fù)雜的 XML 消息時(shí),使用當(dāng)前 Java 應(yīng)用程序服務(wù)器構(gòu)建的應(yīng)用程序其性能很差,不足以投入生產(chǎn)。是發(fā)現(xiàn)的問(wèn)題和以前研究中的問(wèn)題相同:

            • 簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議(SOAP)綁定(代理)低效而緩慢。
            • 每次請(qǐng)求都需要一組全新的資源(對(duì)象、CPU 和網(wǎng)絡(luò)帶寬)來(lái)處理響應(yīng)。沒(méi)有緩沖模式。
            • 使用關(guān)系數(shù)據(jù)庫(kù)技術(shù)存儲(chǔ) XML 數(shù)據(jù)非常慢而且沒(méi)有可伸縮性。
            為了了解這三個(gè)問(wèn)題,設(shè)想一下軟件開(kāi)發(fā)人員如何使用 J2EE 應(yīng)用程序服務(wù)器工具構(gòu)建和部署 XML 服務(wù)。


            圖 1. WSDL 定義的例子
            圖 1. WSDL 定義的例子

            雖然可以使用使用不同技術(shù)建立基于 XML 的 Web 服務(wù),但我發(fā)現(xiàn)多數(shù)開(kāi)發(fā)人員更愿意從服務(wù)的 Web Services Description Language (WSDL) 定義開(kāi)始。Java 應(yīng)用程序服務(wù)器提供了輸入 WSDL定義和生成代理類的工具。代理器接收 SOAP 請(qǐng)求并把請(qǐng)求轉(zhuǎn)發(fā)給 Java 對(duì)象或 Enterprise Java Bean (EJB) 進(jìn)行處理。SOAP 綁定(代理器)是一種 Java 類,可通過(guò) servlet 接口調(diào)用它。


            圖 2. Java 方法調(diào)用
            圖 2. Java 方法調(diào)用

            圖 2 說(shuō)明了 Web 服務(wù)消費(fèi)者如何向服務(wù)發(fā)出 SOAP 請(qǐng)求。SOAP 綁定對(duì) SOAP 消息體中的 XML 內(nèi)容進(jìn)行反序列化。這個(gè)過(guò)程需要進(jìn)行大量的處理,非常復(fù)雜,因?yàn)橄Ⅲw常常包含復(fù)雜的數(shù)據(jù)類型。比如,消費(fèi)者可能向服務(wù)發(fā)送包含多個(gè)值的散列表。SOAP 綁定需要解碼散列表的內(nèi)容,對(duì)每個(gè)值創(chuàng)建 Java 對(duì)象的實(shí)例。散列表還可能包含其他散列表,因此解碼 SOAP 消息內(nèi)容不是一件容易的事。如果不相信的話,請(qǐng)看一看 Apache Axis 反序列化器的源代碼。

            SOAP 綁定實(shí)例化包含 SOAP 消息體內(nèi)容的 Java Request 對(duì)象。SOAP 綁定調(diào)用目標(biāo)類中的目標(biāo)方法,并將 Request 對(duì)象作為參數(shù)傳遞。目標(biāo) EJB 或 Java 對(duì)象提供所有必要的處理來(lái)建立對(duì)請(qǐng)求的響應(yīng)。SOAP 綁定將 EJB 或 Java 對(duì)象返回的值序列化到 SOAP 響應(yīng)消息中。SOAP 綁定將響應(yīng)對(duì)象中的值解碼成能夠序列化到 SOAP 響應(yīng)消息中的值需要經(jīng)過(guò)同樣復(fù)雜的過(guò)程。

            通過(guò)研究用流行的 Java 應(yīng)用程序服務(wù)器工具創(chuàng)建的 SOAP 綁定,我發(fā)現(xiàn)了以下問(wèn)題:

            • 應(yīng)用程序服務(wù)器工具創(chuàng)建的 SOAP 綁定效率很低。比如,我發(fā)現(xiàn)某些 SOAP 綁定創(chuàng)建 SOAP 請(qǐng)求的多個(gè)副本,每個(gè)請(qǐng)求都實(shí)例化為 String 對(duì)象 —— 這樣做并沒(méi)有明顯的理由。一些 SOAP 綁定創(chuàng)建了 15,000 個(gè) Java 對(duì)象來(lái)反序列化消息體中包含 500 個(gè)元素的 SOAP 請(qǐng)求。
            • 在配備有雙 CPU 3.0 GHz Intel Xeon 處理器的服務(wù)器上,我發(fā)現(xiàn)在處理有效負(fù)荷 10,000 字節(jié)、包含 50 個(gè)元素的簡(jiǎn)單 SOAP 消息時(shí),每秒處理的事務(wù)為 15 到 20 個(gè)(TPS)。隨著 SOAP 消息復(fù)雜性和大小的增加,我發(fā)現(xiàn)會(huì)造成明顯的伸縮性和性能問(wèn)題。有效負(fù)荷 100,000 字節(jié)、包含 750 個(gè)元素的 SOAP 消息會(huì)把吞吐量降低到 1.5 TPS。SOAP 消息體中元素個(gè)數(shù)越多,每個(gè)元素嵌套越深,問(wèn)題就會(huì)越嚴(yán)重。

            性能問(wèn)題在 SOA 設(shè)計(jì)中會(huì)引起連鎖反應(yīng)。SOA 是一種組件軟件重用技術(shù)。一個(gè)服務(wù)通常調(diào)用其他服務(wù)來(lái)確定對(duì)消費(fèi)者請(qǐng)求的響應(yīng),從而形成一個(gè)調(diào)用鏈。


            圖 3. 消費(fèi)者
            圖 3. 消費(fèi)者

            不僅僅是一個(gè)服務(wù)的性能問(wèn)題,每個(gè)服務(wù)在序列化、反序列化請(qǐng)求和響應(yīng)的時(shí)候都會(huì)增加同樣的開(kāi)銷(xiāo)。隨著服務(wù)調(diào)用層次的增加,性能問(wèn)題也成倍增加。

            加快 SOA 失去的機(jī)會(huì)

            除了 SOAP 綁定代理速度慢的問(wèn)題,SOA 設(shè)計(jì)還常常忽略或者忽視另外兩個(gè)問(wèn)題。

            首先,SOA 設(shè)計(jì)常常忽視了用中間層服務(wù)緩沖來(lái)提高 SOA 性能的可能性。比如多數(shù) SOA 設(shè)計(jì)中的 XML 模式都定義了了響應(yīng)的 time-to-live 值。在這種情況下,緩沖服務(wù)響應(yīng)并在服務(wù)再次收到同樣的請(qǐng)求時(shí)重新使用緩沖的響應(yīng)是一種提高 SOA 服務(wù)性能的合理而適當(dāng)?shù)姆椒ā?/p>

            其次,在 SOA 性能測(cè)試中,我嘗試了各種不同的 XML 消息解析方法,其中包括 Streaming API for XML (StAX)、XML 綁定編譯器、Java Architecture for XML Binding (JAXB) 和 Document Object Model (DOM) 技術(shù)。一些技術(shù)的性能要優(yōu)于另一些。比如,很多 StAX 解析器能夠提供比 DOM 解析器快 2 到 10 倍的性能。

            我懷疑如果使用其他東西而不是 Java 對(duì)象來(lái)提供 SOAP 綁定是否能夠改進(jìn)性能。比如,如果收到的 SOAP 請(qǐng)求在本機(jī) XML 環(huán)境中處理,那么基于 Java 的 SOAP 綁定就不再是必需的了,同時(shí)還可以避免因?yàn)樾蛄谢?Java 對(duì)象而導(dǎo)致的性能降低。

            此外,一些本機(jī) XML 環(huán)境使用 Java Virtual Machine 環(huán)境,但會(huì)避免構(gòu)造 Java 對(duì)象。比如,Raining Data 的 TigerLogic XDMS 和 Kawa/Qexo 通過(guò)將 XQuery 查詢直接轉(zhuǎn)換成 Java 字節(jié)碼來(lái)實(shí)現(xiàn) XML 處理代碼。這樣做是因?yàn)榕c使用 Java 對(duì)象相比,使用 XQuery 字節(jié)碼實(shí)現(xiàn)的 XML 處理代碼的吞吐量更大,代碼更短。

            FastSOA 解決方案

            FastSOA 是解決這些問(wèn)題的一種體系結(jié)構(gòu)和軟件編碼實(shí)踐:

            • FastSOA 通過(guò)減少 Java 對(duì)象的需要,更多使用本機(jī) XML 環(huán)境提供 SOAP 綁定來(lái)解決 SOAP 綁定(代理)性能問(wèn)題。
            • FastSOA 引入了中間層服務(wù)緩沖來(lái)加快 SOA 服務(wù)。
            • FastSOA 使用本機(jī) XML 持久性來(lái)避免 XML 到關(guān)系數(shù)據(jù)庫(kù)的轉(zhuǎn)換造成的性能問(wèn)題。

            下圖顯示了 FastSOA 體系結(jié)構(gòu)。


            圖 4. FastSOA 體系結(jié)構(gòu)
            圖 4. FastSOA 體系結(jié)構(gòu)

            FastSOA 體系結(jié)構(gòu)與現(xiàn)有的基于 Web 的基礎(chǔ)結(jié)構(gòu)結(jié)合在一起,作為中間層緩沖部署來(lái)接收服務(wù)消費(fèi)者的請(qǐng)求。比如,一個(gè)消費(fèi)者向服務(wù)發(fā)出 SOAP 請(qǐng)求。中間層緩沖提供 SOAP 綁定(代理)。綁定調(diào)用 XQuery 在 XQuery 引擎處理 XML 請(qǐng)求文檔。XQuery 檢查緩沖,查看以前是否收到該請(qǐng)求;在這種情況下,F(xiàn)astSOA 服務(wù)可以從緩沖中返回響應(yīng),不需要逆流而上再請(qǐng)求服務(wù)。該過(guò)程通過(guò)緩沖加快 SOA 執(zhí)行從而實(shí)現(xiàn)了 SOA 提速。

            FastSOA 方法的優(yōu)點(diǎn)包括:

            • 服務(wù)端點(diǎn)是標(biāo)準(zhǔn)的。對(duì)于應(yīng)用程序的其他部分而言,F(xiàn)astSOA 中間層緩沖就像是一種服務(wù)。
            • 不需要修改現(xiàn)有的系統(tǒng)或代碼。FastSOA 中間層緩沖作為一種數(shù)據(jù)聚合和遷移服務(wù)嵌入到已有的數(shù)據(jù)中心。
            • 如果上游服務(wù)暫時(shí)不能用,當(dāng)服務(wù)離線的時(shí)候,F(xiàn)astSOA 方法提供了一種瀏覽緩沖數(shù)據(jù)的機(jī)制。
            • 通過(guò)緩沖服務(wù)的請(qǐng)求降低了為支持消費(fèi)者和服務(wù)之間的通信通常所需的帶寬要求。

            為了從實(shí)踐的角度理解 FastSOA,考慮下面的應(yīng)用程序。

            XML 的例子

            General Motors 采用 SOA 模式創(chuàng)建服務(wù),讓汽車(chē)代理商使用基于 ebXML 的模式和協(xié)議從生產(chǎn)廠家訂購(gòu)零部件。該服務(wù)能夠識(shí)別 Software Technology in Automotive Retailing (STAR) 組織的一種 XML 模式。STAR 是大型汽車(chē)廠商共同努力的結(jié)果,其中包括 GM。STAR 創(chuàng)建并維護(hù) Business Object Document (BOD) 模式,定義了目錄檢查請(qǐng)求(以及其他許多東西)。

            CheckInventory 請(qǐng)求檢查請(qǐng)求者和目錄的級(jí)別與狀態(tài)。服務(wù)消費(fèi)者根據(jù) STAR 模式創(chuàng)建目錄請(qǐng)求文檔。消費(fèi)者將文檔編組成請(qǐng)求,并通過(guò)網(wǎng)絡(luò)發(fā)送給服務(wù)。服務(wù)發(fā)回目錄狀態(tài)響應(yīng)說(shuō)明庫(kù)存中有哪些零部件。

            通過(guò)降低網(wǎng)絡(luò)帶寬的需要和減少為了響應(yīng)冗余請(qǐng)求而造成的服務(wù)帶寬需要,零件訂購(gòu)服務(wù)可以從 FastSOA 模式中受益。

            比方說(shuō),汽車(chē)零售商的零件目錄響應(yīng)中包含一個(gè) Time-To-Live (TTL) 元素。TTL 元素定義了響應(yīng)有效的秒數(shù)。比如 GM 可能將其設(shè)為 60 秒。在這 60 秒內(nèi),F(xiàn)astSOA 用中間層存儲(chǔ)的目錄響應(yīng)緩存響應(yīng)目錄請(qǐng)求。這樣服務(wù)就減少了帶寬的使用,并縮短了請(qǐng)求響應(yīng)時(shí)間。

            下表說(shuō)明了如何計(jì)算網(wǎng)絡(luò)中的服務(wù)提速效果,這些服務(wù)位于本地網(wǎng)絡(luò)之外的服務(wù)器上,F(xiàn)astSOA 數(shù)據(jù)緩沖收集服務(wù)在本地網(wǎng)絡(luò)中。


            表 1. 計(jì)算服務(wù)加速效果
            動(dòng)作無(wú)緩沖2啟用緩沖2
            第一次請(qǐng)求處理的時(shí)間1765122181
            在緩沖中存儲(chǔ)請(qǐng)求的時(shí)間014531
            后續(xù)相同或冗余請(qǐng)求176513201
            使用的 Internet 帶寬30,400 K 字節(jié)304 K 位
            使用的總時(shí)間2941 分鐘533 分鐘

            1這里所有的時(shí)間都是毫秒,1 秒 = 1,000 毫秒。

            2假設(shè):

            • 消費(fèi)者和緩沖服務(wù)使用 100 M 以太網(wǎng)連接和 1.5 M 左右的 DSL 連接。
            • Time to Live (TTL) 為 60 秒。
            • 請(qǐng)求/響應(yīng)包含 38,000 個(gè)字節(jié)。
            • TTL 期間有 100,000 次請(qǐng)求。
            ?

            ??

            在 FastSOA 實(shí)現(xiàn)中,用 XQuery 實(shí)現(xiàn)零部件訂購(gòu)服務(wù)。XQuery 請(qǐng)求目錄服務(wù),讀取響應(yīng)的內(nèi)容,在運(yùn)行時(shí)確定是否可以使用以前存儲(chǔ)的響應(yīng)而不必再次請(qǐng)求目錄服務(wù)。

            這樣就在服務(wù)環(huán)境中實(shí)現(xiàn)了 FastSOA 數(shù)據(jù)緩沖收集體系結(jié)構(gòu)。XQuery 和本機(jī) XML 數(shù)據(jù)庫(kù)提供了重用以前緩沖響應(yīng)數(shù)據(jù)的服務(wù),只要請(qǐng)求與以前的請(qǐng)求匹配并且數(shù)據(jù)仍然不過(guò)時(shí)。結(jié)果是服務(wù)提速了。

            FastSOA 技術(shù)選擇

            可以使用 Java 代碼和關(guān)系數(shù)據(jù)庫(kù)技術(shù)實(shí)現(xiàn) FastSOA 體系結(jié)構(gòu)。但是,在測(cè)試使用 Java 對(duì)象創(chuàng)建的服務(wù)綁定和使用關(guān)系數(shù)據(jù)庫(kù)持久 XML 時(shí),我發(fā)現(xiàn)了重要的性能和可伸縮性問(wèn)題。這些問(wèn)題很突出,考慮使用 XQuery、XSLT 和本機(jī) XML 數(shù)據(jù)庫(kù)技術(shù)很有必要。

            我對(duì) XQuery 感興趣,是因?yàn)樗亲鳛閼?yīng)用程序開(kāi)發(fā)的本機(jī) XML 環(huán)境來(lái)實(shí)現(xiàn)的。與早期的 Java 技術(shù)非常相似,XQuery 社區(qū)充滿了擴(kuò)張和證明 XQuery 是一種開(kāi)發(fā)平臺(tái)的活力。實(shí)際上,多數(shù) XQuery 實(shí)現(xiàn)都經(jīng)過(guò)擴(kuò)展超出了 XQuery 標(biāo)準(zhǔn),以便 XQuery 能夠進(jìn)行 SOAP 請(qǐng)求。比如,XQuery 可以查詢其他服務(wù)、J2EE 對(duì)象和通過(guò) JDBC、SOAP、JMS 協(xié)議查詢數(shù)據(jù)源。此外,已經(jīng)有 10 種或更多非常可靠的商業(yè)化和開(kāi)放源碼 XQuery 實(shí)現(xiàn)。

            最后,F(xiàn)astSOA 使用本機(jī) XML 數(shù)據(jù)庫(kù)作為中間層緩沖,因?yàn)?SOA 數(shù)據(jù)通常采用 XML 編碼格式,而關(guān)系數(shù)據(jù)庫(kù)在持久存儲(chǔ)和索引 XML 這樣的層次性非結(jié)構(gòu)化數(shù)據(jù)方面有很大不足。存儲(chǔ) XML 數(shù)據(jù)的關(guān)系數(shù)據(jù)庫(kù)通常使用大型二進(jìn)制對(duì)象(BLOB)字段類型存儲(chǔ) XML。不僅效率低,而且很難建立索引以便快速搜索。對(duì)于流數(shù)據(jù)采用關(guān)系方法通常也不是最佳辦法。如果在基于 Web 服務(wù)的網(wǎng)絡(luò)中發(fā)送 XML 消息,最好用基于流的方法處理該消息,而關(guān)系數(shù)據(jù)庫(kù)對(duì)此無(wú)能為力。

            FastSOA 的未來(lái)

            除了本文所述的 SOAP 綁定性能改進(jìn)之外,采用中間層服務(wù)緩沖還會(huì)為企業(yè)帶來(lái)很多好處。其他好處包括中間層模式轉(zhuǎn)換、服務(wù)版本化、策略選路和服務(wù)質(zhì)量(QOS)處理。比如,F(xiàn)astSOA 提供了中間層 XML 消息模式轉(zhuǎn)換,以便保證需要不同和不兼容的消息類型的服務(wù)之間的兼容性。

            結(jié)束語(yǔ)

            本文考察了如何提升 SOA 的性能和可伸縮性,詳細(xì)介紹了在中間層使用 XQuery 支持結(jié)合 XML 持久的 SOA 設(shè)計(jì)所帶來(lái)的好處。FastSOA 設(shè)計(jì)結(jié)合使用了本機(jī) XML 持久性和 XQuery,因此每次收到服務(wù)調(diào)用時(shí),中間層都要決定是使用以前請(qǐng)求的緩沖值響應(yīng),還是傳遞請(qǐng)求。服務(wù)使用 XQuery 根據(jù)對(duì)服務(wù)請(qǐng)求元數(shù)據(jù)查詢的結(jié)果描述判定緩沖是否有效。

            posted on 2006-04-17 02:16 wsdfsdf 閱讀(206) 評(píng)論(0)  編輯 收藏 引用 所屬分類: 技術(shù)文章

            国内精品久久久久久中文字幕| 久久中文字幕无码专区| 日产精品久久久一区二区| 久久综合给合久久国产免费 | 精品久久久中文字幕人妻| 亚洲αv久久久噜噜噜噜噜| 青青青国产精品国产精品久久久久| 久久综合久久伊人| 久久亚洲春色中文字幕久久久 | 国产2021久久精品| 久久无码专区国产精品发布| 国产精品久久久久久| 一级女性全黄久久生活片免费 | 久久精品国产亚洲综合色| 久久久久国产一区二区| av无码久久久久不卡免费网站| 色诱久久av| 99久久综合狠狠综合久久| 少妇久久久久久久久久| 亚洲乱码日产精品a级毛片久久 | 久久无码人妻一区二区三区| 婷婷久久综合| 69久久夜色精品国产69| 色天使久久综合网天天| 久久一区二区三区免费| 国产成人AV综合久久| a高清免费毛片久久| 香蕉久久av一区二区三区| 深夜久久AAAAA级毛片免费看| 伊人久久免费视频| 国产国产成人精品久久| 久久久老熟女一区二区三区| 三级三级久久三级久久| 久久天天躁狠狠躁夜夜2020| 国产成人精品久久亚洲高清不卡| 国产一区二区三区久久| 91精品国产高清久久久久久io| 亚洲∧v久久久无码精品| 久久亚洲春色中文字幕久久久| 亚洲精品无码久久久影院相关影片| 一本久久a久久精品vr综合|