TOP100summit：【分享實錄-華爲】微服務場景下的性能提高最佳實踐

本篇文章內容來自2016年TOP100summit華爲架構部資深架構師王啓軍的案例分享。
編輯：Cynthia

王啓軍:華爲架構部資深架構師。負責華爲的雲化、微服務架構推動落地，先後參與了華爲手機祥雲4.0、物聯網IoT2.0的架構設計。曾任噹噹網架構師，主導電商平臺架構設計，包括訂單、支付、價格、庫存、物流等。曾就任於搜狐負責手機微博的研發。「奔跑中的蝸牛」公衆號博主。

導讀：隨着雲時代的來臨，軟件架構突飛猛進，各類新技術層出不窮。「微服務」這個詞更是如火如荼，獲得了業界的普遍承認。可是，微服務並非銀彈，微服務架構下的性能問題在交付項目型的公司尤其重要。
本文主要圍繞微服務下的性能問題展開，目的是經過實際問題的解決過程，分析在服務拆分到必定粒度後，服務調用鏈變長，如何評估、提高總體性能。

1、問題的提出

在架構設計階段，你們比較關心的幾個基本要素包括：性能、可用性、一致性、擴展性、安全性。其中性能問題在起步階段每每容易被忽略，但隨着架構的逐步演進，規模愈來愈大，性能問題會變得愈來愈重要，極可能一個小小的改動，就能夠節省一半的服務器資源。

那性能到底表如今哪些方面？
● 一個是響應時間，也就是發送請求和返回結果的耗時；
● 另外一個是吞吐量，也就是單位時間內響應次數。

固然這兩個指標是在必定資源限制下才有意義。例如要佔用多大磁盤、多少CPU、多大內存等。吞吐量和響應時間之間也互爲影響，雖然這不是絕對的。

平時比較常見的性能問題包括：

● 內存泄露——致使內存耗盡
● 過載——突發流量，大量超時重試
● 網絡瓶頸——須要加載的內容太多
● 阻塞——無盡的等待
● 鎖——經過限制
● IO繁忙——大量的讀寫，分佈式
● CPU繁忙——計算型常見問題
● 長請求擁塞——鏈接耗盡

當吞吐量有問題的時候，咱們指望經過線程或者進程的方式來擴展，線程的方式比進程的方式要複雜得多，由於線程方式須要考慮共享數據變化的問題。

微服務就是一種進程擴展的模式。咱們能夠嘗試給微服務下一個定義：

一種架構風格。

● 單個服務儘可能專一一件事情，高內聚、低耦合；
● 進程隔離；
● 每一個服務能夠獨立的開發、測試、構建、部署；
● 小且靈活；

微服務架構帶來的優點包括：

● 交付週期。每一個服務能夠獨立開發、測試和交付，下降週期；
● 快速溝通。小團隊開發，下降代碼耦合度致使的溝通成本； 業務按服務拆分，新人不須要了解總體架構，上手快；
● 定製化。能夠根據市場需求，靈活多變地組合出新的業務場景；
● 隔離性。進程隔離方式，故障範圍有效控制；
● 技術棧。能夠根據需求，按服務選擇不一樣技術棧；
● 演進優化。能夠按照服務粒度進行演進優化；

同時帶來的問題包括：

● 架構複雜度。因爲服務數量暴增引發的各類複雜的架構問題。例如一致性問題、大量遠程接口調用的複雜度；
● 管理成本。服務數量爆炸致使管理、運維成本升高。咱們但願交付週期短，週期短必然引發變動快，變動是可用性的天敵。須要經過自動化、可視化的手段解決問題；
● 故障定位。例如一個涉及幾十個服務的請求，如何在故障發生的時候快速定位問題；
● 性能損失。本來一次調用能夠返回結果，如今須要流經幾個或幾十個服務才能返回結果，如何提高響應時間的問題； 因爲拆分致使的吞吐量下降，如何補償？雲化就意味着能夠橫向擴展。架構如何實現擴展？提高總體的系統吞吐量。

2、實踐過程

第一步，樹立目標。

一般你獲得的需求是這樣的：「速度要快！」「跟之前比，性能不能下降」。很明顯，這並非一個有效的指標。

如何設立目標呢？先列出幾種常見卻無效的目標。

● 平均響應時間1s
能夠看這組數據，[2, 5, 3, 4, 301, 4, 2, 8, 7, 3, 3, 1, 1, 8, 2] AVG(f)=23.6平均響應時間由於一次很是嚴重的超時致使偏離。沒法正確描述響應時間。

● 99%請求要在1S內完成
首先，不一樣的業務，響應時間不該該相同；
其次，單純的設定響應時間毫無心義，要在吞吐量之下進行設定；

● 支持100萬併發用戶？
首先，這並不等於系統吞吐量的設定；
其次，系統目前有多大數據量，增加速度是前提；

● 錯誤率
指標再高，有錯誤也沒用。

咱們能夠嘗試這樣來設定：
例以下單操做，
響應時間95%<1s
吞吐量>10萬tps
系統數據量：10億>訂單表>1億……
增加速度：1億/年
資源限制：服務器資源……
其餘影響因素……

同時，其餘目標也要同步設定，例如系統總體可用性、一致性等。

第二步，尋找瓶頸點。

首先進行壓力測試。能夠從生產環境引流進行測試，測試環境測出來的結果毫無心義。另外，要基於場景測試，單測某個功能無心義。

其次，要進行全面的監控，包括調用鏈分析，快速定位性能瓶頸點。

第三步，優化。

優化的手段有不少，包括：同步轉異步、阻塞轉非阻塞、數據冗餘、數據拆分、數據合併、壓縮、簡化業務環節等等。關鍵取決於應用場景和成本。

服務化框架

如圖1所示，一個電商裏的詳情頁面會調用價格、庫存、商品等服務，綜合展現信息，若是是串行調用，總耗時等於每一個服務耗時之和；若是是並行調用，總耗時等於三個服務耗時的最大值，性能提高顯著。

還有不少其餘的優化點，例如：
● 使用高效的序列化協議，protobuf、thrift等協議要比http+json的方式好不少，能夠在服務內部使用；
● 採用長鏈接，避免重複創建鏈接致使的性能損失；
● 業務線程和IO線程隔離等。

消息中間件

經過消息中間件能夠削峯填谷，提高吞吐量。如圖2，下單操做直接發送到MQ即返回，由MQ保障最終一致性，還可以下降響應時間。把依賴關係從強依賴變成弱依賴。也就是說，訂單系統的暫時不可用，對下單操做無影響。另外，MQ的吞吐量遠遠大於關係型數據庫，MQ擴展相對要方便不少。

固然，使用MQ也有必定的問題，有一個一致性的時間窗口，對於要求強一致的業務來講，是比較致命的。

分佈式緩存

緩存是被用來提高性能的利器。本地緩存不能共享，會致使比較大的內存浪費，另外一方面，垃圾回收也會影響業務服務。在微服務架構中，咱們廣泛要求把狀態外置到緩存、數據庫中，大型應用多采用分佈式緩存。

因爲數據庫擴展起來比較複雜，帶來的後遺症較多，用緩存來平衡數據庫的壓力是很是好的作法。

分佈式緩存，例如redis、memcache，吞吐量大概在10萬qps這個級別，相對數據庫幾千qps來講是一個很是大的提高。

固然，分佈式緩存帶來的問題就是一致性的問題，何時去更新緩存？若是緩存更新失敗、數據庫更新成功怎麼辦？

數據庫

數據庫的優化是很是直接有效的。

以優先級來排序，優化的方式以下：
● 索引、冗餘、批量寫入
● 減少鎖粒度
● 減少複雜查詢
● 適當轉移事務處理
● 提高硬件性能
● 讀寫分離
● 分庫
● 垂直分表
● 水平分表
● 根據業務狀況選擇NoSql

3、案例分析

如圖3，在電商中，一個價格服務，爲了提高寫的效率，能夠採用消息中間件，爲了解決重複提交的問題，（特別是當某個系統不可用的時候，用戶會頻繁提交，致使人爲的風暴）能夠經過緩存去作排重。

若是一個用戶提交了一百萬價格變更信息，另外一個用戶提交了一個價格修改請求，這個請求會被那一百萬請求阻塞很長時間，這時候就須要消息中間件有優先級的概念，若是不能作優先級，能夠經過創建多個隊列分類來解決問題。

若是一個用戶提交了一百萬條價格修改，發現其中有一個錯了，改了其中一條再提交，按照上述方式會致使新版本被老版本覆蓋，咱們須要經過創建版本號的方式解決這個問題。

4、總結

● 並非全部的地方都須要高性能，須要權衡代碼可讀性維護性，架構複雜度 ；
● 優化以前，找到驅動力；
● 正確對待優化帶來的其餘問題。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峯會，華爲精益敏捷專家陳軍將分享《華爲百人團隊精益看板演進變革之路》；華爲雲計算測試經理李超峯將分享《華爲雲虛擬化質量平臺建設實踐》。

TOP100全球軟件案例研究峯會已舉辦六屆，甄選全球軟件研發優秀案例，每一年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。大會開幕式單天體驗票申請入口