一、作者介紹

　　徐桂林：阿里云日志服務(wù)技術(shù)專家，碩士畢業(yè)，曾任職AutoDesk等公司，擅長云計算，DevOps等。

[[145962]]

　　二、引言

　　我在自動化部署，特別是公有云的自動化部署上工作多年，因此本文主要就這方面進行展開。

　　注意：這里提到的云主要指基礎(chǔ)設(shè)施服務(wù)層，即IaaS，且泛指包括公有云、私有云或者混合云在內(nèi)的所有IaaS層形態(tài)。

　　三、基本背景

　　由于工作關(guān)系，我在上一家公司(Autodesk)時從2008年底開始使用某國外公有云。當時參與項目中很重要的一部分工作就是幫助用戶在我們的平臺上(注：我們的平臺運行在該云上)完成自動化部署。

　　由于整個部署非常重，涉及到平臺自身部署、基礎(chǔ)軟件部署和用戶傳統(tǒng)軟件部署。每次部署需要數(shù)個小時的時間，非常影響整個團隊的工作效率。所以，我們花費了比較多的時間在構(gòu)建自己的云自動化部署系統(tǒng)。　　

　　進入現(xiàn)在公司后，個人也推進了所在項目的部分自動化部署流程。盡管這個項目并不直接運行在云上，但在原來項目中總結(jié)出的辦法還是有一定通用性。其中的部分經(jīng)驗也得以落實，最終效果也不錯(整個系統(tǒng)的部署時間有了數(shù)量級的縮短)。

　　經(jīng)歷上面兩個完全不同的項目，個人意識到，系統(tǒng)自身的可部署性，是能否落實自動化部署的關(guān)鍵所在(當然，這個結(jié)論的前提是團隊已經(jīng)認同自動化部署是團隊效率和質(zhì)量的基礎(chǔ)性制度保證)。

　　而系統(tǒng)的可部署性是從架構(gòu)設(shè)計到最終運維整個流程都需要考慮的因素。所以需要整個工程團隊(開發(fā)、測試和運維)在系統(tǒng)可部署性上要達成一致，制定相關(guān)準則，整個自動化部署才能順利推進。

　　所以，這里我從系統(tǒng)的“可部署實踐準則”角度來分析如何保證自動化部署的成功實施：

　　盡管這里提到的很多準則不僅僅是針對云上系統(tǒng)，但是由于個人經(jīng)驗主要在云上系統(tǒng)的部署，同時個人相信未來絕大部分IT系統(tǒng)也都會運行在云上，所以會以云上系統(tǒng)的自動化部署為主來分享我的具體做法。

#p#

　　四、持續(xù)交付

　　在討論自動化部署時，一定會涉及到持續(xù)交付。從邏輯的角度上看，自動化部署是持續(xù)交付的一個階段。但是，自動化部署流程和系統(tǒng)仍然是可以獨立于整個持續(xù)交付流程而獨立運行。下圖描述常見的持續(xù)交付流程以及自動化部署在其中的位置。　

　　如上圖所示，整個自動化部署流程會涉及到IT系統(tǒng)生命周期中的所有環(huán)境(開發(fā)、測試，預(yù)發(fā)和生產(chǎn))。在這其中，由于生產(chǎn)系統(tǒng)的敏感性以及發(fā)布流程上的一些要求(如發(fā)布窗口期)，需要人工審批并觸發(fā)部署流程。其他環(huán)境更推薦持續(xù)部署來加快迭代周期，盡早發(fā)現(xiàn)問題。

　　五、可部署實踐準則

　　系統(tǒng)的可部署性一定是一個產(chǎn)品技術(shù)團隊共同的職責：

• 　　云上IT系統(tǒng)應(yīng)該遵循的準則有部分是流程上的，可能需要運維人員做標準化；
• 　　有些部分則是系統(tǒng)開發(fā)設(shè)計時的，需要開發(fā)人員考慮；
• 　　當然，測試工作也要考慮可部署性。

　　Rule 0、用版本管理系統(tǒng)(VCS)管理要發(fā)布的所有東西

　　這條規(guī)則比較容易理解，絕大部分團隊也應(yīng)該都在實際項目中很好得落實了這點。

　　需要注意的是，VCS系統(tǒng)不僅僅是用來管理你的代碼，所有要發(fā)布的東西(包括代碼、文檔、視頻等等)都可以(也應(yīng)該)由統(tǒng)一的VCS來管理。至于VCS系統(tǒng)的選擇，主流的軟件(SVN、Git或者Perforce等)都能夠很好支持整個持續(xù)交付和自動化部署流程。

　　Rule 1、統(tǒng)一管理構(gòu)建出來的Artifacts

　　這條規(guī)則是很多團隊容易忽視，但對自動化部署落實又非常重要的基礎(chǔ)性準則。

　　什么是Artifacts?

　　Artifacts是指構(gòu)建系統(tǒng)產(chǎn)生的任何需要部署的輸出，如代碼包、文檔、靜態(tài)資源等。

　　參考上面的持續(xù)集成流程圖，可以看出Artifacts是所有自動部署流程的輸入，它的管理質(zhì)量直接會影響到部署流程的順利程度和效率。關(guān)于Artifacts管理，現(xiàn)實工程中經(jīng)常出現(xiàn)的幾種情況如下：

• 　　團隊完全無Artifacts管理。需要部署時直接從構(gòu)建系統(tǒng)拷貝出來，通過郵件或者其他文件分享工具在團隊內(nèi)部傳輸。這種情況會導致整個部署流程完全失控，并且無法跟蹤部署記錄。
• 　　團隊僅關(guān)注生產(chǎn)環(huán)境下的Artifacts管理。對于開發(fā)、測試或者預(yù)發(fā)環(huán)境的Artifacts管理沒有任何規(guī)劃和標準。這種情況會無法保證整個生命周期的部署一致性，極大影響團隊的迭代效率。
• 　　對于Artifacts的管理完全等同于對于文件的管理，沒有對Artifacts的metadata信息進行任何有效管理。由于缺乏Artifacts的metadata信息，導致部署流程和系統(tǒng)不容易獲取當前Artifacts的元數(shù)據(jù)并以此采取相關(guān)操作。會讓部署流程實現(xiàn)困難，部署質(zhì)量無法保證。

　　在實際工程中，團隊越早在Artifacts管理上達成統(tǒng)一標準，團隊在推進自動化部署落地的難度就越小。個人認為，一個好的Artifacts管理方式需要有下面幾個原則：

• 　　統(tǒng)一管理所有需要部署的Artifacts，包括開發(fā)、測試、預(yù)發(fā)和生產(chǎn)環(huán)境。只有這樣，才能夠為未來自動化部署流程和系統(tǒng)提供統(tǒng)一的輸入。
• 　　統(tǒng)一的Artifacts元數(shù)據(jù)格式，包括當前Artifacts的構(gòu)建信息、版本信息、可部署的環(huán)境等。
• 　　提供對接構(gòu)建系統(tǒng)和部署系統(tǒng)的API接口。只有API接口才能夠保證未來自動化的落地。

　　目前，市面上已經(jīng)有很多Artifacts管理工具(如開源的Nexus)，可以幫助大家快速搭建整個Artifacts管理系統(tǒng)。如果你的系統(tǒng)是在云上部署，云供應(yīng)商提供的對象存儲服務(wù)也是不錯的選擇。

　　Rule 2、讓部署系統(tǒng)管理你的云上基礎(chǔ)設(shè)施

　　之所以把這一點放在前面，是因為它太重要了，而且也是和傳統(tǒng)IT環(huán)境下自動化部署流程非常不同的地方。

　　在云上，一個非常重要的變化就是：所有的基礎(chǔ)設(shè)施都可編程。

　　今天，所有的云供應(yīng)商都必須提供基礎(chǔ)設(shè)施的編程接口(如虛機啟停API，存儲接口，網(wǎng)絡(luò)配置接口)。而有些更成熟的云供應(yīng)商已經(jīng)提供如CloudFormation服務(wù)，讓你的IT系統(tǒng)基礎(chǔ)設(shè)施能夠完全可精確描述。

　　正因為如此，云上自動化部署系統(tǒng)可以完全管理起來自己的基礎(chǔ)設(shè)施，并且通過API或者如CloudFormation服務(wù)快速、精確構(gòu)建一致的IT運行基礎(chǔ)設(shè)施。

　　當系統(tǒng)的自動化部署流程完全包括基礎(chǔ)設(shè)施管理后，有如下幾個明顯好處：

• 　　任何時刻都可以獲取環(huán)境完全一致的IT基礎(chǔ)設(shè)施來運行系統(tǒng)(包括資源申請，環(huán)境搭建和軟件部署)。這樣，可以做到真正從零開始快速部署系統(tǒng)，而無需依賴任何其他部門(如IT部門)。
• 　　IT基礎(chǔ)設(shè)施的任何變化都能夠被部署系統(tǒng)自動感知并采取相應(yīng)的行動，保證IT系統(tǒng)的穩(wěn)定性。
• 　　IT系統(tǒng)可以根據(jù)系統(tǒng)當前情況隨時向部署系統(tǒng)要求調(diào)整IT基礎(chǔ)設(shè)施(如彈性伸縮)。

　　這里需要提到的一點就是，以Docker為代表的容器技術(shù)讓運行時標準化和可編程化變得極其容易和輕量級。

　　但是，整個IT系統(tǒng)基礎(chǔ)設(shè)施不僅僅包括系統(tǒng)的運行時環(huán)境，還包括網(wǎng)絡(luò)規(guī)劃、存儲管理、計算資源管理等等。

　　而這些基礎(chǔ)設(shè)施的程序化目前還只能通過云上IaaS層API或者類似CloudFormation來完成。所以，從這個角度看，Docker和IaaS并不是相互沖突，而是非常好的搭檔，一同把整個IT系統(tǒng)的運維、管理成本大幅降低。

　　Rule 3、使用相同的部署流程管理你的開發(fā)、測試、預(yù)發(fā)和生產(chǎn)環(huán)境

　　這是一條在傳統(tǒng)IT和云上都應(yīng)該遵循的原則。在現(xiàn)實中，很多團隊都喜歡把部署系統(tǒng)這個事情拖到上線前的***一刻才開始。而且，即使有自動化部署流程，也是和生產(chǎn)環(huán)境硬耦合，只能用于生產(chǎn)系統(tǒng)的部署。

　　1.這種做法雖然短時間來得快，但是在長期IT系統(tǒng)部署管理中會帶來不少麻煩，個人覺得至少會包括如下兩點：

　　2.這種部署方式導致不同環(huán)境的不一致性成為一個必然發(fā)生的事情，而這個問題最終會給你的生產(chǎn)環(huán)境帶來致命故障。

　　這種部署方式導致開發(fā)、測試和上線過程極為低效。其實，在不同環(huán)境中，生產(chǎn)環(huán)境的部署頻率是***的，而開發(fā)、測試部署幾乎是工程團隊每天都要做的事情。通過完全自動化的部署流程來管理所有環(huán)境將極大提高日常開發(fā)、測試效率。

　　所以，對于一個新項目，***在項目啟動之初就能夠把整個IT系統(tǒng)的自動化部署流程搭建成功，而且包括所有的環(huán)境。

　　而對于已經(jīng)運行的項目，也要積極推動部署流程和部署環(huán)境的解耦。具體來說，常見的解決思路包括下面幾個點：

• 　　使用不同的代碼分支對應(yīng)不同的環(huán)境，方便進行代碼管理;
• 　　抽象、提出所有和環(huán)境相關(guān)的配置，并以配置服務(wù)的方式提供訪問;
• 　　所有部署階段都需要接受環(huán)境參數(shù)輸入(可以是環(huán)境變量，也可以是參數(shù))，并按照不同環(huán)境做相應(yīng)部署操作;
• 　　給不同環(huán)境設(shè)置不同的部署頻率和時間窗口;
• 　　給不同環(huán)境設(shè)置不同的部署操作和訪問權(quán)限，以控制部署風險。

　　***，可能很多團隊根本不可能有完整開發(fā)、測試和生產(chǎn)環(huán)境(或者這幾個環(huán)境的差異性太大)，讓同一套部署流程很難適配不同的環(huán)境。但是，因為云的出現(xiàn)，讓我們獲取不同環(huán)境的IT基礎(chǔ)設(shè)施變得容易很多。

　　正因為如此，落實這條準則的難度在大幅下降(其實，開發(fā)測試已經(jīng)成為很多企業(yè)用戶開始嘗試云的***站)，而這條規(guī)則帶來的開發(fā)效率提升會讓團隊收益匪淺。

#p#

　　Rule 4、使用相同的部署流程管理全球各地的同一個IT系統(tǒng)

　　這是一條看起來對很多團隊沒什么用的準則。但是，云的出現(xiàn)讓全球化部署變得非常容易，很多非常小的團隊都可以做全球部署和運營。在云上，全球部署就是在云服務(wù)供應(yīng)商的全球不同Region部署你的IT系統(tǒng)。

　　當然，即使在國內(nèi)，為提供更好的系統(tǒng)訪問速度，云供應(yīng)商也會提供多個Region。由于云供應(yīng)商不同的Region提供的服務(wù)都已經(jīng)標準化，訪問接口也都統(tǒng)一，這讓使用相同部署流程管理全國(乃至全球)各地服務(wù)容易很多。為此，你的部署系統(tǒng)需要注意幾點：

• 　　抽象、提出任何和部署Region相關(guān)的配置，并以配置服務(wù)的方式提供訪問(配置服務(wù)有可能是集中化服務(wù))；
• 　　所有部署階段都需要接受Region相關(guān)信息輸入(可以是環(huán)境變量，也可以是參數(shù))；
• 　　需要提供不同Region的部署協(xié)調(diào)機制(例如，不同Region可能會在不同時區(qū)，這是處理和時間相關(guān)的部署任務(wù)需要特別小心的地方)。

　　一旦能夠統(tǒng)一不同Region的部署流程，將會使得業(yè)務(wù)擴展時的IT部署變得容易很多，這也是整個系統(tǒng)可擴展性的重要體現(xiàn)。

　　現(xiàn)在，IT系統(tǒng)擴展性很多時候被局限在同一套系統(tǒng)在同一個地方能否快速伸縮，而忽略了IT系統(tǒng)在不同地點的快速復制能力。而這種快速復制能力不僅僅是業(yè)務(wù)全球化的需求，有時候也是解決系統(tǒng)自身容量擴展性的重要途徑。

　　Rule 5、部署流程要優(yōu)先滿足熱升級、熱切換需求

　　在傳統(tǒng)IT工程中，由于熱升級和熱切換實現(xiàn)起來可能比較困難，而系統(tǒng)升級、切換的頻率也不一定高，很多時候這種功能性需求就會被當成“二等公民”看待。但這條準則恰恰相反，著重在強調(diào)“優(yōu)先滿足”。究其原因，個人認為有如下幾點：

　　1.“一直在線”已經(jīng)成為新的剛需。

　　隨著IT系統(tǒng)從后臺支撐逐步轉(zhuǎn)向前臺直接服務(wù)客戶。那種定期停機升級系統(tǒng)的方式已經(jīng)不再可以接受。

　　尤其是互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)的普及，用戶對于在線服務(wù)的默認期待已經(jīng)是“任何時候，任何地點都可以訪問”。在這種情況下，無論是架構(gòu)設(shè)計還是部署流程都需要考慮“一直在線”這個目標。

　　2.熱升級、熱切換是持續(xù)交付的基礎(chǔ)，是最終支撐業(yè)務(wù)快速發(fā)展的關(guān)鍵所在。實際工程中，產(chǎn)品團隊的所有工作最終都得到生產(chǎn)環(huán)境接受檢驗。

　　只有整個部署流程完全支持熱升級、熱切換，產(chǎn)品的任何改進或需求確認才能夠快速推到生產(chǎn)環(huán)境進行驗證。如果部署流程無法支持熱升級、熱切換，那持續(xù)部署就必然造成頻繁中斷服務(wù)，進而影響業(yè)務(wù)。

　　正因為上面的原因，在整個架構(gòu)和部署流程的設(shè)計過程中就需要優(yōu)先考慮熱升級、熱切換，并堅持走下去。否則搭建的整個持續(xù)交付或者自動化部署流程都會事倍功半，最終走向失敗。

　　在云上，由于基礎(chǔ)設(shè)施資源的獲取非常容易，在升級過程中讓不同版本完全獨立運行并逐步切換流量已經(jīng)是一個成本不高的實踐方式。所以，云上系統(tǒng)的熱升級及熱切換實現(xiàn)難度也有一定程度上的降低。

　　Rule 6、自動化、自動化還是自動化

　　就如“自動化部署”的名字所表述，自動化是其核心訴求，也是能夠最終成功實踐的技術(shù)保障。關(guān)于自動化的好處，相信不用展開說大家也都明白。但在現(xiàn)實過程中，大家面臨的問題常常是如何實現(xiàn)平滑的實現(xiàn)自動化。個人推薦下面幾個實踐經(jīng)驗：

　　1.不要在自動化技術(shù)和工具上猶豫太久。

　　選擇什么樣的自動化部署工具對于還沒有自動化流程的團隊來說不是***要務(wù)。重要的是團隊有決心、花時間去開始行動。

　　如果在選擇技術(shù)和工具上真有什么建議的話，那就選團隊最熟悉的技術(shù)和工具，這樣對于快速出結(jié)果最為有利。而讓團隊盡快看到自動化部署的優(yōu)勢，從而堅定在這條路上走下去比選擇什么樣的工具要重要得多。

　　2.盡早建立“one-click”部署流程。這樣可以讓團隊在“one-click”上有更早的約束，而不是在推進過程中不斷妥協(xié)，***完全無法自動化。

　　3.在有“one-click”部署流程的前提下分步推進各個組件達到自動化部署的要求。

　　在分步驟推進過程中，一個好的策略是區(qū)分模塊中的“常量”和“變量”。

　　這里的“常量”指系統(tǒng)部署中不經(jīng)常變化的部分(如基礎(chǔ)操作系統(tǒng)，基礎(chǔ)軟件等等)。對于這些部分，開始可以使用“預(yù)制模式”(如系統(tǒng)鏡像)加入部署系統(tǒng)。而部署過程中經(jīng)常變的“變量”部分，則需要在部署系統(tǒng)中重點考慮。當然，“常量”和“變量”的劃分也不是絕對的。一般來說，部署系統(tǒng)都是從自動化最頻繁變化的“變量”部分開始，逐步覆蓋較少變化的“常量”部分。因為這樣可以盡早***化自動化流程帶來的價值。

　　Rule 7、讓模塊有自啟動、自發(fā)現(xiàn)和自部署能力

　　在實施自動化部署的過程中，估計最容易讓團隊沮喪的就是不同模塊之間的部署依賴關(guān)系。很多傳統(tǒng)部署軟件也試圖通過各種方式(如可視化依賴關(guān)系)來降低維護部署依賴的難度，但很多時候最終效果并不好。

　　究其原因，個人覺得在業(yè)務(wù)場景的頻繁變化中，讓模塊之間的緊耦合依賴關(guān)系很難長期保持穩(wěn)定，部署系統(tǒng)也就很難高效維護這種多變的部署依賴關(guān)系。隨著微服務(wù)概念的流行，更多人開始相信每個微服務(wù)模塊都應(yīng)該是獨立部署、運維并提供服務(wù)。

　　這點體現(xiàn)在部署上，就是讓每個模塊有自啟動、自發(fā)現(xiàn)和自部署的能力。具體來說，其包括下面幾個方面：

• 　　每個模塊在部署到系統(tǒng)中，都能夠在無外接主動觸發(fā)的前提下自我啟動；
• 　　每個模塊在啟動后，都能夠在無需外接主動告知的前提下發(fā)現(xiàn)自己承擔的角色是什么；
• 　　每個模塊在發(fā)現(xiàn)自我角色后，都能夠在無需外接主動推送的前提下完成對自我角色的部署、配置、依賴檢查并啟動對外服務(wù)。

　　基于上面幾點要求，個人在實踐過程中采取的常見方法包括：

• 　　優(yōu)先選擇“運行時部署”，而不是“預(yù)定義模式”(最常見的預(yù)定義模式就是鏡像交付);
• 　　每個模塊需要自我描述如何完成自己的部署流程(如某大云的CodeDeploy服務(wù)，其中的appspec.yaml文件其實就是其對應(yīng)模塊自我部署的描述文件);
• 　　讓每個模塊獨立進行部署，不要求必須有前置或者后置的模塊部署。而模塊之間的依賴則優(yōu)先使用動態(tài)發(fā)現(xiàn)的模式進行。

　　#p#

Rule 8、讓部署變成服務(wù)

　　當團隊完成了整個自動化部署流程，記得在往前一步，把你的部署工具變成一個對內(nèi)的部署服務(wù)，讓團隊每個人(包括非技術(shù)人員或者新來的同事)也能夠快速完成部署。

　　為讓部署成為服務(wù)，你可能需要實現(xiàn)一個Portal，或者再添加一個郵件通知服務(wù)。當然，你也可以把整個部署服務(wù)做得更好，甚至服務(wù)于其他團隊。無論如何，這都會給團隊帶來很大的好處，因為它降低了整個系統(tǒng)的使用門檻，讓更多的人從中獲益。

　　Rule 9、用戶全面監(jiān)控保障自動化部署

　　這是***一條準則，但是可能也是很多開始嘗試自動化部署的團隊最擔心的問題：如果自動化部署出問題了咋辦?

　　人工部署時候還可以一步步觀察結(jié)果，由人來把關(guān)部署流程，避免不良后果快速擴大。其實，在回答這個問題之前，如果大家仔細回顧人肉部署帶來的各種故障，一定會發(fā)現(xiàn)人為失誤引起的故障比例會大得驚人。

　　而自動化部署的一個目標恰恰就是為了減少人為失誤導致的故障。當然，為了避免自動化部署的負面影響，你需要注意下面幾個方面：

• 　　請為你的服務(wù)提供全面的監(jiān)控。這不僅僅是日常運維的需要，也是自動化部署的需要。而且，這里的監(jiān)控需要包括很多應(yīng)用級別的監(jiān)控，而不僅僅是類似CPU、Memory這些基礎(chǔ)性監(jiān)控。這樣，可以方便團隊及時發(fā)現(xiàn)自動部署引起的系統(tǒng)服務(wù)問題。
• 　　在部署流程中提供快速回滾(Rollback)方案?？煽康幕貪L方案會讓你推進自動化部署的時候有更多的信心。
• 　　對每個模塊每個部署階段做更多的pre-check和post-check。想想如果你人肉做部署的時候是怎樣check每一個部署階段是否成功，如何判斷是否問題，然后盡量把這些判斷邏輯都自動化起來。

　　***，如果你是團隊內(nèi)希望推動自動化部署的同學，下面兩點經(jīng)驗或許在你推進過程中能幫助到你：

• 　　痛點原則。在推進自動化部署過程中，一個常見的問題就是時間問題。團隊總是會被不同的業(yè)務(wù)需求推著往前走，而自動化部署這種非功能性需求經(jīng)常無法得到資源保障。這時候，你需要不斷問自己的一個問題是“如果我現(xiàn)在只能在自動化部署方面做一見事情，那我需要做什么”。記得找到痛點***的唯一一件事情作為突破口，盡快讓團隊感受到自動化部署帶來的優(yōu)勢，才能夠得到團隊更多的支持。
• 　　不回頭原則。在推進自動化部署過程中，團結(jié)經(jīng)常會因為自動化部署帶來的問題或者自動化部署流程不完善而放棄嘗試。這時候，作為主動推進的人，一定要及時跟進發(fā)現(xiàn)系統(tǒng)問題，而不是讓團隊輕易走回頭路。

　　當然，你肯定會說搞定老板才是最核心的保障。如果你能夠有一個完全支持你的老板，那你是幸運的。

　　更多時候，老板會是一種半信半疑的態(tài)度對待自動化部署。這時候，找到突破點，快速見效并能堅持下去可能就是你能說服老板的***策略。

　　http://blog.xuguilin.me/2014/01/22/autodeploy-on-aws.html

　　如何一起愉快地發(fā)展

　　“高效運維”公眾號(如下二維碼)值得您的關(guān)注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上精彩分享及群友原創(chuàng)。“高效運維”也是互聯(lián)網(wǎng)專欄《高效運維***實踐》及運維2.0官方公眾號。

　　提示：目前高效運維兩個微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，進行申請;或申請加入我們技術(shù)交流群(技術(shù)討論為主，沒有主群那么多規(guī)矩，更熱鬧)。

　　重要提示：除非事先獲得授權(quán)，請在本公眾號發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識，請必須全文轉(zhuǎn)載，并包括本行及如下二維碼。