美團外賣從2013年9月成交首單以來，已走過了三個年頭。時期，事務(wù)飛速開展，美團外賣由日均幾單開展為日均500萬單（9月11日已突破600萬）的大型O2O互聯(lián)網(wǎng)外賣服務(wù)渠道。渠道支撐的品類也由開始外賣單品拓寬為全品類。

跟著訂單量的增加、事務(wù)復(fù)雜度的提高，外賣訂單體系也在不斷演化進化，從前期一個訂單事務(wù)模塊到現(xiàn)在分布式可擴展的高性能、高可用、高安穩(wěn)訂單體系。全部開展過程中，訂單體系閱歷了幾個顯著的期間，下面本篇文章將為我們介紹一下訂單體系的演進過程，重點重視各期間的事務(wù)特征、應(yīng)戰(zhàn)及應(yīng)對之道。

為便利我們非常好地了解全部演進過程，我們首要看一下外賣事務(wù)。

外賣訂單業(yè)務(wù)對于及時性的要求很高，因此從技術(shù)角度來看，實時性的優(yōu)先級很高，從用戶訂餐開始算起，直至送達，時效通常在一個小時左右。如果超時，用戶體驗就會受到傷害，成為一次糟糕的購物經(jīng)歷。

在一個小時之內(nèi)，訂單會不斷的變更狀態(tài)，一直到最終送達。這期間要求各階段配合緊密，一定要保證訂單有效且及時送達。

下圖是一個用戶視角的訂單流程圖。

我們從一個普通用戶的思維出發(fā)，當(dāng)他下達訂單之后，會有一個什么流程？

用戶需要下單然后支付，這是整個訂單發(fā)出的路徑，在這之后，商家接收訂單，完成制作，再之后，我們的物流團隊進行配送，送至終端用戶，然后就是確認收貨、包括后續(xù)售后或完結(jié)訂單等操作。

從技術(shù)上團隊來看，各個階段其實是多個子服務(wù)共同配的結(jié)果：比如說用戶在訂單下達的階段可能會有需要各個購物車、預(yù)覽、接受訂單服務(wù)共同匹配完成，這一系列的子服務(wù)又依賴于我們整體的底層基礎(chǔ)服務(wù)來完成。

另一個問題在于，外賣業(yè)務(wù)的時效性非常顯著，訂單在中午、傍晚時段會大批量的集中爆發(fā)，在其他時段數(shù)量則非常之少。這導(dǎo)致，到某時間段之后，整個系統(tǒng)的壓力會急劇上升。

下圖是一天內(nèi)的外賣訂單量分布圖

總結(jié)而言，外賣業(yè)務(wù)具有如下特征：

• 流程較長且實時性要求高；
• 訂單量高且集中。

下面將按時間脈絡(luò)為大家講解訂單系統(tǒng)經(jīng)歷的各個階段、各階段業(yè)務(wù)特征、挑戰(zhàn)以及應(yīng)對之道。

在早期，外賣業(yè)務(wù)起步階段技術(shù)團隊的第一目標(biāo)是要能夠急速驗證我們整體業(yè)務(wù)的可行性，所以這階段技術(shù)團隊的主要任務(wù)就是保證我們的服務(wù)架構(gòu)有足夠的靈活性，方便快速迭代，完成業(yè)務(wù)快速試錯過程中的需求。

因此，我們將訂單相關(guān)功能組織成為模塊化的服務(wù)，將其與其他的模塊一起拼裝成jar包，這個包是公用的，可以通過我們的各個系統(tǒng)來使用這個包，從而提供訂單功能。

早期系統(tǒng)的整體架構(gòu)圖如下所示：

在業(yè)務(wù)前期使用這種架構(gòu)，整體來講比較簡單、靈活，整個公共服務(wù)的邏輯通過集成分配到各端，整個應(yīng)用的開發(fā)部署相對比較簡單，十分適合我們前期的需求：前面已經(jīng)提過，是邏輯簡單、業(yè)務(wù)量不大，方便與快速迭代。

但是，隨著業(yè)務(wù)量持續(xù)上升，整個服務(wù)體系邏輯變得復(fù)雜，業(yè)務(wù)量開始增加，因此我們現(xiàn)有架構(gòu)的漏洞開始出現(xiàn)，整個業(yè)務(wù)體系互相干擾，出現(xiàn)了很多問題。

我們考慮，在前期整個業(yè)務(wù)處在試探階段，初步的架構(gòu)可以滿足業(yè)務(wù)需求，也能夠給提供快速迭代的支持，但隨著整個業(yè)務(wù)的成長、服務(wù)的成熟，我們應(yīng)該對這個體系進行升級，滿足現(xiàn)階段的需求。

在14年的4月左右，外賣訂單數(shù)量增長迅速，幾乎達到每天10萬訂單量的水平，而且由于業(yè)務(wù)發(fā)展良好，這個數(shù)字每天都在不斷攀升。整體業(yè)務(wù)的大框架此時已經(jīng)基本成型，集體業(yè)務(wù)在整體框架上快速迭代。

業(yè)務(wù)團隊使用一個大項目進行開發(fā)部署，在此基礎(chǔ)上互相影響，業(yè)務(wù)溝通成本上升，大多數(shù)業(yè)務(wù)公用VM的情況，也對業(yè)務(wù)整體產(chǎn)生了一定影響。

為解決開發(fā)、部署、運行時相互影響的問題。我們將訂單系統(tǒng)進行獨立拆分，從而獨立開發(fā)、部署、運行，避免受其它業(yè)務(wù)影響。

系統(tǒng)拆分主要有如下幾個原則：

• 相關(guān)業(yè)務(wù)拆分獨立系統(tǒng)；
• 優(yōu)先級一致的業(yè)務(wù)拆分獨立系統(tǒng)；
• 拆分系統(tǒng)包括業(yè)務(wù)服務(wù)和數(shù)據(jù)。

出于以上考慮，我們把訂單系統(tǒng)進行了整體的的獨立拆分，將接收到的所有訂單服務(wù)通過接口提供給外部使用。

在內(nèi)部訂單系統(tǒng)中，我們評估了功能優(yōu)先級，按照優(yōu)先級拆分成了不同的子系統(tǒng)，以防止業(yè)務(wù)之間的相互影響，通過隊列消息的形式，訂單系統(tǒng)可以通知外部訂單狀態(tài)的變更等情況。

獨立拆分后的訂單系統(tǒng)架構(gòu)如下所示：

這其中，最底層是數(shù)據(jù)存儲層，負責(zé)訂單相關(guān)數(shù)據(jù)的獨立存儲。訂單服務(wù)層，該層按照優(yōu)先級劃分為三個體系，分別稱之為交易體系、查詢體系和異步處理的體系。

獨立拆分后，能夠避免事務(wù)間的相互影響。迅速支持事務(wù)迭代需要的一起，保障體系穩(wěn)定性。

在我們將訂單系統(tǒng)進行拆分后，業(yè)務(wù)之間的相互干擾大大降低，不僅保證了迭代的速度，而且還很好的維持了系統(tǒng)的穩(wěn)定性，在這期間，整個業(yè)務(wù)的訂單量開始逐漸想著百萬大關(guān)邁進，并逐漸超出。本來的小問題，在大量訂單出現(xiàn)的時候覆蓋面積加大，對用戶的試用體驗相當(dāng)不友好。舉例說明，再支付成功后，某些極端情況會導(dǎo)致支付成功的消息無法返回，在終端顯示沒有支付。在巨量訂單的前提下，這種問題開始增加，我們必須進一步優(yōu)化系統(tǒng)的可靠性，保證我們的訂單功能不會影響用戶使用。

不僅如此，訂單量仍在不斷增加的同時，一些業(yè)務(wù)邏輯相對復(fù)雜、混亂，對于整個系統(tǒng)的使用提出了新的、更高的要求。

因此，為了能夠建設(shè)一個更加穩(wěn)定并且可信賴的訂單服務(wù)系統(tǒng)，我們必須再次對整個系統(tǒng)進行升級。我們后文就會按照各個升級需求對整個升級過程進行描述。

系統(tǒng)獨立拆分后，可以方便地對訂單系統(tǒng)進行優(yōu)化升級。我們對獨立拆分后的訂單系統(tǒng)進行了很多的性能優(yōu)化工作，提升服務(wù)整體性能，優(yōu)化工作主要涉及如下幾個方面。

一個顯而易見的道理是，同一時間需要處理的事情越少，服務(wù)性能就會越高、速度越快，所以我們將通過將部分操作進行異步化處理減少整個操作進行的壓力。通過異步來提升服務(wù)氣的性能。

以下使我們提出的兩種方案：

• 線程或線程池：將異步操作放在單獨線程中處理，避免阻塞服務(wù)線程；
• 消息異步：異步操作通過接收消息完成。

注意合理有一個隱患，我們?nèi)绾伪Ｕ袭惒讲僮鞯膱?zhí)行？設(shè)想一下場景，當(dāng)應(yīng)用重啟時，如果是線程或者線程池的行的異步化，在后臺執(zhí)行未完成的情況下，jvm重啟會造成相當(dāng)大的影響。

因此需要采取優(yōu)雅關(guān)閉開保障業(yè)務(wù)的進行。當(dāng)然，如果采取消息異步，則無須考慮這個問題。

具體到該系統(tǒng)，我們選擇將某些沒有必要同步進行的操作異步化，從而提供更強的性能，例如我們發(fā)放紅包或者推送消息等等全部采用了異步處理。

以訂單配送PUSH推送為例，將PUSH推送異步化后的處理流程變更如下所示：

PUSH異步化后，線程#1在更新訂單狀態(tài)、發(fā)送消息后立即返回，而不用同步等待PUSH推送完成。而PUSH推送異步在線程#2中完成。

操作并行化也是提升性能的一大利器，并行化將原本串行的工作并行執(zhí)行，降低整體處理時間。我們對所有訂單服務(wù)進行分析，將其中非相互依賴的操作并行化，從而提升整體的響應(yīng)時間。

以用戶下單為例，第一步是從各個依賴服務(wù)獲取信息，包括門店、菜品、用戶信息等。獲取這些信息并不需要相互依賴，故可以將其并行化，并行后的處理流程變更如下所示：

通過將獲取信息并行化，可有效縮短下單時間，提升下單接口性能。

經(jīng)過將核算信息進行提早核算后緩存，防止獲取數(shù)據(jù)時進行實時核算，然后提升獲取核算數(shù)據(jù)的效勞功能。比如關(guān)于首單、用戶已減免配送費等，經(jīng)過提早核算后緩存，能夠簡化實時獲取數(shù)據(jù)邏輯，節(jié)省時刻。

以用戶已減免配送費為例，假如需求實時核算，則需求取到用戶一切訂單后，再進行核算，這么實時核算成本較高。技術(shù)團隊經(jīng)過提早核算，緩存用戶已減免配送費。需求取用戶已減免配送費時，從緩存中取即可，不用實時核算。具體來說，包含如下幾點：

• 通過緩存保存用戶已減免配送費；
• 用戶下單時，如果訂單有減免配送費，增加緩存中用戶減免配送費金額（異步進行）；
• 訂單取消時，如果訂單有減免配送費，減少緩存中用戶減免配送費金額（異步進行）；

訂單體系觸及買賣，需要確保數(shù)據(jù)的共同性。不然，一旦出現(xiàn)疑問，可能會致使訂單不能及時配送、買賣金額不對等。

買賣一個很主要的特征是其操作具有業(yè)務(wù)性，訂單體系是一個雜亂的分布式體系，比方付出觸及訂單體系、付出渠道、付出寶/網(wǎng)銀等第三方。僅經(jīng)過傳統(tǒng)的數(shù)據(jù)庫業(yè)務(wù)來確保不太可行。關(guān)于訂單買賣體系的業(yè)務(wù)性，并不請求嚴(yán)厲滿意傳統(tǒng)數(shù)據(jù)庫業(yè)務(wù)的ACID性質(zhì)，只需要終究成果共同即可。對于訂單體系的特征，咱們經(jīng)過如下種方法來確保終究成果的共同性。

重試/冪等

經(jīng)過延時重試，確保操作終究會最執(zhí)行。比方退款操作，如退款時遇到網(wǎng)絡(luò)或付出渠道毛病等疑問，會延時進行重試，確保退款終究會被完結(jié)。重試又會帶來另一個疑問，即有些操作重復(fù)進行，需要對操作進行冪等處理，確保重試的正確性。

以退款操作為例，參加重試/冪等后的處理流程如下所示：

退款操作首先會查看是否現(xiàn)已退款，假如現(xiàn)已退款，直接返回。不然，向付出渠道建議退款，從而確保操作冪等，防止重復(fù)操作帶來疑問。假如建議退款失利（比方網(wǎng)絡(luò)或付出渠道毛病），會將使命放入延時行列，稍后重試。不然，直接返回。

經(jīng)過重試+冪等，能夠確保退款操作終究一定會完結(jié)。

2PC

2PC是指分布式業(yè)務(wù)的兩期間提交，經(jīng)過2PC來確保多個體系的數(shù)據(jù)一致性。比方下單過程中，觸及庫存、優(yōu)惠資歷等多個資本，下單時會首先預(yù)占資本（對應(yīng)2PC的第一期間），下單失利后會釋放資本（對應(yīng)2PC的回滾期間），成功后會運用資本（對應(yīng)2PC的提交期間）。關(guān)于2PC，網(wǎng)上有很多的說明，這兒不再持續(xù)打開。

分布式體系的可用性由其各個組件的可用性一起決議，要提高分布式體系的可用性，需求歸納提高構(gòu)成分布式體系的各個組件的可用性。

對于訂單體系而言，其主要構(gòu)成組件包括三類：存儲層、中間件層、效勞層。下面將分層說明訂單體系的可用性。

存儲層

存儲層的組件如MySQL、ES等自身現(xiàn)已完成了高可用，比方MySQL經(jīng)過主從集群、ES經(jīng)過分片仿制來完成高可用。存儲層的高可用依靠各個存儲組件即可。

中間件層

分布式體系會大量用到各類中間件，比方服務(wù)調(diào)用結(jié)構(gòu)等，這類中間件通常使用開源商品或由公司根底渠道供給，自身已具有高可用。

服務(wù)層

在分布式體系中，各個服務(wù)間經(jīng)過彼此調(diào)用來完成事務(wù)功用，一旦某個服務(wù)出現(xiàn)問題，會級聯(lián)影響調(diào)用方的其他服務(wù)，進而致使體系潰散。分布式體系中的依靠容災(zāi)是影響服務(wù)高可用的一個重要方面。

依靠容災(zāi)主要有如下幾個思路：

• 依賴超時設(shè)置；
• 依賴災(zāi)備；
• 依賴降級；
• 限制依賴使用資源；

訂單系統(tǒng)會依賴多個其它服務(wù)，也存在這個問題。當(dāng)前訂單系統(tǒng)通過同時采用上述四種方法，來避免底層服務(wù)出現(xiàn)問題時，影響整體服務(wù)。具體實現(xiàn)上，我們采用Hystrix框架來完成依賴容災(zāi)功能。Hystrix框架采用上述四種方法，有效實現(xiàn)依賴容災(zāi)。訂單系統(tǒng)依賴容災(zāi)示意圖如下所示

通過為每個依賴服務(wù)設(shè)置獨立的線程池、合理的超時時間及出錯時回退方法，有效避免服務(wù)出現(xiàn)問題時，級聯(lián)影響，導(dǎo)致整體服務(wù)不可用，從而實現(xiàn)服務(wù)高可用。

另外，訂單系統(tǒng)服務(wù)層都是無狀態(tài)服務(wù)，通過集群+多機房部署，可以避免單點問題及機房故障，實現(xiàn)高可用。

上面都是經(jīng)過架構(gòu)、技能完成層面來保證訂單體系的功能、安穩(wěn)性、可用性。實際中，有很多的事端是人為因素致使的，除了好的架構(gòu)、技能完成外，經(jīng)過標(biāo)準(zhǔn)、準(zhǔn)則來躲避人為事端也是保證功能、安穩(wěn)性、可用性的重要方面。訂單體系經(jīng)過完善需要review、計劃評定、代碼review、測驗上線、后續(xù)跟進流程來防止人為因素影響訂單體系安穩(wěn)性。

經(jīng)過以上辦法，技術(shù)團隊將訂單體系建造成了一個高功能、高安穩(wěn)、高可用的分布式體系。其中，交易體系tp99為150ms、查詢體系tp99時刻為40ms。全體體系可用性為6個9。

訂單體系通過上面介紹的全體晉級后，已經(jīng)是一個高功能、高安穩(wěn)、高可用的分布式體系。可是體系的的可拓展性還存在必定疑問，部分效勞只能通過筆直拓展（添加效勞器裝備）而不能通過水平拓展（加機器）來進行擴容。可是，效勞器裝備有上限，致使效勞全體容量受到約束。

到2015年5月的時分，這個疑問就比較突出了。其時，數(shù)據(jù)庫效勞器寫挨近單機上限。事務(wù)預(yù)期還會持續(xù)快速增長。為確保事務(wù)的快速增長，咱們對訂單體系開始進行第2次晉級。方針是確保體系有滿足的拓展性，然后支持事務(wù)的快速開展。

分布式體系的拓展性依賴于分布式體系中各個組件的可拓展性，關(guān)于訂單體系而言，其首要組成組件包含三類：存儲層、中間件層、效勞層。下面將分層闡明怎么進步各層的可拓展性。

存儲層

訂單體系存儲層首要依賴于MySQL耐久化、tair/redis cluster緩存。tair/redis cluster緩存自身即提供了極好的拓展性。MySQL能夠通過添加從庫來處理讀拓展疑問。可是，關(guān)于寫MySQL存在單機容量的約束。另外，數(shù)據(jù)庫的全體容量受限于單機硬盤的約束。

存儲層的可拓展性改造首要是對MySQL拓展性改造。

• 分庫分表

寫容量約束是受限于MySQL數(shù)據(jù)庫單機處理才能約束。假如能將數(shù)據(jù)拆為多份，不一樣數(shù)據(jù)放在不一樣機器上，就能夠便利對容量進行拓展。

對數(shù)據(jù)進行拆分通常分為兩步，第一步是分庫，行將不一樣表放不一樣庫不一樣機器上。通過第一步分庫后，容量得到必定提高。可是，分庫并不能處理單表容量超越單機約束的疑問，跟著事務(wù)的開展，訂單體系中的訂單表即遇到了這個疑問。

關(guān)于訂單表超越單庫容量的疑問，需求進行分表操作，行將訂單表數(shù)據(jù)進行拆分。單表數(shù)據(jù)拆分后，處理了寫的疑問，可是假如查詢數(shù)據(jù)不在同一個分片，會帶來查詢功率的疑問（需求聚合多張表）。因為外賣在線事務(wù)對實時性、功能請求較高。咱們關(guān)于每個首要的查詢維度均保留一份數(shù)據(jù)（每份數(shù)據(jù)按查詢維度進行分片），便利查詢。

具體來說，外賣首要涉及三個查詢維度：訂單ID、用戶ID、門店ID。對訂單表分表時，關(guān)于一個訂單，咱們存三份，別離依照訂單ID、用戶ID、 門店ID以必定規(guī)矩存儲在每個維度不一樣分片中。這么，能夠渙散寫壓力，一起，依照訂單ID、用戶ID、門店ID三個維度查詢時，數(shù)據(jù)均在一個分片，確保較高的查詢功率。

訂單表分表后，訂單表的存儲架構(gòu)如下所示：

可以看到，分表后，每個維度共有100張表，分別放在4個庫上面。對于同一個訂單，冗余存儲了三份。未來，隨著業(yè)務(wù)發(fā)展，還可以繼續(xù)通過將表分到不同機器上來持續(xù)獲得容量的提升。

分庫分表后，訂單數(shù)據(jù)存儲到多個庫多個表中，為應(yīng)用層查詢帶來一定麻煩，解決分庫分表后的查詢主要有三種方案：

• MySQL服務(wù)器端支持：目前不支持。
• 中間件。
• 應(yīng)用層。

由于MySQL服務(wù)器端不能支持，我們只剩下中間件和應(yīng)用層兩個方案。中間件方案對應(yīng)用透明，但是開發(fā)難度相對較大，當(dāng)時這塊沒有資源去支持。于是，我們采用應(yīng)用層方案來快速支持。結(jié)合應(yīng)用開發(fā)框架（SPRING+MYBATIS），我們實現(xiàn)了一個輕量級的分庫分表訪問插件，避免將分庫分表邏輯嵌入到業(yè)務(wù)代碼。分庫分表插件的實現(xiàn)包括如下幾個要點。

• 配置文件管理分庫分表配置信息；
• JAVA注解說明SQL語句分庫分表信息；
• JAVA AOP解析注解+查詢配置文件，獲取數(shù)據(jù)源及表名；
• MYBATIS動態(tài)替換表名；
• SPRING動態(tài)替換數(shù)據(jù)源。

通過分庫分表，解決了寫容量擴展問題。但是分表后，會給查詢帶來一定的限制，只能支持主要維度的查詢，其它維度的查詢效率存在問題。

• ES搜索

訂單表分表之后，對于ID、用戶ID、門店ID外的查詢（比如按照手機號前綴查詢）存在效率問題。這部分通常是復(fù)雜查詢，可以通過全文搜索來支持。在訂單系統(tǒng)中，我們通過ES來解決分表后非分表維度的復(fù)雜查詢效率問題。具體來說，使用ES，主要涉及如下幾點。

• 通過databus將訂單數(shù)據(jù)同步到ES。
• 同步數(shù)據(jù)時，通過批量寫入來降低ES寫入壓力。
• 通過ES的分片機制來支持?jǐn)U展性。

通過對存儲層的可擴展性改造，使得訂單系統(tǒng)存儲層具有較好的可擴展性。對于中間層的可擴展性與上面提到的中間層可用性一樣，中間層本身已提供解決方案，直接復(fù)用即可。對于服務(wù)層，訂單系統(tǒng)服務(wù)層提供的都是無狀態(tài)服務(wù)，對于無狀態(tài)服務(wù)，通過增加機器，即可獲得更高的容量，完成擴容。

通過對訂單系統(tǒng)各層可擴展性改造，使得訂單系統(tǒng)具備了較好的可擴展性，能夠支持業(yè)務(wù)的持續(xù)發(fā)展，當(dāng)前，訂單系統(tǒng)已具體千萬單/日的容量。

上面幾部分都是在介紹如何通過架構(gòu)、技術(shù)實現(xiàn)等手段來搭建一個可靠、完善的訂單系統(tǒng)。但是，要保障系統(tǒng)的持續(xù)健康運行，光搭建系統(tǒng)還不夠，運維也是很重要的一環(huán)。

早期，對系統(tǒng)及業(yè)務(wù)的運維主要是采用人肉的方式，即外部反饋問題，RD通過排查日志等來定位問題。隨著系統(tǒng)的復(fù)雜、業(yè)務(wù)的增長，問題排查難度不斷加大，同時反饋問題的數(shù)量也在逐步增多。通過人肉方式效率偏低，并不能很好的滿足業(yè)務(wù)的需求。

為提升運維效率、降低人力成本，我們對系統(tǒng)及業(yè)務(wù)運維進行自動化、智能化改進，改進包括事前、事中、事后措施。

• 事前措施

事前措施的目的是為提前發(fā)現(xiàn)隱患，提前解決，避免問題惡化。

在事前措施這塊，我們主要采取如下幾個手段：

1. 定期線上壓測：通過線上壓測，準(zhǔn)確評估系統(tǒng)容量，提前發(fā)現(xiàn)系統(tǒng)隱患；
2. 周期性系統(tǒng)健康體檢：通過周期檢測CPU利用率、內(nèi)存利用率、接口QPS、接口TP95、異常數(shù)，取消訂單數(shù)等指標(biāo)是否異常，可以提前發(fā)現(xiàn)提前發(fā)現(xiàn)潛在問題、提前解決；
3. 全鏈路關(guān)鍵日志：通過記錄全鏈路關(guān)鍵日志，根據(jù)日志，自動分析反饋訂單問題原因，給出處理結(jié)果，有效提高反饋處理效率。

• 事中措施

事中措施的目的是為及時發(fā)現(xiàn)問題、快速解決問題。

事中這塊，我們采取的手段包括：

1. 訂單監(jiān)控大盤：實時監(jiān)控訂單業(yè)務(wù)指標(biāo)，異常時報警；
2. 系統(tǒng)監(jiān)控大盤：實時監(jiān)控訂單系統(tǒng)指標(biāo)，異常時報警；
3. 完善的SOP：報警后，通過標(biāo)準(zhǔn)流程，快速定位問題、解決問題。

• 事后措施

事后措施是指問題發(fā)生后，分析問題原因，徹底解決。并將相關(guān)經(jīng)驗教訓(xùn)反哺給事前、事中措施，不斷加強事先、事中措施，爭取盡量提前發(fā)現(xiàn)問題，將問題扼殺在萌芽階段。

通過將之前人肉進行的運維操作自動化、智能化，提升了處理效率、減少了運維的人力投入。