企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)設(shè)計(jì)難點(diǎn)探討_第1頁
企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)設(shè)計(jì)難點(diǎn)探討_第2頁
企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)設(shè)計(jì)難點(diǎn)探討_第3頁
企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)設(shè)計(jì)難點(diǎn)探討_第4頁
企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)設(shè)計(jì)難點(diǎn)探討_第5頁
已閱讀5頁,還剩4頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)設(shè)計(jì)難點(diǎn)探討

當(dāng)企業(yè)在面臨諸如需求迭代頻繁但是項(xiàng)目進(jìn)度推進(jìn)乏力、用戶量高速增長(zhǎng)但是系統(tǒng)出現(xiàn)瓶頸卻沒有好的解決方案,研發(fā)資源逐步增加但是團(tuán)隊(duì)協(xié)作效率卻變的遲緩的情況,雖然使用微服務(wù)架構(gòu)方案能解決所面臨的問題,而且目前微服務(wù)架構(gòu)的框架都比較成熟,例如Springcloud或者dubbo在各大互聯(lián)網(wǎng)平臺(tái)都有成功案例,然而看似簡(jiǎn)單的框架在實(shí)際開發(fā)過程中會(huì)面臨很多問題。問題一:企業(yè)從單體架構(gòu)往微服務(wù)架構(gòu)轉(zhuǎn)型怎么啟動(dòng)?這個(gè)問題也是本次活動(dòng)中大家比較關(guān)注的問題,追其根究主要是因?yàn)槠髽I(yè)打算轉(zhuǎn)型微服務(wù),但是真正的實(shí)施后發(fā)現(xiàn)又很難,其實(shí)微服務(wù)架構(gòu)轉(zhuǎn)型不僅僅是一門技術(shù)活,更主要的的是組織結(jié)構(gòu)和技術(shù)轉(zhuǎn)型的結(jié)合,其中組織機(jī)構(gòu)轉(zhuǎn)型是起步的首要條件,包括統(tǒng)一思路和充分培訓(xùn)。

(1)

思想統(tǒng)一

當(dāng)準(zhǔn)備要實(shí)施微服務(wù)的時(shí)候首要條件就是獲得高層的認(rèn)可,因?yàn)樯婕暗浇M織結(jié)構(gòu)的調(diào)整以及后續(xù)人力資源的增補(bǔ),比如在單體應(yīng)用中其組織機(jī)構(gòu)包括開發(fā)部、測(cè)試部、運(yùn)維部、DBA部,每個(gè)部門各司其職由高層統(tǒng)一指揮,看似很非常合理的組織結(jié)構(gòu),但是在項(xiàng)目或者迭代實(shí)際過程中會(huì)花費(fèi)大量的時(shí)間去跨部門溝通,形成了孤島式功能團(tuán)隊(duì)。但是在實(shí)施微服務(wù)的時(shí)候,希望能協(xié)同配合快速交付,如果還是需要多次跨部門協(xié)調(diào)處理問題的話,那么“微”很難實(shí)現(xiàn)“微”的好處,微服務(wù)的團(tuán)隊(duì)?wèi)?yīng)該是如下所示,所以如果沒有高層參與那么組織架構(gòu)就不會(huì)調(diào)整。(2)

充分培訓(xùn)

微服務(wù)開發(fā)關(guān)注點(diǎn):微服務(wù)架構(gòu)的開發(fā)人員具備“精”、“氣”、“神”的特質(zhì),否則在后續(xù)發(fā)展階段一定會(huì)出現(xiàn)各種難題?!熬笔侵甘煜I(yè)務(wù),熟悉選型的開發(fā)框架,“氣”是指大家的思想認(rèn)知一致,能夠在一個(gè)頻道上對(duì)話,“神”是指需要了解其理論知識(shí),明白為什么需要這樣而不是那樣。微服務(wù)在開發(fā)設(shè)計(jì)過程中需要關(guān)注以下點(diǎn):一份基準(zhǔn)代碼多份部署(deploy):程序部署需要做到和環(huán)境無關(guān),不需要改動(dòng)任何一行代碼,如圖2-3顯式聲明依賴關(guān)系:通過依賴清單,確切地聲明所有依賴項(xiàng)(例如MAVEN依賴),新進(jìn)開發(fā)者簡(jiǎn)化了環(huán)境配置流程“做產(chǎn)品”而不是“做項(xiàng)目”在環(huán)境中存儲(chǔ)配置:所要求的代碼和配置嚴(yán)格分離,配置可以完全不一樣,但是代碼必須是一樣的,配置和代碼無關(guān)“去中心化”地治理技術(shù)把后端服務(wù)當(dāng)作資源:后端服務(wù)是指程序運(yùn)行所需要的通過網(wǎng)絡(luò)調(diào)用的各種服務(wù)如數(shù)據(jù)庫,MQ,緩存等。例如在不進(jìn)行任何代碼改動(dòng)的情況下,將MySQL數(shù)據(jù)庫換成第三方服務(wù)嚴(yán)格分離構(gòu)建和運(yùn)行:構(gòu)建階段是指將代碼倉庫轉(zhuǎn)化為可執(zhí)行包的過程,發(fā)布階段會(huì)將構(gòu)建的結(jié)果和當(dāng)前部署所需配置相結(jié)合,并能夠立刻在運(yùn)行環(huán)境中投入使用,如回滾,運(yùn)行階段是指針對(duì)選定的發(fā)布版本,在執(zhí)行環(huán)境中啟動(dòng)一系列應(yīng)用程序進(jìn)程無狀態(tài)進(jìn)程運(yùn)行應(yīng)用:運(yùn)行環(huán)境中,應(yīng)用程序通常是以一個(gè)和多個(gè)進(jìn)程運(yùn)行的,任何需要持久化的數(shù)據(jù)都要存儲(chǔ)在后端服務(wù)內(nèi),比如數(shù)據(jù)庫問題二:微服務(wù)中所謂的服務(wù)到底如何拆分,服務(wù)拆分到什么粒度算好的服務(wù)?在談服務(wù)拆分之前首先給服務(wù)做個(gè)定義:服務(wù)是分布式架構(gòu)下的基礎(chǔ)單元,包含了一組特定的功能。微服務(wù)拆分的方式?jīng)]有明確標(biāo)準(zhǔn),可謂說是千人千面,每個(gè)人對(duì)于服務(wù)拆分理解程度和拆分尺度都不一樣,有的團(tuán)隊(duì)按每個(gè)接口一個(gè)服務(wù)。一般來說我們?cè)诓鸱值臅r(shí)候會(huì)結(jié)合理論知識(shí)和拆分原則來綜合考慮:1)

微服務(wù)拆的理論指導(dǎo)-團(tuán)隊(duì)規(guī)模大小

一般來說5-7個(gè)人一個(gè)小組比較合適,因?yàn)闇贤ㄐ屎蛨F(tuán)隊(duì)可擴(kuò)展性都能得到保障。如果一個(gè)團(tuán)隊(duì)人數(shù)過少的話,本來應(yīng)該是多人開發(fā)的服務(wù)最有由1-2人來開發(fā),會(huì)導(dǎo)致本來設(shè)計(jì)好的服務(wù)拆分邏輯最后卻都合并在一個(gè)工程上做開發(fā)了,失去了微服務(wù)的意義。-項(xiàng)目交付周期

盡可能縮短項(xiàng)目交付周期短,把頻繁需求變更的功能盡量獨(dú)立成單獨(dú)的服務(wù),保證快速的迭代,還能滿足快速上線的需求,縮短了項(xiàng)目交付周期,同時(shí)還能做到隨時(shí)回滾,風(fēng)險(xiǎn)變小,從而提高系統(tǒng)穩(wěn)定性。變更影響范圍

一個(gè)業(yè)務(wù)迭代功能點(diǎn),盡量不要分布到多個(gè)微服務(wù)中,盡量將關(guān)聯(lián)的實(shí)體對(duì)象存于一個(gè)微服務(wù),避免分布式事務(wù),比如把20%經(jīng)常變動(dòng)的部分進(jìn)行抽離,80%不經(jīng)常變動(dòng)的單獨(dú)部署和管理。-吞吐量大小

頻繁訪問,吞吐量大的服務(wù),盡量獨(dú)立微服務(wù),方便擴(kuò)容,能夠有效地提高資源利用率。2)

服務(wù)拆分原則-高內(nèi)聚低耦合

高內(nèi)聚低耦合是軟件工程中的概念,在軟件設(shè)計(jì)中通常用耦合度和內(nèi)聚度作為衡量模塊獨(dú)立程度的標(biāo)準(zhǔn)。但是在微服務(wù)拆分中同樣試用,服務(wù)拆分的一個(gè)準(zhǔn)則是高內(nèi)聚低耦合。從功能粒度來看,高內(nèi)聚即每個(gè)服務(wù)盡可能只完成一件事(最大限度的聚合);低耦合即減少外部服務(wù)依賴,盡量避免服務(wù)再調(diào)用服務(wù)。從數(shù)據(jù)庫角度來看每個(gè)服務(wù)單獨(dú)試用獨(dú)立的數(shù)據(jù)庫,外部如果需要試用數(shù)據(jù)必須通過接口調(diào)用。-以業(yè)務(wù)模型切入

有了高內(nèi)聚低耦合的前提,那么可以通過業(yè)務(wù)線來做拆分,比如用戶、商品、訂單、評(píng)論都拆分為獨(dú)立的服務(wù)。把相關(guān)的業(yè)務(wù)都聚合在同一個(gè)服務(wù)中,這樣也避免了跨庫所帶來數(shù)據(jù)一致性的問題。有可能以業(yè)務(wù)模型切入的方式初期階段會(huì)比較粗,但是可以通過后續(xù)的迭代頻率和吞吐量大小的指標(biāo)再來衡量是否需要繼續(xù)拆分。問題三:分布式事物怎么解決?一旦完成服務(wù)拆分,就會(huì)涉及到分布式事物,在談數(shù)據(jù)一致性要求的時(shí)候有2個(gè)非常重要的理論即CAP定理和Base理論:

CAP定理:C表示一致性,也就是所有用戶看到的數(shù)據(jù)是一樣的,A表示可用性,是指總能找到一個(gè)可用的數(shù)據(jù)副本,P表示分區(qū)容錯(cuò)性,能夠容忍網(wǎng)絡(luò)中斷等故障。

BASE理論:BA指的是基本業(yè)務(wù)可用性,支持分區(qū)失敗,當(dāng)分布式系統(tǒng)出現(xiàn)故障的時(shí)候,允許損失一部分可用性,例如在電商大促的時(shí)候,對(duì)一些非核心鏈路的功能進(jìn)行降級(jí)處理來提高系統(tǒng)的可用性,S表示柔性狀態(tài),允許系統(tǒng)存在中間狀態(tài),這個(gè)中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。比如,數(shù)據(jù)庫讀寫分離,寫庫同步到讀庫(主庫同步到從庫)會(huì)有一個(gè)延時(shí),E表示最終一致性,數(shù)據(jù)最終是一致的,例如主從同步雖然有短暫的數(shù)據(jù)不一致情況,但是最終數(shù)據(jù)還是一致的。

在實(shí)際中可以通過本地事務(wù)和發(fā)送MQ消息這種柔性事物方式來解決分布式事物所面臨的問題,既能保障服務(wù)的穩(wěn)定性又能保障調(diào)用效率的高效性,針對(duì)MQ可以使用Apache的RocketMQ所提供的事物消息和本地事物表結(jié)合。問題四:微服務(wù)框架選型?在選擇微服務(wù)架構(gòu)框架的時(shí)候,都在討論目前主流的微服務(wù)框架Dubbo以及SpringCloud,Dubbo出生于阿里系,是阿里巴巴服務(wù)化治理的核心框架,并被廣泛應(yīng)用于中國(guó)各互聯(lián)網(wǎng)公司,只需要通過spring配置的方式即可完成服務(wù)化,對(duì)于應(yīng)用無入侵。設(shè)計(jì)的目的還是服務(wù)于自身的業(yè)務(wù)為主。SpringCloud是大名鼎鼎的Spring家族的產(chǎn)品,專注于企業(yè)級(jí)開源框架的研發(fā)。SpringCloud自從發(fā)展到現(xiàn)在,仍然在不斷的高速發(fā)展,幾乎考慮了服務(wù)治理的方方面面,開發(fā)起來非常的便利和簡(jiǎn)單。這2種開發(fā)框架各巨頭互聯(lián)網(wǎng)公司都有深度使用,所以選擇任何一套框架都不會(huì)成為技術(shù)的瓶頸,關(guān)鍵還是看團(tuán)隊(duì)熟悉哪種框架,選擇最擅長(zhǎng)的,而不是去跟風(fēng)。問題五:微服務(wù)架構(gòu)下網(wǎng)關(guān)的必要性以及在網(wǎng)關(guān)下做限流、熔斷、降級(jí)等操作在談到網(wǎng)關(guān)的時(shí)候,首先需要確認(rèn)下目前微服務(wù)的業(yè)務(wù)線有幾條,如果只有單一的業(yè)務(wù)線,那么有沒有網(wǎng)關(guān)意義不大。其實(shí)網(wǎng)關(guān)可以理解為一個(gè)反向路由,它屏蔽內(nèi)部細(xì)節(jié),為調(diào)用者提供統(tǒng)一入口,接收所有調(diào)用者請(qǐng)求,通過路由機(jī)制轉(zhuǎn)發(fā)到服務(wù)實(shí)例,同時(shí)網(wǎng)關(guān)也是“過濾器”集合,可以實(shí)現(xiàn)一系列與業(yè)務(wù)無關(guān)的橫切面功能,如安全認(rèn)證、限流熔斷、日志監(jiān)控。-網(wǎng)關(guān)工作原理

協(xié)議轉(zhuǎn)換:將不同的協(xié)議轉(zhuǎn)換成“通用協(xié)議”,然后再將通用協(xié)議轉(zhuǎn)化成本地系統(tǒng)能夠識(shí)別的協(xié)議,例如把http協(xié)議統(tǒng)一轉(zhuǎn)換為dubbo協(xié)議。

鏈?zhǔn)教幚恚合牡谝粋€(gè)插件流入,從最后一個(gè)插件流出,每個(gè)步驟的插件對(duì)經(jīng)過的消息進(jìn)行處理,整個(gè)過程形成了一個(gè)鏈條。優(yōu)勢(shì)在于它將處理請(qǐng)求和處理步驟分開,每個(gè)處理的插件,只關(guān)心這個(gè)插件上需要做的處理操作,處理步驟和邏輯順序由“鏈”來完成。

異步請(qǐng)求:所有的請(qǐng)求都會(huì)通過API網(wǎng)關(guān)訪問應(yīng)用服務(wù),無論業(yè)務(wù)量如何變化,網(wǎng)關(guān)的吞吐量要保持穩(wěn)定狀態(tài)。假如把網(wǎng)關(guān)的請(qǐng)求看成一次IO操作的話,處理請(qǐng)求的線程,從接受請(qǐng)求開始直到服務(wù)端返回響應(yīng),都是阻塞狀態(tài)。操作系統(tǒng)所能承載的線程數(shù)是有限的,如果多個(gè)線程都處在這種狀態(tài),會(huì)導(dǎo)致系統(tǒng)緩慢。異步請(qǐng)求是指每個(gè)請(qǐng)求訪問網(wǎng)關(guān)的時(shí)候,會(huì)被包裝成一個(gè)事件,CPU內(nèi)核會(huì)維持一個(gè)監(jiān)聽器,不斷輪詢請(qǐng)求事件,請(qǐng)求的線程不用一直等待數(shù)據(jù)的返回。它在請(qǐng)求完畢以后,就直接返回了。-網(wǎng)關(guān)限流、降級(jí)網(wǎng)關(guān)的熔斷、降級(jí)是針對(duì)接口而言,可以選擇hystrix或者sentinel來做服務(wù)包括,一般來說需要具備以下設(shè)置:設(shè)置錯(cuò)誤率:可以設(shè)置每個(gè)服務(wù)錯(cuò)誤率到達(dá)制定范圍后開始熔斷或降級(jí);具備人工干預(yù):可以人工手動(dòng)干預(yù),主動(dòng)觸發(fā)降級(jí)服務(wù);設(shè)置時(shí)間窗口:可配置化來設(shè)置熔斷或者降級(jí)觸發(fā)的統(tǒng)計(jì)時(shí)間窗口;具備主動(dòng)告警:當(dāng)接口熔斷之后,需要主動(dòng)觸發(fā)短信告知當(dāng)前熔斷的接口信息;問題六:超時(shí)時(shí)間如何設(shè)置微服務(wù)中存在一次接口調(diào)用涉及到多個(gè)依賴服務(wù),每個(gè)依賴服務(wù)的耗時(shí)又不一樣,所以設(shè)置怎么樣的超時(shí)時(shí)間非常有講究,首先必須要有一刀切的態(tài)度,即每個(gè)接口的響應(yīng)時(shí)間不能超過閥值(比如1秒或者2秒),一方面提升用戶體驗(yàn),另外一方面也是增加系統(tǒng)的穩(wěn)定性。如果調(diào)用鏈路比較深的,則需要把非必要鏈路通過發(fā)送MQ消息的方式解耦,其次通過并行調(diào)用的方式來降低系統(tǒng)的響應(yīng)時(shí)間??偟膩碚f超時(shí)時(shí)間一般不會(huì)超過1秒,如何優(yōu)化到一秒,需要從系統(tǒng)的全局考慮,而不是只關(guān)注某一個(gè)點(diǎn)。問題七:熔斷設(shè)計(jì)需要考慮那些點(diǎn)?在進(jìn)行服務(wù)化拆分之后,系統(tǒng)中原有的本地調(diào)用就會(huì)變成遠(yuǎn)程調(diào)用,這樣就引入了更多的復(fù)雜性。比如說服務(wù)A依賴于服務(wù)B,這個(gè)過程中可能會(huì)出現(xiàn)網(wǎng)絡(luò)抖動(dòng)、網(wǎng)絡(luò)異常,服務(wù)B變得不可用或者響應(yīng)慢時(shí),也會(huì)影響到A的服務(wù)性能,甚至可能會(huì)使得服務(wù)A占滿整個(gè)線程池,導(dǎo)致這個(gè)應(yīng)用上其它的服務(wù)也受影響,從而引發(fā)更嚴(yán)重的雪崩效應(yīng)。需要針對(duì)如下幾項(xiàng)做了個(gè)性化配置:

?錯(cuò)誤率:可以設(shè)置每個(gè)服務(wù)錯(cuò)誤率到達(dá)制定范圍后開始熔斷或降級(jí);

?人工干預(yù):可以人工手動(dòng)干預(yù),主動(dòng)觸發(fā)降級(jí)服務(wù);

?時(shí)間窗口:可配置化來設(shè)置熔斷或者降級(jí)觸發(fā)的統(tǒng)計(jì)時(shí)間窗口;

主動(dòng)告警:當(dāng)接口熔斷之后,需要主動(dòng)觸發(fā)短信告知當(dāng)前熔斷的接口信息;

目前市場(chǎng)上可選擇的產(chǎn)品例如:Hystrix或則Sentinel做服務(wù)熔斷和降級(jí),這里推薦下Sentinel,不管是Dubbo還是SpringCloud

只要使用官方給定的依賴即可快速接入。問題八:微服務(wù)架構(gòu)的業(yè)務(wù)系統(tǒng)眾多,那么數(shù)據(jù)的一致性怎么保障,數(shù)據(jù)的隔離機(jī)制如何實(shí)現(xiàn)等等?當(dāng)前微服務(wù)架構(gòu)的業(yè)務(wù)系統(tǒng)越來越多,無論是做緩存場(chǎng)景,還是內(nèi)存數(shù)據(jù)庫場(chǎng)景,redis的適用非常普遍,但是每套業(yè)務(wù)系統(tǒng)都部署一套redis集群,相當(dāng)浪費(fèi)資源,而且,考慮到同城和異地的信息系統(tǒng)建設(shè),費(fèi)用也相當(dāng)之高,是否有機(jī)制可以類似中臺(tái)一樣,建立一個(gè)統(tǒng)一的redis平臺(tái),提供各種場(chǎng)景的服務(wù)?那么數(shù)據(jù)的一致性怎么保障,數(shù)據(jù)的隔離機(jī)制如何實(shí)現(xiàn),性能如何評(píng)估等等?

回復(fù)1:(1)首先統(tǒng)一的redis中心是很“技術(shù)”,因?yàn)槟阋粋€(gè)強(qiáng)大的技術(shù)人員或團(tuán)隊(duì);

(2)為了保證一致性,rediscluster讀取數(shù)據(jù)是從master上讀取數(shù)據(jù)的,這樣可以保證數(shù)據(jù)的一致性,當(dāng)然,性能也就差了;redis主從模式,寫master節(jié)點(diǎn),異步同步slave節(jié)點(diǎn),讀從slave上讀取數(shù)據(jù),讀性能提高了,但一致性難以保證。這也就是門德爾不可能三角中的CAP原則中,保證P的同時(shí),CA不可能同時(shí)滿足。

(3)當(dāng)然,也不是沒有解決方案,但redis作為一個(gè)緩存數(shù)據(jù)庫,并沒有做的這么復(fù)雜?,F(xiàn)代分布式數(shù)據(jù)庫中,使用multiraft架構(gòu),最大限度的解決了這個(gè)問題----master是變化的,根據(jù)應(yīng)用的不同不斷的變化,同時(shí)讀永遠(yuǎn)從變化的master上寫入和讀取。

(4)redis也是有事物的,但只保證了一致性和隔離性,沒有原子性,一致性上面說過了。因?yàn)閞edis本質(zhì)上是單線程的,一個(gè)一個(gè)的去執(zhí)行命令。這種順序執(zhí)行,隔離性是有保證的。回復(fù)2:首選糾正下你對(duì)微服務(wù)架構(gòu)的理解,在微服務(wù)架構(gòu)下,要求每個(gè)原子服務(wù)的數(shù)據(jù)庫、緩存都是相互獨(dú)立的,原因是當(dāng)服務(wù)所依賴的數(shù)據(jù)庫或者緩存有問題只影響它本身的服務(wù),不影響其他服務(wù),避免級(jí)聯(lián)問題。

其次關(guān)于你所擔(dān)心的資源浪費(fèi)問題,可以考慮每個(gè)服務(wù)的調(diào)用量來設(shè)置不同的服務(wù)資源配置,目前不管是虛擬化使用docker還是云平臺(tái)所提供的redis服務(wù),都可以做到非常低的費(fèi)用。

所以,想微服務(wù)穩(wěn)定,按標(biāo)準(zhǔn)的模式來,每種資源做隔離,而不是聚集在一起。回復(fù)3:這個(gè)架構(gòu)有問題,統(tǒng)一的redis平臺(tái)或者是集群提供服務(wù),因此這個(gè)集群肯定是橫向擴(kuò)容的,只能是cluster集群架構(gòu),所以從一致性、數(shù)據(jù)隔離、性能評(píng)估三個(gè)方面來分析

1、一致性可以做到,cluster的特性可以保證數(shù)據(jù)一致性

2、數(shù)據(jù)隔離做不到,單機(jī)支持多個(gè)數(shù)據(jù)庫,并且每個(gè)數(shù)據(jù)庫的數(shù)據(jù)是隔離的不能共享。cluster就沒有數(shù)據(jù)庫的概念,不支持多數(shù)據(jù)庫。

3、性能評(píng)估取決于承載業(yè)務(wù)的訪問量。問題九:企業(yè)微服務(wù)建設(shè)難點(diǎn):接口拆分多個(gè)微服務(wù)后帶來的接口響應(yīng)慢,怎么辦?回復(fù)1:理論上不會(huì)有慢的現(xiàn)象,可從以下方面查:

(1)使用s

溫馨提示

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

最新文檔

評(píng)論

0/150

提交評(píng)論