中國應用性能管理行業(yè)盛宴—2017中國應用性能管理大會(簡稱APMCon 2017)于8月10日至11日在北京新云南皇冠假日酒店隆重召開。本屆APMCon是由聽云、極客邦和InfoQ聯(lián)合主辦，作為國內(nèi)APM領域最具影響力的技術大會，本次大會以“驅(qū)動應用架構優(yōu)化與創(chuàng)新”為主題，致力于推動APM在國內(nèi)的成長與發(fā)展。

　　聽云產(chǎn)品副總裁Moca于APMCon 2017大會主論壇發(fā)表了題為《風起云涌-APM開啟全新數(shù)字化體驗時代》的演講，現(xiàn)場解讀了全球范圍內(nèi)，APM如何幫助企業(yè)進行數(shù)字化轉型以及APM行業(yè)未來的發(fā)展趨勢。

　　以下為演講實錄：

　　Moca：大家上午好，非常感謝大家來到第二屆APMCon的現(xiàn)場，很榮幸作為聽云的代表為大家分享關于APM的話題。

　　聽云作為APM的先行者，從2014年到2017年經(jīng)歷了APM摸索階段和、市場認知初期的狀態(tài)，同時也是越來越多的廠商去應用APM，越來越多的技術在APM領域蓬勃發(fā)展的階段。這其中非常大的變化，就是我看到百度搜索關鍵詞的競價排名單價翻了好幾倍，所以說這個市場變熱了，大家搜索的意愿都提升了，大家也對這個行業(yè)和這個技術有了更大的興趣和應用。

　　這個調(diào)研表明了全球CEO在2017年度到2018年度中企業(yè)最關注的兩件事是什么。第一點毋庸置疑的是企業(yè)的增長，第二就是與IT相關。所以在廣義的企業(yè)中，不只是互聯(lián)網(wǎng)廠商，在傳統(tǒng)企業(yè)當中的IT部門里，我們整個IT的從業(yè)人員在企業(yè)的地位也是得到了很大的提升。那么為什么大家都開始關注IT相關的技術呢?是因為它被證實的確可以促進企業(yè)的發(fā)展和業(yè)務的增長。

　　這些都是大家耳熟能詳?shù)腎T細分領域，包括企業(yè)上云、數(shù)字化營銷、如何利用IT技術提升企業(yè)的產(chǎn)能等。這些細分領域都得到了相應的重視，就是因為其中的數(shù)字化轉型，也就是說企業(yè)會更多的用IT的方式和數(shù)字化的方式去促進自己的業(yè)務增長。

　　數(shù)字化轉型我認為給廣義上的企業(yè)帶來了最大的兩個變化，第一個是業(yè)務更多的去通過數(shù)字化的媒介進行承載，比如像APP、微信，包括現(xiàn)在的微信公眾號，以及IOT的設備、網(wǎng)站等;另外就是IT的運維團隊原來可能更關注的只是保障系統(tǒng)的穩(wěn)定性，現(xiàn)在還要去想如何適應企業(yè)的業(yè)務創(chuàng)新和快速發(fā)展，怎樣用新的架構、新的開發(fā)模式來適應發(fā)展。

　　因此現(xiàn)在企業(yè)內(nèi)部的IT團隊和越來越多的業(yè)務團隊，越來越通過數(shù)字化來承載業(yè)務，他們希望對業(yè)務的交易性能能有更高的能見度，這就很大的促進了整個IT性能管理軟件這個細分領域的猛烈增長。基于現(xiàn)存的全球90億美金的市場，2015年也有13.9%的增長。這個增長在IT的細分領域是非常大的，要知道全球普通的IT細分領域每年的增長也只是6%左右。

　　這是Gartner對性能分析技術這個軟件細分領域的技術炒作趨勢圖，其中APM已經(jīng)過了技術初期的狀態(tài)，并從低谷逐漸走向了從技術成熟區(qū)，也就意味著這個技術在兩年到五年之內(nèi)會被整個的市場普遍的應用，這是整個國際的趨勢，在國內(nèi)可能稍微晚一點。

　　但是我發(fā)現(xiàn)在今年的APMCon中，大家對APM技術的關注越來越高，而且從整個市場的接受度來說，也可以看出現(xiàn)在已經(jīng)不是初期的階段，有很多的廠商，包括剛才Wood所講的，很多觀望者都已經(jīng)開始進到了這個領域里。

　　APM是在IT性能分析軟件的細分市場中唯一相對成熟且高價值的技術。由于數(shù)字化轉型的到來，越來越多的業(yè)務通過數(shù)字化媒介去承載。

　　但是傳統(tǒng)的IT監(jiān)控體系其實更多的是從下往上建立的，也就是從數(shù)據(jù)中心內(nèi)部，從技術組件、基礎架構監(jiān)控出發(fā)建立的。并且更多的IT運維團隊，大部分的KPI是以9為論的，比如“四個9”。但是，我們發(fā)現(xiàn)這樣的一個監(jiān)控體系已經(jīng)不能滿足現(xiàn)在企業(yè)高速數(shù)字化轉型的進程了，為什么呢?

　　因為我們發(fā)現(xiàn)，面向基礎架構的監(jiān)控只能發(fā)現(xiàn)30%左右的問題，而另外70%的問題是發(fā)現(xiàn)不了的。因此，當他們接到用戶投訴的時候，由于這些問題并不是在基礎架構組件中能發(fā)現(xiàn)的問題，并且用戶并不會投訴說是不是你們的CPU過熱了、磁盤IO是不是該清理了，他們肯定只會說我這個頁面打不開，按紐點了沒有反應，或者發(fā)生了白屏等等。那這些問題很多都是由于運營商劫持導致的，用戶那邊看到的內(nèi)容跟本身的廠商提供的并不一樣，或者是網(wǎng)絡出現(xiàn)了問題，然后這邊的內(nèi)容根本就沒有加載出來，出現(xiàn)白屏等這樣的問題。所以我們認為，下一代的應用性能監(jiān)控應該是從最終用戶體驗來出發(fā)，并且能夠把整個前端的用戶體驗以及后端的應用、OS、后端的組件以及基礎架構層做串聯(lián)，當發(fā)現(xiàn)一個問題的時候我們可以把它串起來，并且第一時間發(fā)現(xiàn)問題根本原因。

　　Gartner對2016年的APM也做了提升的定義，其中APM不是新詞，但是是這幾年才火起來的技術領域。之所以火，就是因為有一些新的技術改革以及新的業(yè)界發(fā)展形態(tài)所帶來的改變。Gartner對APM2016年做的必須具備的能力有三個，其中我認為可以突出講的有以下幾點。

　　第一是數(shù)字化用戶體驗的監(jiān)控(DEM)。過去的APM其實更多強調(diào)的是應用的發(fā)現(xiàn)、拓撲、追蹤與診斷。那現(xiàn)在由于更多的業(yè)務去通過數(shù)字化呈現(xiàn)給用戶，數(shù)字化用戶體驗的監(jiān)控就會變得非常重要。這中間就包括主動式的模擬探測監(jiān)控以及被動式的嵌入式監(jiān)控，這種監(jiān)控方式能夠第一時間發(fā)現(xiàn)終端用戶產(chǎn)生的一系列的劫持、網(wǎng)絡問題、崩潰等性能問題，并且能夠通過傳統(tǒng)APM的能力串聯(lián)，最終追蹤發(fā)現(xiàn)問題。

　　第二強調(diào)了應用分析(AA)。原來應用分析和性能的分析更多的是通過圖表的分析去看趨勢。那么現(xiàn)在Gartner要求我們對整個應用性能的分析過程中要加入自動化運維、加入大數(shù)據(jù)的分析和數(shù)據(jù)擬合建模分析能力，來幫助用戶甚至預測性能發(fā)展的瓶頸和趨勢。之后我們裴丹教授也會講很多的算法，我們之間也有一些交流。就是如何用一些算法科學能夠找到性能的瓶頸去做診斷。像這樣的技術能力現(xiàn)在已經(jīng)被越來越多的應用到APM的領域當中。

　　APM應用場景

　　我剛才講了整個應用性能管理行業(yè)的趨勢和新的變化，以及整個行業(yè)的認知。現(xiàn)在我給大家分享的就是在這三年當中我們所發(fā)現(xiàn)的，在2016年到2017年三個比較新的APM的應用場景。

　　APM的核心能力是能夠把應用的整個拓撲關系，后端組件的依賴關系，通過一個事物去進行串聯(lián)。過去傳統(tǒng)的APM主要的意義在于發(fā)現(xiàn)問題并且能夠定位到代碼級別的問題，做根因的診斷。但是由于這兩年數(shù)字化轉型的變革，有一些新的應用場景。

　　1. 如何去用APM做用戶體驗的量化與優(yōu)化。

　　2. 在很多上云的進程中，APM如何幫助企業(yè)做云的選型、上云后的管理，甚至幫助云廠商做云各個節(jié)點路由的優(yōu)化策略。

　　3. APM如何結合DevOps內(nèi)部的推進。

　　一、APM如何做用戶體驗的量化與優(yōu)化

　　先來看看用戶體驗，大家都知道它非常重要?，F(xiàn)在各個行業(yè)，尤其是最終用戶的行業(yè)用戶體驗極為重要，因為競爭太激烈了。

　　這張圖大家看著像油畫，其實是衛(wèi)星探測的共享單車，這個其實是比較夸張的，但這是我們現(xiàn)實中的圖，能證明這個行業(yè)非常的激烈。如果你的性能不夠好，用戶很容易就切換到另外一家廠商。同時像航空業(yè)、國航、東航、南航，各個都有自己的App。用戶更多的通過數(shù)字化來承載他們的業(yè)務，他們選擇價格因素是其中之一，當時時效性的性能和體驗也決定了用戶是不是能夠?qū)δ愕钠放朴兄艺\度、好感度，以及后續(xù)的使用習慣。所以用戶體驗的優(yōu)化其實是一個非常重要的，并且需要持續(xù)去做的一件事。

　　我們的客戶經(jīng)常問三個問題，這三個場景比較常見。第一個問題是像雙11大促或者是有一些事件性的活動上線的時候，如何動態(tài)的掌握用戶體驗，能夠及時止損，并且能夠在這個過程中或者在之前就能做到優(yōu)化和并且快速的決策;第二個問題，不光是我們互聯(lián)網(wǎng)廠商，很多傳統(tǒng)的企業(yè)，像航空業(yè)，包括制造業(yè)，高科技產(chǎn)業(yè)，他們內(nèi)部的OA的APP每周都要迭代一次，迭代頻率非常快。那么如何在迭代過程中從用戶體驗這邊制定一個衡量的標準;第三個問題是如何定義用戶體驗并快速定位問題。什么意思?在座的各位想想，用戶體驗用什么指標來去定義，你們心中有一個統(tǒng)一的目標嗎?大家會說響應時間。但到底是后端的響應時間還是什么呢?大家可能沒有統(tǒng)一的定義。所以從監(jiān)控的角度我們應該去定義到底什么是好的、什么是不好的，才能去幫助我們的客戶和開發(fā)者快速的發(fā)現(xiàn)這個問題，才能有統(tǒng)一的標準。針對以上這三個問題我們怎么解決呢?

　　A、事件性的活動如何快速的決策，如何第一時間響應并發(fā)現(xiàn)問題

　　這是整個實時監(jiān)控系統(tǒng)，并且是用戶體驗的監(jiān)控大屏。這個大屏會被用到很多企業(yè)的IT指揮中心、作戰(zhàn)中心，他們會把這塊大屏嵌入到活動當中。這個大屏對于企業(yè)有怎樣的優(yōu)勢呢?

　　1. 可以實時監(jiān)測全國日活用戶是怎樣的，各個區(qū)域的響應時間是怎樣的，其中紅色代表不好，黃色比較差，綠色是比較好。

　　2. 結合活躍用戶的發(fā)生區(qū)域看哪個地方是需要優(yōu)先解決的。

　　3. 全國各地是否發(fā)生了劫持，劫持的區(qū)域是不是業(yè)務所重視的。

　　4. CDN加速情況，不同的CDN下全國的全網(wǎng)加速情況。

　　5. 將核心業(yè)務實時的展現(xiàn)出來，比如說我的登錄頁面、支付頁面，在全國是否會有延遲現(xiàn)象。

　　以上這五點能夠幫助用戶在活動進行時做出快速準確的輔助決策。所以在做活動時的用戶體驗監(jiān)控時，最重要的是信息化和可視化，尤其是在時效性為先的時候一定要有一塊屏幕能夠第一時間的發(fā)現(xiàn)用戶體驗的問題。

　　B、如何制定KPI，如何在快速迭代中制定這些目標，如何量化

　　這張圖是針對APP用戶體驗、性能體驗的打分，這個打分不光是簡單的加權平均的算法，而是基于整個76個行業(yè)的劃分，以及超過6億終端的數(shù)據(jù)做的后期算法建模。其中藍色是自己所在行業(yè)的分數(shù)，我們把這個性能分成幾個重要的指標，如響應時間、崩潰、卡頓錯誤、流量消耗等，我們認為這幾個指標是直接影響用戶的體驗和用戶感受的。最后我們會對這幾個指標進行權重以及算法，最后得出所在的行業(yè)整體用戶體驗大概是處于怎樣的區(qū)間。根據(jù)你的APP用戶體驗到底是處于行業(yè)哪個位置，我們會給出一個歷史評分，這其實就是行業(yè)基線的概念。所以當制定一個快速迭代的指標時，不光要看自己每次提升了多少，而是基于所在的行業(yè)去滿足行業(yè)競爭的需求。

　　同時根據(jù)上圖就可以看出客戶在這段時間做了一次迭代，響應時間大大的降低了。所以這里是做了一個很明顯的優(yōu)化。通過這一套評分體系，就可以把用戶體驗的量化評分用作每次的迭代，然后去對比這次的迭代有沒有上升，制定目標也是基于行業(yè)的基線去制定的目標。

　　C、如何定義用戶體驗

　　過去我們?nèi)绻麖那岸碎_發(fā)和程序員的視角或者運維的視角來定義，要么就是服務有沒有中斷，要么就是整體頁面加載情況怎么樣，有沒有錯誤的問題。

　　用戶體驗本身與業(yè)務很貼近，我們先去定義清楚用戶體驗的點，然后做切片，再去定位問題，這才是更好的視角。所以我們把用戶體驗這個頁面的加載，把它做了一些劃分，基于用戶體驗的重要性去做了劃分，比如白屏時間、首屏時間，最小可交付的時間，以及加載時間等。根據(jù)不同的業(yè)務來自定義，比如是內(nèi)容的業(yè)務，可能只關注首屏的時間加載的是不是夠快就可以了，因為后面會隨著刷新去加載的。另外有的頁面是轉到了一個可操作的頁面，那可能更關注的是最小的可交互時間。所以通過這幾個指標把網(wǎng)站的用戶體驗和關注的指標做切分。

　　所以用戶體驗的監(jiān)控是屬于數(shù)字化體驗監(jiān)控的范疇之內(nèi)，我們做了一些創(chuàng)新和改造。傳統(tǒng)其實也有一些頁面級的監(jiān)控軟件，他們給出的就是整個的JS錯誤分析，Ajax請求分析，流媒體的監(jiān)控，我們現(xiàn)在就是先從用戶頁面來定義這個問題，然后再分析原因。

　　大家可以看到，我們會把整個網(wǎng)站列出來，并且給出用戶的訪問量，以及完全加載、白屏、首屏、交互時間等各個指標。非常簡單就能夠看到想優(yōu)化某一個頁面的用戶體驗。發(fā)現(xiàn)用戶體驗問題，首先要關注的是PV多不多，如果不多的話就不用看。所以要基于業(yè)務的請求量排優(yōu)先級。另外就是關注不同的指標做排序，關注什么就看什么的時間。

　　同時從不同的維度給出頁面的不同維度分析，從而能夠得出你的問題到底發(fā)生在哪兒。如果發(fā)現(xiàn)這個問題比較著重于某一個運營商，或者某一個地區(qū)的話，那么接下來就要看它的單樣本數(shù)據(jù)去定位問題。所以整個流程我想給大家講的是一個解決問題的思路，就是說過去是直接看有多少個錯誤，但現(xiàn)在的思路是要先看最重要的用戶體驗，并且能細分下去，然后再看單樣本的數(shù)據(jù)去定位解決問題，這是現(xiàn)在解決問題的思路。

　　并不是說這個技術有多么的高深，但是這個思路才是符合現(xiàn)在數(shù)字化轉型并解決用戶體驗問題的思路。通過這些元素的拓撲，我們能夠發(fā)現(xiàn)導致加載慢的元素。并且，很多性能都會關聯(lián)到后端的，比如說很多Ajax請求是由于后端的請求響應慢導致的。所以APM核心能力在用戶體驗解決問題的時候，要能夠追蹤到后面的應用，以及對應用的各個時間、分段做最后的追蹤和定位問題。

　　剛才我從用戶體驗方面說了三點，一個是我們要有實時的監(jiān)控體系，能夠在一些事件性的情況下第一時間看到問題所在。第二就是我們要有指標體系、基線，可以達到在競爭環(huán)境中快速迭代、制定目標。第三個就是我們要能明確定義用戶體驗的指標，我們要優(yōu)化哪些，優(yōu)先解決哪些，怎么解決。

　　二、云體驗度量

　　接下來就是云體驗的度量?，F(xiàn)在的情況是迎來了大撥傳統(tǒng)企業(yè)上云，我估計今年年底的時候大家看公有云的業(yè)績還是會有非常大的增長的。我們的客戶又問了，云廠商選哪家好，云廠商分布的各個節(jié)點資源實際效果如何，因為云廠商提供的都是自己的測試報告，很難分辨出業(yè)務上去之后實際效果怎么樣。一上去其實就是很難切換的，雖然說大家覺得云是一個很動態(tài)，很靈活的資源，但其實真的業(yè)務上去之后大家就會明白很難切換;第二就是上云之后如何繼續(xù)保持業(yè)務的可建性，過去傳統(tǒng)業(yè)務的板塊上云之后就不工作了。第三就是云廠商也會問，如何從最終用戶體驗優(yōu)化我的節(jié)點路由。接下來我說幾個案例。

　　1、APM如何做云選型

　　這是給客戶做的云的選型，從這邊我們做了一個壓測。我們會部署客戶相同的應用到云上。另外就是通過全網(wǎng)的節(jié)點訪問這個應用。經(jīng)過節(jié)點的數(shù)量加壓之后，再看網(wǎng)絡層和應用層的監(jiān)控數(shù)據(jù)，網(wǎng)絡層主要看延時和丟包，云一明顯延時比云二要高的。應用層這邊的可用性比云二要好的。所以可以非常直觀的看出實際業(yè)務在這上面跑了之后，云廠商給你分布的主機節(jié)點資源這些，在相同的配置下哪個更適合。

　　這是我們分別把云一和云二的各個服務器節(jié)點，北京、廣東、上海的區(qū)域做了壓測的對比。Apdex是應用的滿意度指標，還包括應用服務器的響應時間，CPU使用率，磁盤IO這樣的組件的數(shù)據(jù)，能看到CPU使用率云一是高于云二的。所以這也能夠幫助你判斷上云后所相對應的消耗大小。

　　2、上云后的可視化管理

　　上云后的管理也是非常重要的，上云后的管理需要11個相關的技術功能相互輔助。其中有一項就是Monitoring and monitering，能實時的監(jiān)控、測量管理和度量，這也需要持續(xù)的使用應用性能管理的系統(tǒng)做管理，不管你的應用部署在哪里，APM有主動式、被動式，嵌入式的技術手段，你只要嵌入到當中就能掌握你的動態(tài)?？梢耘挪槌龅降资菓玫膯栴}，還是網(wǎng)絡問題，還是云這邊機房出了問題，提前會有一個預判。

　　3、APM如何幫助云廠商做鏈路路由策略調(diào)優(yōu)

　　這是對我們廠商節(jié)點優(yōu)化的案例，其實很簡單，這時APM能做的一個比較大的能力。比如說廊坊的節(jié)點給北京的用戶分配，同時你這個機房，還有河南節(jié)點給北京的分配，是更好還是更次，所以需要有真實的探測和實時動態(tài)的掌握。所以這邊做了兩個機房服務區(qū)的對比，可以看到不同的兩個北京的機房，在整個的響應時間里看，延時和丟包來說都不一樣的，會有一些區(qū)別。并且這個探測是基于城市和運營商的，在這個測試結果中我沒有列出具體的數(shù)據(jù)，但是北京2機房的移動效果訪問不好，聯(lián)通和電信比較好的。北京1的機房反而是移動比較好，在成都、杭州、濟南、鄭州，移動訪問用戶訪問北京2的機房的效果不好，所以不建議在北京2的機房去服務這四個地區(qū)的移動線路。所以這就是一個非常明確和有效的鏈路選型的建議。

　　同時我們會給出基于不同運營商城市的路由，也就是說在不同的機房、在不同的城市，哪一個機房訪問最終用戶的體驗是最好的，我們可以給它一個優(yōu)化策略的路由表。所以我們現(xiàn)在的一些云廠商也是用這套策略和APM的辦法來優(yōu)化它的節(jié)點。

　　三、APM對DevOps的推動

　　DevOps就是開發(fā)人員和運維一體化，其本質(zhì)是要保障促進業(yè)務的快速發(fā)展，并且是一個高質(zhì)高量的保障，所以我們要有一系列的工具來保證這個效益。

　　#FormatImgID_18#

　　這是2017年DevOps的技術炒作曲線，大家可以看到APM也是在這個區(qū)間，也就是說APM是DevOps技術的高價值投入。

　　APM可以幫助DevOps完成從設定業(yè)務、迭代目標，到基于目標進行開發(fā)、測試、設定性能矩陣、生產(chǎn)環(huán)境以及設定度量的偏差，這些過程都是研發(fā)和運維一起完成的。研發(fā)要保障代碼的質(zhì)量，運維要保證快速的上線和迭代。

　　1、APM高價值的體現(xiàn)

　　其中APM對DevOps的應用最核心的價值，就是從用戶端到網(wǎng)絡層，到整個后端應用，到組件、中間件等等全部進行了串聯(lián)，這也就是非常符合DevOps工作流程的方法。

　　a) APM對于DevOps來說是一個平臺。APM可以將DevOps甚至商業(yè)部門以及測試部門用一個平臺、一套數(shù)據(jù)以及一套方法論，將問題整合到一起去解決瓶頸。這個非常重要，因為現(xiàn)在每一個企業(yè)不同的系統(tǒng)、不同的部門都有不同的監(jiān)控體系，他們的監(jiān)測數(shù)據(jù)都是不一樣的，所以如果你想實現(xiàn)這種快速的迭代和研發(fā)的話，就要確保大家都在一個平臺，用一套語言、一套數(shù)據(jù)去說話。否則就會變成互相扯皮。

　　b) APM對于DevOps來說有有效的錯誤定位能力。APM的組件診斷的能力能夠幫助DevOps團隊理解并診斷基礎設施組件的問題，包括函數(shù)的調(diào)用、依賴關系等等，來發(fā)現(xiàn)代碼中的瓶頸和潛在的問題，保證DevOps中非常強調(diào)的高質(zhì)量的代碼。

　　c) APM對于DevOps來說可以快速發(fā)現(xiàn)特定切片的響應延遲。當產(chǎn)品快速上線或者測試的時候，基于事務可以從前到后拓撲出之間相互的依賴關系，以及問題發(fā)生在哪兒，哪兒有延遲，做切片的問題診斷。

　　d) APM對終端用戶的管理，過去DevOps對終端用戶的掌控力相對較弱，現(xiàn)在通過這一套平臺能發(fā)現(xiàn)像劫持、崩潰等等只有終端用戶才能發(fā)現(xiàn)的一些問題。

　　四、關于性能監(jiān)控體系的幾點建議

　　1、一定要把數(shù)據(jù)作為核心，APM最核心的不光是整個的體系和后臺，它不是純工具。APM在各個端、各個節(jié)點去采集數(shù)據(jù)，這些數(shù)據(jù)的來源非?？少F，因為這些數(shù)據(jù)的體現(xiàn)間接挖掘出了行業(yè)的基線，這樣的一些數(shù)據(jù)建模的價值是很高的。同樣企業(yè)內(nèi)部也需要把這些數(shù)據(jù)做統(tǒng)一的管理和后期的挖掘，可以基于這些數(shù)據(jù)去做加強自動化運維的判斷依據(jù)。

　　2、作為IT管理者，這里說的是廣義的傳統(tǒng)企業(yè)IT管理者，需要基于數(shù)字化轉型去做新的監(jiān)控體系策略。而不是只用過去傳統(tǒng)的監(jiān)控體系就夠了，因為你的數(shù)字化轉型如果不能隨著可視化和可度量去做的話，這無異于是盲人摸象。

　　3、要從數(shù)字化用戶體驗層出發(fā)建立這套IT監(jiān)控體系，并與業(yè)務數(shù)據(jù)做關聯(lián)分析，這也是接下來的一個新的發(fā)展。

特別提醒：本網(wǎng)內(nèi)容轉載自其他媒體，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實，對本文以及其中全部或者部分內(nèi)容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內(nèi)容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網(wǎng)有任何內(nèi)容侵犯您的權益，請及時聯(lián)系我們，本站將會在24小時內(nèi)處理完畢。