大規模分布式系統的彈性測試_第1頁
大規模分布式系統的彈性測試_第2頁
大規模分布式系統的彈性測試_第3頁
大規模分布式系統的彈性測試_第4頁
大規模分布式系統的彈性測試_第5頁
已閱讀5頁,還剩19頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1/1大規模分布式系統的彈性測試第一部分分布式系統彈性測試的概念 2第二部分彈性測試框架的分類 4第三部分故障注入測試技術 7第四部分壓力和性能測試方法 11第五部分容量規劃和預測 13第六部分測試用例設計策略 16第七部分測試環境構建與管理 18第八部分彈性測試報告與分析 20

第一部分分布式系統彈性測試的概念關鍵詞關鍵要點分布式系統彈性測試的概念:

主題名稱:彈性測試定義

1.彈性測試評估分布式系統在故障、延遲或其他中斷條件下的生存能力。

2.該過程模擬真實世界場景,例如節點故障、網絡延遲和負載激增,以衡量系統適應性和恢復性。

主題名稱:彈性測試目標

分布式系統彈性測試的概念

一、彈性測試的定義

彈性測試是一種軟件測試方法,旨在評估分布式系統應對中斷、故障和性能挑戰時的能力。它側重于驗證系統在各種壓力下保持可用性和功能性。

二、分布式系統的特點

分布式系統由跨多個物理或虛擬位置分布的組件組成,這些組件通過網絡相互通信。它們具有以下特點:

*分布式組件:系統由多個獨立的組件組成,負責特定任務。

*異構性:組件可能在不同的硬件、軟件和操作系統上運行。

*通信依賴性:組件需要通過網絡進行通信以交換數據。

*并發性:多個組件可以同時執行任務。

三、分布式系統彈性測試的挑戰

*分布式通信中斷:網絡故障或慢速連接可能導致組件之間的通信中斷。

*組件故障:單個組件的故障可能會影響整個系統。

*資源耗盡:組件可能用完內存、CPU或存儲空間。

*并發爭用:多個組件同時訪問共享資源可能導致死鎖或性能下降。

*級聯故障:單個組件的故障可能會觸發其他組件的故障,導致系統故障。

四、分布式系統彈性測試的目標

*評估系統對中斷和故障的適應能力。

*測量系統在壓力下的恢復時間和數據完整性。

*識別系統設計和實現中的弱點。

*提高系統可用性和魯棒性。

五、分布式系統彈性測試技術

故障注入測試:通過人為地觸發故障來評估系統響應。

負載測試:施加載荷或壓力來模擬真實世界的負載,并評估系統性能和可伸縮性。

混沌測試:隨機引入故障和錯誤,以模擬難以預測的現實場景。

6.分布式系統彈性測試的度量

*平均恢復時間(MRT):系統從故障中恢復所需的時間。

*數據完整性:測試期間數據丟失或損壞的程度。

*可用性:系統在指定時間內保持可訪問的百分比。

*吞吐量:系統在壓力下處理請求的速率。

*響應時間:系統響應請求所需的時間。

七、分布式系統彈性測試的最佳實踐

*自動化測試:使用自動化工具來實現快速和可重復的測試。

*多階段測試:將測試分為多個階段,從基本故障注入到復雜的混沌測試。

*現實場景模擬:構建模擬真實世界負載和故障的測試場景。

*持續監控:在測試期間監測系統指標和日志,以便快速識別問題。

*與開發人員合作:在測試過程中與開發人員合作,以識別和解決系統設計和實現中的問題。

通過遵循這些最佳實踐,可以有效地測試分布式系統的彈性,并提高其對中斷、故障和性能挑戰的適應能力。第二部分彈性測試框架的分類關鍵詞關鍵要點主題名稱:基于云的彈性測試框架

1.利用云計算平臺的彈性資源池,按需分配和釋放測試資源,實現測試規模的靈活擴展。

2.支持異構云環境,允許在不同的云平臺上運行測試,提高測試覆蓋范圍和可靠性。

3.集成云原生服務,例如自動伸縮、負載均衡和監控,簡化測試環境管理和自動化測試流程。

主題名稱:基于容器的彈性測試框架

彈性測試框架的分類

彈性是分布式系統中至關重要的屬性,它決定了系統在面對故障、流量激增和其他動態變化時維持可用性和性能的能力。為了評估和驗證彈性,需要采用專門的測試框架。

根據實施方式和測試目標,彈性測試框架可以分為以下幾類:

1.故障注入框架

故障注入框架通過人為地注入故障來模擬系統故障,從而評估系統的容錯性。這些框架允許用戶創建各種自定義故障場景,如節點故障、網絡中斷和延遲。通過注入故障并觀察系統的響應,可以識別單點故障和恢復機制的有效性。

常用的故障注入框架包括:

*ChaosMonkey:由Netflix開發,主要用于測試云計算環境中的彈性。

*Gremlin:一個開源框架,支持廣泛的故障類型,包括機器故障、網絡問題和服務依賴性故障。

*FTL(FaultToleranceLayer):一種低開銷的故障注入框架,可以集成到各種應用程序中。

2.流量測試框架

流量測試框架通過向系統施加高流量負載來評估其可擴展性和容錯能力。這些框架允許用戶生成和控制大量模擬請求,從而觀察系統在不同負載條件下的性能。通過逐步增加流量并監控系統指標,可以識別瓶頸、性能限制和響應時間惡化。

常用的流量測試框架包括:

*Siege:一個命令行工具,用于對Web服務器進行壓力測試。

*Jmeter:一個開源框架,用于執行各種負載測試和性能測試場景。

*Taurus:一個現代化的負載測試平臺,支持多種協議和工具集成。

3.彈性探測框架

彈性探測框架提供持續的監視和檢測機制,以評估系統在實時條件下的彈性。這些框架收集系統指標、日志和事件,并使用分析技術識別異常和性能下降。通過持續監視,可以主動檢測問題并采取緩解措施,防止系統中斷。

常用的彈性探測框架包括:

*Hystrix:一個開源庫,用于實現彈性容錯模式,例如斷路器和超時。

*Micrometer:一個開源框架,用于收集和監控系統指標。

*Prometheus:一個開源監控系統,用于收集、存儲和查詢時間序列指標。

4.基于模型的框架

基于模型的框架利用數學模型和仿真技術來預測和評估彈性。這些框架構建系統的抽象模型,并使用分析或模擬方法來評估系統在不同故障場景和負載條件下的行為。通過預測分析,可以識別潛在的瓶頸和弱點,并制定緩解策略。

常用的基于模型的框架包括:

*SASSI(ScalableandExtensibleSystemsSimulationInfrastructure):一個開源工具包,用于構建和執行大規模分布式系統仿真。

*SimGrid:一個開源框架,用于模擬分布式計算環境中的復雜行為。

*OMNeT++:一個廣泛用于網絡仿真和建模的開源框架。

5.混合框架

混合框架結合了多個方法,例如故障注入、流量測試和基于模型的分析。這些框架提供全面的彈性評估,涵蓋靜態分析、動態測試和持續監視。通過結合不同的技術,混合框架可以提供更深入的見解和更全面的彈性評估。

常用的混合框架包括:

*ChaosToolkit:一個開源平臺,用于執行混沌工程實驗,包括故障注入、流量測試和彈性指標監視。

*ResiliencePlatform:一個商業平臺,提供故障注入、流量測試和指標分析的集成解決方案。

*Resilience360:一個云托管平臺,用于持續評估和管理云環境中的彈性。

根據特定的測試目標和系統架構,選擇適當的彈性測試框架至關重要。通過采用有效和全面的測試策略,組織可以確保其分布式系統具有應對故障、流量激增和其他挑戰的彈性。第三部分故障注入測試技術關鍵詞關鍵要點ChaosMonkey

1.隨機終止服務:ChaosMonkey隨機終止分布式系統中的實例,測試系統對實例故障的響應能力。

2.模擬現實故障:它模仿云環境中常見的故障類型,例如網絡中斷和硬件故障,提供更真實的測試場景。

3.持續測試:ChaosMonkey可配置為持續運行,不斷地引入故障,以評估系統的彈性在長期運行中的變化。

Gremlin

1.場景化測試:Gremlin允許用戶自定義故障場景,模擬特定類型的故障,例如延遲、丟包和異常響應。

2.可編程擴展性:它的Go生態系統提供了擴展性,允許用戶創建自己的測試和故障類型,以滿足特定需求。

3.故障緩解分析:Gremlin提供故障緩解分析工具,幫助用戶識別和修復系統中導致故障恢復延遲或失敗的瓶頸。

Pumba

1.網絡故障模擬:Pumba專注于模擬網絡分區、延遲和丟包等網絡故障,測試系統對網絡連接中斷的響應。

2.Kubernetes集成:與Kubernetes深度集成,允許用戶在Kubernetes集群中輕松部署和運行Pumba測試。

3.容器故障模擬:除了網絡故障外,Pumba還能夠模擬容器故障,例如容器掛起、重啟和終止。

MonkeyLord

1.分布式測試:MonkeyLord是一個分布式故障注入工具,允許用戶在分布式系統中同時引入多個故障。

2.故障協調:它提供故障協調機制,確保在系統不同組件之間引入協調和順序的故障。

3.故障可視化:MonkeyLord提供交互式可視化工具,幫助用戶跟蹤和分析故障注入過程中的系統行為。

ChaosBlade

1.云原生故障注入:ChaosBlade專為云原生環境而設計,支持對Kubernetes、Docker和其他云原生平臺進行故障注入。

2.豐富的故障場景:提供廣泛的故障場景庫,包括CPU、內存、網絡和存儲故障。

3.故障自愈評估:ChaosBlade可以評估系統在故障注入后的自愈能力,提供故障恢復和彈性的洞察。

ChaosLab

1.混沌工程平臺:ChaosLab是一個全面的混沌工程平臺,包括故障注入、性能測試和模擬工具。

2.故障庫管理:提供豐富的故障庫,允許用戶自定義和管理自己的故障場景。

3.故障影響分析:ChaosLab提供故障影響分析功能,幫助用戶了解故障對系統性能和可用性的影響。故障注入測試技術

故障注入測試是一種可控的測試方法,通過故意在系統中引入故障,來評估系統對這些故障的反應能力和恢復能力。通過模擬各種故障場景,故障注入測試可以幫助識別系統中的薄弱點并驗證其彈性。

#故障注入方法

故障注入測試可以使用多種方法進行,包括:

*硬件故障注入:通過物理手段,如拔插設備或短路線路,來模擬硬件故障。

*軟件故障注入:通過修改軟件代碼或注入錯誤,來模擬軟件故障。

*網絡故障注入:通過斷開網絡連接或引入延遲,來模擬網絡故障。

*人為故障注入:通過人為操作,如錯誤配置或數據破壞,來模擬人為故障。

#故障注入工具

故障注入測試通常使用專門的工具來執行。這些工具可以自動化故障注入過程,并提供可視化和分析功能。流行的故障注入工具包括:

*ChaosMonkey:用于在分布式系統中注入虛擬機故障。

*Gremlin:用于在各種云環境中注入故障。

*ResilienceShield:用于在Kubernetes集群中注入故障。

*ChaosBlade:用于在Kubernetes和Serverless環境中注入故障。

#故障注入流程

故障注入測試通常按以下流程進行:

1.故障定義:確定要注入的故障類型和嚴重程度。

2.故障注入:使用故障注入工具或技術注入故障。

3.系統監控:使用監控工具監控系統在故障注入期間的響應。

4.故障驗證:確認故障是否成功注入,并驗證系統的行為是否符合預期。

5.恢復驗證:評估系統從故障中恢復的能力和時間。

6.分析和改進:分析測試結果,識別薄弱點并制定改進措施。

#故障注入測試的優點

故障注入測試提供了以下優點:

*提高系統彈性:通過發現和緩解薄弱點,提高系統對故障的抵抗力。

*驗證彈性機制:驗證容錯、故障轉移和自動恢復機制的有效性。

*識別單點故障:識別系統中對單個故障點高度依賴的組件。

*優化故障處理策略:根據測試結果,優化故障處理策略和恢復時間目標(RTO)。

*提高信心:通過證明系統能夠承受故障,提高團隊對系統彈性的信心。

#故障注入測試的局限性

故障注入測試也有一些局限性:

*可能破壞生產系統:如果故障注入操作不當,可能會損壞生產系統。

*難以模擬復雜的故障:并非所有故障場景都可以通過故障注入技術準確模擬。

*時間和資源密集:全面故障注入測試需要大量時間和資源。

*可能需要專門的工具和專業知識:實施故障注入測試需要專門的工具和專業知識。

*結果解讀難度大:分析故障注入測試結果可能是復雜且費時的。

#結論

故障注入測試是一種有價值的技術,用于評估大規模分布式系統的彈性。通過模擬各種故障場景,故障注入測試可以幫助識別薄弱點、驗證彈性機制并提高系統的整體彈性。然而,故障注入測試也需要謹慎使用,并應與其他測試方法相結合,以獲得全面且準確的系統評估。第四部分壓力和性能測試方法關鍵詞關鍵要點主題名稱:負荷測試

1.模擬真實用戶訪問模式,逐漸增加請求量直至系統臨界點,評估系統吞吐量、響應時間和錯誤率。

2.可使用分布式負載發生器,如JMeter、Gatling,以從多個服務器同時發送請求,真實地模擬生產環境。

3.通過監控關鍵指標(如CPU、內存、帶寬)和應用程序日志,分析系統在高負載下的表現。

主題名稱:容量測試

壓力和性能測試方法

壓力測試和性能測試是評估分布式系統彈性至關重要的技術。它們通過向系統施加高負載來揭示系統在極限條件下的行為。

壓力測試

壓力測試旨在確定系統在高負載下失效的臨界點。其目的是確定系統的最大容量和穩定性極限。壓力測試通常涉及以下步驟:

*遞增負載:逐步增加系統上的負載,直到達到預定義的極限或系統失效。

*監視指標:密切監視關鍵系統指標,例如吞吐量、響應時間和資源利用率。

*分析結果:識別系統失效點,分析導致故障的因素,并制定緩解措施。

性能測試

性能測試評估系統在典型負載下的性能。其目的是確定系統的響應時間、吞吐量和資源利用率等關鍵指標。性能測試通常涉及以下步驟:

*模擬真實流量:使用真實或模擬的流量來模擬典型的系統負載。

*測量指標:收集關鍵性能指標,例如吞吐量、響應時間和錯誤率。

*基準測試:將性能結果與基準值或類似系統進行比較,以評估系統性能的相對表現。

*容量規劃:確定系統在不同負載下的處理能力,并制定容量規劃策略。

壓力和性能測試方法選擇

選擇適當的壓力和性能測試方法取決于系統的具體需求和測試目標。

*單服務器測試:適用于測試單個服務器或服務的性能和穩定性。

*多服務器測試:適用于測試分布式系統中的服務器和組件之間的交互。

*基于場景的測試:使用一組預定義的場景來模擬系統的真實世界負載。

*基于負載的測試:通過施加預定義的負載模式來測試系統的性能。

*混沌測試:對系統進行不可預測和隨機的負載,以評估其在異常條件下的彈性。

最佳實踐

進行壓力和性能測試時,應遵循以下最佳實踐:

*確定測試目標:明確測試的目標和要評估的指標。

*制定測試計劃:定義測試場景、負載模式和監視策略。

*漸進式測試:逐漸增加負載,以逐步暴露系統中的瓶頸。

*全面監視:監視關鍵指標,以識別性能下降或故障點。

*自動化測試:自動化壓力和性能測試過程,以提高效率和可重復性。

*分析結果:分析測試結果,確定系統瓶頸,并制定緩解措施。

*重復測試:在不同的條件和配置下重復測試,以驗證緩解措施并持續監視系統性能。

通過遵循這些最佳實踐,可以有效利用壓力和性能測試來提高大規模分布式系統的彈性,確保其在高負載和異常條件下穩定可靠地運行。第五部分容量規劃和預測關鍵詞關鍵要點容量規劃

1.確定系統容量要求:分析用戶需求、業務負載和性能目標,確定系統所需的峰值容量和平均容量。

2.選擇合適的容量規劃方法:評估靜態方法(如基準測試)和動態方法(如隊列論)的優點和缺點,選擇最適合系統的容量規劃方法。

3.考慮容量的可擴展性:設計系統以應對不斷增長的負載,考慮自動伸縮機制和彈性基礎設施,以確保系統能夠滿足未來需求。

容量預測

1.使用歷史數據進行預測:收集系統負載和性能指標的歷史數據,分析趨勢和模式,為未來的容量需求建立預測模型。

2.考慮季節性因素和異常情況:預測模型應考慮業務周期、季節性因素和異常事件對容量需求的影響。

3.持續監控和更新預測:隨著系統和業務不斷變化,建立一個持續監測和更新預測的流程,以確保預測準確性并及時調整容量規劃。容量規劃和預測

在進行彈性測試時,容量規劃和預測至關重要,它有助于確定系統在不同負載和事件下的性能表現。

容量規劃

容量規劃的目標是根據預期負載和服務水平協議(SLA)確定系統的容量要求。這需要考慮以下因素:

*硬件資源:CPU、內存、存儲和網絡帶寬

*軟件資源:應用程序、中間件和操作系統

*負載模式:峰值負載、平均負載和突發負載

*性能指標:響應時間、吞吐量和資源利用率

預測

在容量規劃的基礎上,預測涉及使用模型和分析技術來預測系統在未來時間內的性能。這可以幫助組織:

*預測潛在的瓶頸和性能問題

*識別需要擴展或優化的地方

*優化資源分配,以滿足不斷變化的負載

*主動規劃容量,以滿足未來的增長和需求

預測方法

有幾種預測方法可用于彈性測試:

*基準測試:使用代表性工作負載對系統進行基準測試,以確定其當前性能并建立基線。

*分析模型:使用數學模型和數據分析來預測系統性能,例如排隊論和性能建模。

*機器學習:利用歷史數據和模式識別算法來訓練機器學習模型,以預測未來的性能。

*仿真:創建系統的仿真模型,以模擬不同的負載和事件,并收集性能數據。

容量規劃和預測的最佳實踐

為了進行有效的容量規劃和預測,請考慮以下最佳實踐:

*使用多種方法:結合使用不同的方法,以獲得對系統性能的全面了解。

*定期更新:隨著系統和負載的不斷變化,定期更新容量規劃和預測。

*考慮各種場景:模擬和預測在不同負載、事件和故障情況下的系統行為。

*設置預警閾值:確定觸發警報和自動響應機制的資源利用率和性能指標閾值。

*實施彈性策略:實施自動擴展、負載均衡和故障轉移等彈性策略,以應對容量不足和事件。

結論

容量規劃和預測在彈性測試中至關重要,有助于組織了解系統的性能限制并主動規劃未來容量需求。通過使用多種方法、定期更新和考慮各種場景,組織可以確保系統在各種負載和事件下都能保持彈性。第六部分測試用例設計策略關鍵詞關鍵要點【測試用例設計策略】

1.測試覆蓋范圍:確保測試用例涵蓋系統所有關鍵功能、接口和組件。

2.測試深度:設計測試用例以驗證系統在各種負載、錯誤和故障條件下的行為。

3.故障注入:使用故障注入機制來模擬系統中的各種故障,例如網絡中斷、節點崩潰和數據損壞。

【故障場景識別】

測試用例設計策略

需求和場景分析

*分析系統需求文檔,識別關鍵場景和功能。

*確定故障場景和恢復機制,重點關注彈性方面。

*考慮不同負載、故障模式和環境下的影響。

基于風險的測試

*評估潛在故障場景的風險和影響。

*根據風險等級,優先考慮測試用例。

*專注于高風險和可能導致服務中斷或數據丟失的場景。

邊界值分析

*確定系統參數和資源的邊界值。

*設計測試用例以覆蓋邊界值,測試系統在極限條件下的行為。

*例如,最大用戶并發數、內存大小和存儲容量。

功能覆蓋

*確保測試用例覆蓋系統的所有關鍵功能。

*包括正向和負向測試,驗證正確的行為和錯誤處理。

*考慮不同輸入和輸出條件。

錯誤注入測試

*模擬故障或錯誤條件來測試系統的恢復能力。

*注入故障到關鍵組件(例如,網絡中斷、節點故障、數據損壞)。

*驗證系統是否能夠優雅地處理錯誤并恢復到正常狀態。

混沌測試

*采用隨機或不可預測的故障模式來測試系統。

*持續不斷地注入故障,模擬實際操作環境的混亂性。

*評估系統的適應性和彈性。

性能測試

*在有故障和正常情況下評估系統的性能。

*測量關鍵指標,例如響應時間、吞吐量和資源利用率。

*確定故障對性能的影響程度。

恢復和故障轉移測試

*測試故障轉移機制,驗證系統在故障期間能夠無縫恢復。

*模擬故障轉移事件,觀察系統恢復速度和數據完整性。

*評估故障轉移期間的性能和可用性。

集中式與分布式測試

*考慮分布式系統架構,設計適當的測試策略。

*使用集中式測試工具監控和協調跨多個節點的測試。

*分布式測試框架可以支持并行化和可擴展性。

自動化測試

*自動化測試用例以提高效率和覆蓋率。

*使用測試框架和工具編寫自動化腳本。

*定期執行自動化測試,以持續驗證系統的彈性。第七部分測試環境構建與管理關鍵詞關鍵要點測試環境構建

1.云平臺利用:充分利用云平臺的彈性、易擴展、按需付費等優勢,構建和管理分布式測試環境。

2.虛擬化技術:運用虛擬化技術隔離測試環境,實現資源共享、靈活配置和快速部署。

3.自動化工具:采用自動化工具(如Ansible、Terraform)進行環境配置和管理,提高效率和一致性。

測試環境管理

測試環境構建與管理

1.測試環境的類型

*開發環境:用于開發和測試代碼的本地環境。

*集成環境:用于集成不同組件和模塊的共享環境。

*測試環境:用于執行全面測試和性能分析的專門環境。

*預生產環境:用于在實際部署之前進行最終測試和驗證的環境。

*生產環境:實際部署系統運行的環境。

2.測試環境的構建

*自動化:使用自動化工具(如Terraform、Ansible)進行環境配置和管理。

*容器化:使用Docker或Kubernetes等技術將應用打包到容器中,實現快速部署和一致性。

*云原生:構建在云平臺(如AWS、Azure、GCP)之上,利用其可擴展性、靈活性、按需定價。

*持續集成和持續交付(CI/CD):集成代碼更改觸發自動構建、測試和部署。

3.測試環境的管理

資源管理:

*監控資源消耗(CPU、內存、存儲)。

*優化資源分配,確保測試穩定性。

*考慮云平臺的按需計費和伸縮能力。

版本控制:

*保持測試環境的版本化,以便進行回滾和故障排除。

*跟蹤環境變化,了解對系統行為的影響。

安全:

*遵循安全最佳實踐,如防火墻、訪問控制、數據加密。

*定期進行安全評估和漏洞掃描。

*限制對測試環境的訪問,防止未經授權的訪問。

監控和日志記錄:

*實時監控環境性能,包括響應時間、錯誤率、資源利用率。

*啟用日志記錄以跟蹤系統行為,進行故障排除和分析。

*設置告警機制在發生異常時通知相關人員。

數據管理:

*確保測試數據與生產數據一致,提供真實性的測試。

*使用數據掩碼技術保護敏感數據。

*定期備份和恢復測試數據,確保數據完整性。

4.測試環境的維護

*定期更新:保持測試環境與最新軟件版本和補丁同步。

*清理:刪除不再使用的組件和數據,釋放資源。

*重新配置:根據測試需求調整環境配置,包括負載生成器、監控工具。

*故障排除:迅速識別和解決環境問題,確保測試的順利進行。

5.最佳實踐

*使用云平臺的托管服務,簡化環境管理。

*采用基礎設施即代碼(IaC)工具,實現可重復和一致的環境配置。

*與開發團隊合作,確保測試環境反映生產環境。

*建立明確的測試環境管理指南和流程。

*定期審查和改進測試環境,以滿足不斷變化的需求。第八部分彈性測試報告與分析關鍵詞關鍵要點測試報告框架

1.建立清晰的報告結構,包括摘要、測試目標、測試環境、測試方法、測試結果和分析。

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論