一. 架構(gòu)高可用評價(jià)維度：

• 指系統(tǒng)在面對各種異常時(shí)可以提供正常服務(wù)的能力
• 系統(tǒng)的可用性可以用系統(tǒng)停服務(wù)的時(shí)間和正常服務(wù)時(shí)間的比例來衡量
• 系統(tǒng)不可用時(shí)間(故障時(shí)間=故障修復(fù)時(shí)間點(diǎn)-故障發(fā)現(xiàn)時(shí)間點(diǎn))
• 幾個(gè)9
  1. 4個(gè)9的可用性(99.99%)
     ? 具備自動恢復(fù)能力的高可用
     ? 一年停機(jī)的時(shí)間不能超過53分鐘
     ? 3652460/10000 = 53分鐘
  2. 5個(gè)99的可用性(99.999%)
     ? 極高可用性
     ? 一年停機(jī)的時(shí)間不能超過5分鐘
     ? 3652460/100000=5分鐘

二. 服務(wù)分級

2.1 服務(wù)名和服務(wù)級別對應(yīng)關(guān)系的梳理翰萨，例如：

  ![image.png](https://upload-images.jianshu.io/upload_images/5928323-6543199acbb62a33.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

2.2 事故級別定義：

  ? 確定服務(wù)級別
  ? 使用最合適衡量標(biāo)準(zhǔn)確定事故的影響面

WechatIMG3.jpeg

WechatIMG3.jpeg

三. 穩(wěn)定性按系統(tǒng)層次劃分:

2.jpeg

3.1 接入層穩(wěn)定性設(shè)計(jì)大綱

3.1.1 接入層Session設(shè)計(jì)遇到的問題择同？

• 高可用主要基于服務(wù)無狀態(tài)
• 事實(shí)上業(yè)務(wù)總是有狀態(tài)的遭顶，如鸠儿，用戶點(diǎn)餐，需要記錄
• 這些有狀態(tài)的信息會隨用戶操作變化而發(fā)生更新

3.1.2 接入層Session設(shè)計(jì)

• 服務(wù)端設(shè)計(jì)：

1. 集群(多機(jī))設(shè)計(jì)-Session復(fù)制陪毡，根據(jù)路由策略路由到任一機(jī)器

- 優(yōu)勢：高可用保證
- 劣勢：海量的session復(fù)制油吭，占用帶寬，每臺機(jī)器全量拷貝纽绍，會出現(xiàn)oom蕾久。

2. Session綁定：通過hash(ID)，路由到指定的session服務(wù)器拌夏，存儲方式：本地內(nèi)存僧著，redis，mysql,nosql

- 優(yōu)勢：高可用保證障簿，M-S盹愚。

• 客戶端設(shè)計(jì)：

1. 客戶端保持session:

 - Session由服務(wù)端生成，存儲到客戶端
 - 每次請求攜帶客戶端Session
 - 服務(wù)端若有更新返回給客戶端存儲站故。
 - 對于app存儲到Native皆怕，對于web存儲到Cookie中。

• Session高可用集群：

  • 接入層無狀態(tài)化
  • 統(tǒng)一的高可用Session服務(wù)器
  • 接入層分布式讀寫Session集群
  • 狀態(tài)分離：
    1.接入層本身無狀態(tài)西篓。
    2.Session集群有狀態(tài)愈腾。
    3.存儲：分布式緩存，sql或nosql數(shù)據(jù)庫岂津。

  3.1.3 模塊和數(shù)據(jù)分離：

  • 接入層模塊無狀態(tài)：
    1. 動態(tài)線性伸縮
    2. 冗余
  • Session數(shù)據(jù)統(tǒng)一分布式存儲：
    1. 數(shù)據(jù)冗余保證
    2. 高可用性保證

  3.1.4 接入層最佳實(shí)踐:

  1.模塊和數(shù)據(jù)分離虱黄。
  2.Session綁定。
  3.不存儲Session吮成。

3.2 邏輯層穩(wěn)定性設(shè)計(jì)大綱：

3.2.1 邏輯層職責(zé)：整個(gè)系統(tǒng)中業(yè)務(wù)邏輯的處理橱乱。

3.2.2 邏輯層如何設(shè)計(jì)?

1. 業(yè)務(wù)間物理垂直劃分方式
   優(yōu)點(diǎn)：
   1.業(yè)務(wù)間完全解耦
   2.業(yè)務(wù)間互不影響
   3.業(yè)務(wù)模塊獨(dú)立。
   4.業(yè)務(wù)模塊獨(dú)立粱甫。
   5.效率高泳叠。

3.2.3 無狀態(tài)業(yè)務(wù)邏輯層設(shè)計(jì)：

• 關(guān)鍵因素：
  1.業(yè)務(wù)邏輯層不保存請求狀態(tài)。
  2.業(yè)務(wù)邏輯層不保存數(shù)據(jù)茶宵。
  3.所有業(yè)務(wù)邏輯層服務(wù)器完全對稱析二。
  4.當(dāng)一臺或者多臺宕機(jī)。
  5.請求提交到集群中的任意可用服務(wù)器。
  6.業(yè)務(wù)邏輯層高可用-負(fù)載均衡叶摄。
• 負(fù)載均衡（LVS/Nginx）：
  1.服務(wù)器可用狀態(tài)實(shí)時(shí)監(jiān)測的機(jī)制。
  2.自動轉(zhuǎn)移失敗任務(wù)(機(jī)器)的機(jī)制安拟。
  3.請求量和數(shù)據(jù)量較高蛤吓，將流量和數(shù)據(jù)分?jǐn)偟郊褐卸嗯_服務(wù)器的能力。
  4.通過心跳機(jī)制發(fā)現(xiàn)下游服務(wù)器不可用糠赦，剔除掉会傲。
  5.一旦服務(wù)器可用，可以自動重連恢復(fù)拙泽。

3.2.4 業(yè)務(wù)邏輯層如何異步調(diào)用?
優(yōu)缺點(diǎn)：
1.異步調(diào)用優(yōu)點(diǎn)：線程(調(diào)用者)非阻塞淌山，一直Running，CPU利用率高顾瞻，系統(tǒng)性能高泼疑，系統(tǒng)吞吐量高。
2. 異步調(diào)用缺點(diǎn)：實(shí)現(xiàn)成本稍高荷荤，代碼可讀性差退渗。

方案一（業(yè)務(wù)解耦考慮）：消息隊(duì)列方案（kafka）：

• 通過消息隊(duì)列(緩沖、持久化蕴纳、解決異步)實(shí)現(xiàn)異步調(diào)用
  例子：
  新用戶注冊請求会油，假設(shè)需要2步
  ? 第一步:用戶名和密碼寫入數(shù)據(jù)庫
  ? 第二步:發(fā)送注冊成功郵件

• 異步方式：
  ? 新用戶注冊請求寫入消息隊(duì)列，直接返回成功給請求調(diào)用者
  ? 業(yè)務(wù)邏輯層通過成消息隊(duì)列中讀取請求古毛，異步執(zhí)行第一步和第二步 ? 調(diào)用者不阻塞翻翩，效率高
  ? 系統(tǒng)性能高

方案二 (性能提升考慮)：nio,netty,nodejs,vert.x。

3.jpeg

高性能純異步網(wǎng)絡(luò)調(diào)用設(shè)計(jì):

? server端連接池+server端收發(fā)隊(duì)列;
? client端連接池+client端收發(fā)隊(duì)列; ? 超時(shí)隊(duì)列與超時(shí)管理器;
? 上下文管理器+狀態(tài)機(jī);

3.2.5 業(yè)務(wù)邏輯層如何分級管理:
1.部署層面：
? 服務(wù)部署隔離
? 避免故障帶來的連鎖反應(yīng)
? 核心系統(tǒng)部署在物理機(jī)上
? 核心系統(tǒng)部署不同的機(jī)房 ? 邊緣系統(tǒng)部署虛擬機(jī)
? 邊緣系統(tǒng)公用機(jī)器

2. 監(jiān)控分級層面
   ? 核心服務(wù)更多類型的監(jiān)控
   – 進(jìn)程
   – 語義
   – 錯(cuò)誤日志 – ......
   ? 監(jiān)控粒度更細(xì)致
   ? 郵件和短信發(fā)送通知

3. 響應(yīng)分級層面：
   ? 核心服務(wù)開發(fā)響應(yīng)迅速
   ? 核心服務(wù)上線響應(yīng)迅速
   ? 核心服務(wù)運(yùn)維響應(yīng)迅速
   ? 核心服務(wù)上線問題處理迅速

3.2.6 設(shè)置合理超時(shí)：
1.設(shè)置合理超時(shí)的重要性：

• 業(yè)務(wù)邏輯層和下游模塊交互次數(shù)多
• 設(shè)置合理超時(shí)非常重要
• 下游服務(wù)宕機(jī)稻薇、線程死鎖等嫂冻，請求得到不到響應(yīng) – 請求占用資源
• 調(diào)用方得不到響應(yīng)，用戶體驗(yàn)糟糕

2.設(shè)置合理超時(shí)：

• 請求的超時(shí)設(shè)置根據(jù)請求的平均響應(yīng)延遲:經(jīng)驗(yàn)值
• 超時(shí)時(shí)間是平均響應(yīng)延遲的2倍颖低，避免過長時(shí)間等待
• 響應(yīng)延遲高絮吵，超時(shí)時(shí)間設(shè)置長些：3S
• 響應(yīng)延遲低，超時(shí)時(shí)間設(shè)置短些100MS
• 下游請求超時(shí)后忱屑，業(yè)務(wù)層根據(jù)預(yù)設(shè)的調(diào)度策略
  1. 繼續(xù)重試
  2. 一般3次
  3. 多次無好處
  4. 請求轉(zhuǎn)移到下游其他同樣服務(wù)上

3.2.7 業(yè)務(wù)邏輯層服務(wù)降級設(shè)計(jì)：
1.降級必要性:

• 網(wǎng)站高峰期蹬敲，并發(fā)量大
• 服務(wù)能力有限
• 性能下降
• 服務(wù)宕機(jī)
• 系統(tǒng)雪崩情況

2.降級方案：

• 拒絕部分請求
• 關(guān)閉請求

3.拒絕部分請求
? 拒絕低優(yōu)先級服務(wù)的調(diào)用
? 減少服務(wù)調(diào)用并發(fā)數(shù)
? 確保核心服務(wù)正常使用

4. 關(guān)閉部分服務(wù)：
   ? 非核心服務(wù)直接關(guān)閉
   ? 業(yè)務(wù)邏輯層屏蔽掉
   ? 不再調(diào)用
   ? 節(jié)約系統(tǒng)開銷
   ? 保證核心服務(wù)的正常響應(yīng)
   ? 秒殺活動
   ? 雙11.11活動

3.2.8 業(yè)務(wù)邏輯層如何做到冪等設(shè)計(jì)?
1.天然冪等，如把離線消息設(shè)置為已讀莺戒，多次設(shè)置都是一樣的伴嗡。
2.非冪等->冪等設(shè)計(jì)：

如： 支付

• 支付ID，支付狀態(tài)
• 每次支付前从铲，判斷支付狀態(tài)瘪校，未支付狀態(tài)繼續(xù)進(jìn)行，已支付了就中止

3.2.9 業(yè)務(wù)邏輯層穩(wěn)定性總結(jié)：

? 無狀態(tài)
? 冗余部署
? 異步
? 超時(shí)機(jī)制
? 請求分級
? 冪等設(shè)計(jì)
? 高性能

3.3 數(shù)據(jù)存儲層穩(wěn)定性設(shè)計(jì)大綱

3.3.1 數(shù)據(jù)存儲高可用的幾個(gè)原理：

3.3.1.1 CAP定理與設(shè)計(jì)

• 一致性(Consistency)、可用性(Availability)阱扬、分區(qū)可容忍性(Tolerance of network Partition)泣懊。
• 在分布式環(huán)境下，三者不可能同時(shí)滿足
  -分布式存儲系統(tǒng)需要能夠自動容錯(cuò)麻惶，也就是說分區(qū)容忍性需要保證：

1. 保證一致性
   – 強(qiáng)同步復(fù)制
   – 主副本網(wǎng)路異常馍刮，寫操作被阻塞，可用性無法保證
2. 保證可用性
   – 異步復(fù)制機(jī)制
   – 保證了分布式存儲系統(tǒng)的可用性 – 強(qiáng)一致性無法保證
3. 一致性和可用性需要折中權(quán)衡
4. 不允許數(shù)據(jù)丟失(保證強(qiáng)一致性)
   ? 金融
   2.小概率丟失允許(保證可用性)
   ? 消息

3.3.1.1 2PC協(xié)議與設(shè)計(jì)

? 實(shí)現(xiàn)分布式事務(wù)

? 兩類節(jié)點(diǎn)
– 協(xié)調(diào)者
? 1個(gè)
– 事務(wù)參與者
? 多個(gè)
? 每個(gè)節(jié)點(diǎn)都會記錄Commit Log窃蹋，保證數(shù)據(jù)可靠性

? 兩階段提交由兩個(gè)階段組成

1. 請求階段
2. 提交階段

3.3.1.2 Paxos協(xié)議與設(shè)計(jì)

• 用于解決多個(gè)節(jié)點(diǎn)之間的一致性問題
• 多個(gè)節(jié)點(diǎn)卡啰，只有一個(gè)主節(jié)點(diǎn)
• 主節(jié)點(diǎn)掛掉，能夠選舉新的節(jié)點(diǎn)
• 主節(jié)點(diǎn)往往以操作日志的形式同步備節(jié)點(diǎn)
• 角色：

1. 提議者( Proposer)
2. 接受者( Acceptor)

• 執(zhí)行步驟：

1. 批準(zhǔn)( accept)
   Proposer發(fā)送accept消息到Acceptor要求接受某個(gè)提議者
2. 確認(rèn)(acknowledge)
   如果超過一半的Acceptor接受警没，意味著提議值生效匈辱， Proposer發(fā)送acknowledge消息通知所有的Acceptor提議
3. 生效
   2PC協(xié)議與Paxos協(xié)議

3.3.2 數(shù)據(jù)存儲層冗余我們?nèi)绾巫?/h3>

3.3.2.1 數(shù)據(jù)復(fù)制：

1. 基于日志

2. Master-Slave:
   – MySQL、MongoDB

3. Replic Set:
   – MongoDB

4. 雙寫

• 存儲層多主對等結(jié)構(gòu)
• 數(shù)據(jù)模塊層對存儲層雙寫
• 比較靈活
• 數(shù)據(jù)模塊層成本較高

3.3.3 數(shù)據(jù)備份落地

• 數(shù)據(jù)冷備份
• 數(shù)據(jù)熱備份

3.3.3.1 數(shù)據(jù)冷備份:

將數(shù)據(jù)復(fù)制到某種存儲介質(zhì)上(磁盤等)

• 優(yōu)點(diǎn):

1. 簡單杀迹、廉價(jià)
2. 成本和技術(shù)難度都較低

• 缺點(diǎn):

1. 定期備份
2. 數(shù)據(jù)一致性保證不了
3. 恢復(fù)時(shí)間長亡脸，系統(tǒng)高可用保證不了

3.3.3.2 數(shù)據(jù)熱備份:

1.方法：

• Online異步熱備份
• Online同步熱備份

2.數(shù)據(jù)異步熱備份：

• 多份數(shù)據(jù)副本寫入異步完成
• 應(yīng)用程序?qū)懭氤晒σ环輸?shù)據(jù)后，即返回

• 由存儲系統(tǒng)異步寫入其他副本

  
  
  4.jpeg

3.數(shù)據(jù)同步熱備份：

• 多份數(shù)據(jù)副本寫入同步完成
• 應(yīng)用程序收到所有副本的寫入成功
• 應(yīng)用程序收到部分服務(wù)的寫入成功佛南，可能都成功(網(wǎng)絡(luò)故障無法返回成功resp)
• 為了提高寫入性能梗掰，應(yīng)用程序并發(fā)寫入數(shù)據(jù)
• 沒有主從之分，完全對等
• 響應(yīng)延遲是最慢的那臺服務(wù)器嗅回，而不是所有響應(yīng)延遲之和

5.jpeg

3.3.3.3 數(shù)據(jù)存儲層失效轉(zhuǎn)移機(jī)制：

1. 失效確認(rèn)：

• 是否宕機(jī)
• 心跳

2. 訪問轉(zhuǎn)移：

• 訪問路由到非宕機(jī)機(jī)器 ? 存儲數(shù)據(jù)完全一致

3. 數(shù)據(jù)恢復(fù)：

• Master-Slave
• 日志

3.3.3.4 數(shù)據(jù)存儲層如何做無縫數(shù)據(jù)遷移：

• 數(shù)據(jù)類型：
  1.時(shí)效性數(shù)據(jù)及穗，特點(diǎn)：過期作廢(1個(gè)月)，遷移簡單
  2.核心數(shù)據(jù)绵载，特點(diǎn)：永久有效埂陆，遷移復(fù)雜
  時(shí)效性數(shù)據(jù)遷移方案：
  核心數(shù)據(jù)遷移方案：

3.3.3.4 數(shù)據(jù)存儲層高可用最佳實(shí)踐

• 可用性
• 可靠性
• 一致性
• 備份
• 轉(zhuǎn)移

3.4 分布式緩存層穩(wěn)定性設(shè)計(jì)大綱：

3.4.1 分布式緩存類型:

• Memcached
• Redis
• 自主研發(fā)

3.4.2 高可用架構(gòu)緩存原則：

• 緩存就是緩存，不是磁盤數(shù)據(jù)庫娃豹。
• 一旦緩存不可用焚虱，查詢數(shù)據(jù)庫。
• 那么問題來了懂版，數(shù)據(jù)會不會掛掉?

1. 緩存集群鹃栽，宕機(jī)某臺幾率大，宕機(jī)多臺幾率小
2. 宕機(jī)某臺躯畴，對數(shù)據(jù)庫影響不大民鼓，不會產(chǎn)生雪崩
3. 預(yù)估宕機(jī)一臺，數(shù)據(jù)庫可以承受的最大壓力

3.4.3 高可用架構(gòu)緩存一致性

• 多份數(shù)據(jù)副本（數(shù)據(jù)庫蓬抄、多份緩存）丰嘉，數(shù)據(jù)一致性問題會存在
• 強(qiáng)一致性較難
• 追求最終一致性

3.4.4 高可用架構(gòu)緩存命中率:

• 業(yè)務(wù)不同，命中率不同
• 命中率80%+
• 相對靜態(tài)數(shù)據(jù)緩存
• 緩存時(shí)間長些
• 定期查看緩存命中情況嚷缭，適當(dāng)調(diào)整緩存對象

3.4.5 高可用架構(gòu)緩存最佳實(shí)踐

• 業(yè)務(wù)特點(diǎn)饮亏，選用多級緩存

1. Local
2. Process
3. Distrubute

• 緩存高可用性保證
• 緩存宕機(jī)耍贾，數(shù)據(jù)庫最大壓力評估
• 緩存一致性
• 最終一致性
• 強(qiáng)一致性場合少
• 分布式鎖、分布式隊(duì)列

四.性能評估,擴(kuò)容:

4.1 性能評估

4.1.1 目的：

• 找出系統(tǒng)性能瓶頸
• 提供性能優(yōu)化方案
• 達(dá)到硬件和軟件的合理配置路幸，使系統(tǒng)資源使用平衡

4.1.2 性能評估工具(Linux)

4.1.2.1 CPU性能評估:

1.cup

• us:用戶進(jìn)程消耗CPU時(shí)間百分比荐开，us值高，用戶進(jìn)程消耗CPU時(shí)間多劝赔，如果長期大于50%誓焦，優(yōu)化程序;
• sy:內(nèi)核進(jìn)程消耗的CPU時(shí)間百分比;
• us + sy參考值為80%，如果us + sy大于80%着帽，說明可能存在CPU不足。

2. 進(jìn)程
   ? r:運(yùn)行和等待CPU時(shí)間片的進(jìn)程數(shù)移层，如果長期大于系統(tǒng)CPU的個(gè)數(shù)仍翰，CPU遇到瓶頸，需要擴(kuò)展CPU观话。
   ? b:等待資源的進(jìn)程數(shù)予借，比如正在等待磁盤I/O、網(wǎng)絡(luò)I/O等频蛔。

3.問題:

• 系統(tǒng)CPU整體利用率不高灵迫，而應(yīng)用響應(yīng)緩慢?
  – 選擇單線程還是多個(gè)線程?
• CPU閑置問題

4.1.2.2 內(nèi)存性能評估：

1. free工具
   ? free [-m/-g]
   ? 應(yīng)用程序可用內(nèi)存數(shù)量:
2. 經(jīng)驗(yàn)值
   ? 應(yīng)用程序可用內(nèi)存/系統(tǒng)物理內(nèi)存 > 70% 內(nèi)存充足
   ? 應(yīng)用程序可用內(nèi)存/系統(tǒng)物理內(nèi)存<20% 內(nèi)存不足，需要增加內(nèi)存
   ? 20%<應(yīng)用程序可用內(nèi)存/系統(tǒng)物理內(nèi)存<70%內(nèi)存基本夠用

4.1.2.3 磁盤I/O性能評估：

4.1.2.3.1 iostat工具：

? iostat –xdk 1
? 磁盤塊設(shè)備分布
? rkB/s每秒讀取數(shù)據(jù)量kB;
? wkB/s每秒寫入數(shù)據(jù)量kB;
? svctm I/O請求的平均服務(wù)時(shí)間晦溪，單位毫秒;
? await I/O請求的平均等待時(shí)間瀑粥，單位毫秒;值越小，性能越好;
? util 一秒中有百分幾的時(shí)間用于I/O操作三圆。接近100%時(shí)狞换，表示磁盤帶寬跑滿，需 要優(yōu)化程序或者增加磁盤;
? rkB/s舟肉、wkB/s根據(jù)系統(tǒng)應(yīng)用不同會有不同的值修噪，但有規(guī)律遵循:長期、超大數(shù) 據(jù)讀寫路媚，肯定不正常黄琼，需要優(yōu)化程序讀取。
? svctm的值與await的值很接近整慎，表示幾乎沒有I/O等待脏款，磁盤性能好，如果await 的值遠(yuǎn)高于svctm的值院领，則表示I/O隊(duì)列等待太長弛矛，需要優(yōu)化程序或更換更快磁 盤。

4.1.2.3.2 ifstat工具:

• 各個(gè)網(wǎng)卡的in比然、out
• 觀察網(wǎng)絡(luò)負(fù)載情況
• 程序網(wǎng)絡(luò)讀寫是否正常 – 程序網(wǎng)絡(luò)I/O優(yōu)化
• 增加網(wǎng)絡(luò)I/O帶寬

Load average分析:

1. 含義： 任務(wù)隊(duì)列的平均長度
   1分鐘丈氓、5分鐘、15分鐘前到現(xiàn)在平均值
2. 分析方法：
   這三個(gè)值的大小一般不能大于系統(tǒng)CPU的核數(shù)，如果三個(gè)值長期大于CPU的核數(shù)說明CPU很繁忙万俗，負(fù)載很高影響機(jī)器整體系統(tǒng);相反如果這三個(gè)值小于CPU個(gè)數(shù)湾笛，表示CPU比較空閑。

4.1.3 應(yīng)用程序性能評估：

1. 壓力測試
   ? 確認(rèn)模塊的最大吞吐量 – QPS闰歪、TPS
   2.模塊單機(jī)壓力極限衡量標(biāo)準(zhǔn)
   • CPU極限
     ? 線程32
     ? CPU3200%
   • 內(nèi)存極限
     ? 內(nèi)存32G
     ? 應(yīng)用占完了嚎研，排除內(nèi)存泄露的可能
   • 磁盤I/O極限
     ? util 100%
   • 網(wǎng)絡(luò)I/O極限
     ? 100Mb
     ? in、out帶寬跑滿了
     3.日志:
     根據(jù)日志統(tǒng)計(jì)出最大的QPS库倘、TPS

4.2 系統(tǒng)擴(kuò)容原則:

4.2.1系統(tǒng)使用和優(yōu)化原則

• 始終保留一定量的空閑資源临扮。
  1. 多少合適?根據(jù)應(yīng)用的特點(diǎn)，比如是否有突發(fā)性使用增長?
  2. 一般情況下教翩，保留至少50%的系統(tǒng)資源杆勇，以應(yīng)付流量增長(流量翻一倍);
  3. 一般情況下，資源使用率達(dá)到80%時(shí)饱亿，需要考慮擴(kuò)容的事兒蚜退。
• 系統(tǒng)硬件達(dá)到合理的配置，資源消耗均衡為目標(biāo)
  1.系統(tǒng)性能的木桶理論
• 應(yīng)用程序?qū)Y源的使用要均衡(理想目標(biāo))：
  理想狀況為:CPU消耗到50%的時(shí)候彪笼，磁盤I/O也到50%钻注，網(wǎng)絡(luò)I/O也到50%，內(nèi) 存使用也到50%;