大型網站後臺穩定性技術策略

https://blog.csdn.net/paolei/article/details/94390330

背景簡介

　　對於大型應用後臺系統來講，穩定性相當重要。目前愈來愈多的大型應用系統採用微服務架構，更加須要關注穩定性的技術能力建設。穩定性是服務系統基礎能力的體現。

　　基礎知識

　　在介紹穩定性技術策略主題以前，咱們首先梳理一些基礎概念和知識。

　　針對咱們業務後臺系統建設，任何大型業務後臺系統絕對不是一蹴而就。它是伴隨着業務不一樣階段，不斷進行演進的過程。若是經歷過從 0 到 1 建設一個業務後臺系統的同窗，都會有相似的體會。

　　啓動階段

　　啓動階段，業務模型相對簡單，用戶量少，這時候咱們能夠將全部的系統模塊耦合在一個工程裏面，進行單機部署。這時候可能僅僅須要將業務系統與數據庫進行隔離。

　　探索階段

　　探索階段，業務模型不斷演進，用戶量增長，單機服務能力瓶頸凸顯。這時候就須要由單機服務部署向集羣服務部署來優化，利用負載均衡將請求合理分配，減小單機服務壓力。另一個方面，數據量不斷的增長，也須要考慮針對數據來進行水平的擴展(主從部署，讀寫分離)。

　　在這一階段，咱們僅僅是作了集羣擴展，但全部的業務代碼都在同一個工程維護，全部的數據信息都在同一個數據庫中存儲。隨着團隊的擴充與業務交互不斷複雜化，在工程維護上存在很大的風險，工程研發效率受到制約，業務代碼之間的耦合也難以清晰，系統可靠性存在很大風險，一個 bug 可能會形成整個應用的崩潰不可用。

　　發展階段

　　若是咱們比較幸運，業務持續快速發展，對於業務角色模型理解愈來愈清晰，業務角色模型之間的交互愈來愈肯定。這時候就須要咱們基於對業務充分的理解前提下進行垂直拆分。不一樣的業務模型會部署到不一樣的系統工程中，工程之間經過接口來進行交互。這樣工程內業務高度集中，工程間經過接口服務來進行解耦。這時候無論是系統維護，仍是業務模塊維護，都將大大的提升效率。數據部分一樣垂直拆分，不一樣業務數據拆分到不一樣的數據庫，從而提升單機數據庫的能力。

　　拿電商系統的結構來講，以下圖所示：

　　

　　基於業務模型分爲幾個大的系統服務，系統服務之間經過內部 RPC 接口來進行交互。

　　成熟階段

　　上面是基於大的業務模型進行劃分，隨着業務複雜度愈來愈高，咱們必將對大業務模型，基於功能或者業務邊界進行更細粒度的拆分。好比說，咱們能夠將產品中心劃分爲：基礎信息中心，庫存管理中心，SKU 中心等。

　　這時候就涉及到微服務的拆分與治理工做。

　　微服務的拆分原則咱們應該注意：業務功能單一； 服務間業務邊界清晰；拆分粒度合理； 分層劃分合理。

　　從研發的角度來講，微服務帶來的好處：研發效率提高；代碼質量更優；可以獨立部署；單模塊複雜度下降。上面提到的產品中心咱們能夠拆分不少小的服務來提供，以下圖所示：

　　

　　細粒度的拆分，也會帶來必定的挑戰：

　　微服務劃分單元越細，總體服務維護很是複雜；

　　微服務經過 RPC 接口交互，整個鏈路可能會不清晰；

　　單服務的修改或者優化會受到其餘模塊的牽制。

　　固然這些挑戰都是咱們須要思考與解決的問題，並不能抹殺微服務的優勢。

　　大型業務後臺系統，不斷的微服務化，帶來系統之間的接口交互與依賴管理也愈來愈重要。咱們須要從總體上考慮咱們如何保證這樣一個流量併發高，業務模型複雜，服務依賴交互多的大型微服務後臺應用系統的穩定性。不能因爲某個不利因素來影響整個業務微服務系統的不可用。接下來咱們將重點介紹穩定性相關的內容。

　　穩定性技術策略

　　什麼是穩定性

　　對於大型微服務系統，在錯綜複雜的服務邏輯各類交互情景下，面對各類未知的條件變化，總體系統依舊可以正常平穩的提供服務，這即是穩定性。

　　影響穩定性的因素

　　系統穩定性影響因素很是多，舉例來講：

　　1. 服務間的依賴：某個服務 BUG 形成其餘依賴服務的不可用；

　　2. 業務邏輯變動：業務邏輯不斷迭代演變，新老服務的不兼容；

　　3. 訪問流量激增：流量忽然增長，好比咱們進行促銷活動期間，致使服務壓力過大 ，達到服務能力上限，從而致使服務崩潰；

　　4. 機器老化異常：任何機器和人同樣，都有生老病死，隨着長時間的運行，也會有磨損，所以某個機器故障，也是可能的異常。

　　還有其餘各方面的因素，在這裏就不進行窮盡了，你們能夠思考一下，還有那些經典的影響因素。

　　穩定性的衡量標準

　　穩定性衡量標準通常用 N 個 9 來衡量。如表格所示：

　　名稱級別年度停機時間描述2 個 999%87.6 小時基本可用3 個 999.9%8.8 小時較高可用性4 個 999.99%53 分鐘技術容災能力可用性5 個 999.999%5 分鐘極高可用性

　　好比說某個系統網站整年穩定性達到 4 個 9 ，意味着整年服務不可用的時間小於等於 53 分鐘。

　　穩定性技術策略

　　穩定性的技術策略，是咱們本文介紹的重點，從大的方面來講，穩定性技術策略包含：監控，冗餘，限流，降級，回滾，重試。

　　監控

　　監控是指對整個系統服務進行實時的監控操做，準確反饋系統運行狀態，可以作到及時發現異常故障，記錄詳細日誌與數據，提升故障發現，定位，解決的效率。從而提升系統服務總體穩定性。

　　監控是保證穩定性最基礎工做。咱們將重點介紹監控須要從幾個方面考慮？ 有哪些監控方向？

　　監控能夠分爲如下幾類來進行：

　　流量監控

　　流量監控包括：PV、 UV、 IP，熱門頁面，用戶響應時間。

　　這些基本的流量指標就不在這裏向你們詳細說明了，若是有不太清楚的同窗能夠本身搜索一下。

　　在流量監控這塊，咱們須要注意的是：流量毛刺。流量毛刺每每表明了系統某個風險點或者異常狀況的發生。

　　一個正常業務的流量趨勢具有周期一致性特徵。好比說，一個業務天天的流量峯值通常在中午 12:00 和下午 18:00，那麼這種峯值在沒有特殊狀況出現的前提下，應該會遵循該峯值時間規律。 那麼流量毛刺是啥呢？ 以下圖所示：

　　

　　從圖中左側部分能夠看到，8 點鐘有流量的突增，這時候咱們須要確認爲何會有流量的突增。是業務的正常表現，仍是有其餘的異常流量進入。

　　從圖中右側部分能夠看到，每條曲線表明了每一天的流量統計，紅色曲線相對於其餘幾天的流量曲線在凌晨 3:00 和早上 8:00 的時候有明顯的流量毛刺，這時候咱們就須要確認是什麼因素形成流量數據的突變。

　　經過對於流量毛刺的觀察，可以讓咱們及時瞭解業務中的風險，及時作好預警與準備。

　　業務監控

　　業務監控是根據業務屬性來定義監控指標，能夠用於斷定總體業務的運轉是否正常。不一樣業務類型監控的指標確定有所不一樣，好比電商場景、物流場景、遊戲場景是徹底不一樣的監控方向。

　　咱們拿一個電商交易業務系統來舉例，看看有哪些監控指標？你們能夠參考着思考本身目前負責的業務指標。舉例來講針對一個電商交易系統咱們能夠監控的業務指標有：

　　用戶下單監控：秒/分/時 用戶下單統計 ；

　　用戶支付監控：秒/分/時 用戶支付統計；

　　用戶退款狀況：秒/分/時 用戶退款統計；

　　商品庫存狀態：庫存消耗/剩餘統計；

　　業務 GMV 監控：業務總體銷售額統計；

　　商家在線狀態：監控商家在線狀態；

　　促銷運營監控：監控促銷金額與數量。

　　在業務監控中，還須要重點關注業務轉化漏斗概念。流量漏斗能夠看出業務轉化率以及用戶的訪問深度。它是業務健康程度的監控，也是部分需求效果的衡量標準。

　　

　　機器監控

　　機器監控須要關注的內容，應該是後臺研發比較熟悉的部分。 主要監控方向包含下面幾個部分：

　　

　　固然在 linux 系統中，也有各類經常使用指令，來進行該類數據的收集：top、free、ping、iostat、netstat。

　　對於 Java 系統來講，須要進行 JVM 層面的監控內容，好比說：gc 的狀況，線程建立銷燬狀況，full gc 狀況，內存不一樣模塊使用狀況等。 JVM 一樣也提供了指令集，方便咱們進行信息的查找：jstat、jps、stack、jmap、jhat 等。

　　日誌記錄

　　在日誌的打印過程當中，咱們須要注意日誌的打印規範，日誌打印內容應該包含對於問題排查有益的信息，而且日誌格式清晰，可解析性高。日誌通常是打印到服務器磁盤上面，可是因爲單機磁盤能力有限，而且對於大型分佈式系統來講須要總體收集不一樣服務器模塊的日誌，進行統一分析，提升問題排查效率。這時候就須要一個集中式的日誌中心。

　　日誌中心的核心能力通常包含：獲取日誌、存儲日誌、展現日誌、分析日誌、報警服務。

　　相對比較簡單的實現方式能夠採用ELK快速搭建本身的日誌中心。

　　

　　咱們利用 kafka 將日誌信息，進行異步廣播，而後進行日誌的解析，存儲到 ES 檢索系統中，利用 kibana 來進行日誌的檢索、查看等。進一步提高日誌的有效管理。

　　冗餘

　　冗餘的對立面是單點。冗餘能夠有效的減小單點問題形成的影響。你們能夠思考一下，若是一個系統服務只部署到一臺機器，機器服務掛掉以後，意味着服務不可用，依賴於它的服務也會出現異常，最壞的狀況可能會形成雪崩。

　　爲了簡化冗餘的思考，咱們將整個應用後臺架構簡化爲四層架構，以下圖所示：

　　

　　最上層是用戶訪問，而後到反向代理，Nginx 爲流量入口； 而後到站點應用，好比說我們的 Tomcat 或者 Jetty 應用服務器； 最後是數據層 db；爲了性能優化增長了 Cache 服務。

　　你們思考一下，若是這幾層服務，所有的都是單點，單點就是咱們只有一個機器去部署這些服務。Nginx 只有一臺機器，Server 應用也只有一臺機器。若是機器宕機會形成什麼樣的後果？會直接致使整個系統服務不可用，這個就是單點的風險。

　　徹底依賴一個單點 沒有任何冗餘備份，致使服務的穩定性很是脆弱。

　　怎麼去作冗餘呢？

　　對於 Nginx 層與 Server 層，咱們能夠從下面幾個方向考慮冗餘：

　　多機部署：同一個機房內，部署多個服務節點，其中一臺掛掉，還有同機房的冗餘備份；

　　跨機房部署：不一樣機房內，部署多個服務幾點，其中一個機房斷電或者其餘異常狀況，還有其餘機房來備份提供支持；

　　異地多活：若是全部機房都在同一個城市，就會形成地域單點，好比說城市光纖異常。這時候異地多活部署就會減小這部分影響。

　　

　　對於數據層面好比 MySQL、Redis 都有自身提供的冗餘方案。 MySQL 自身提供了主從部署，主從同步的機制，系統服務能夠進行讀主寫從操做。

　　

　　Redis 也相似，提供了集羣冗餘方案：主從配置，哨兵機制，集羣模式。

　　

　　Redis 集羣模式可以實現數據分區冗餘備份，主從同步，多主容災，故障自動轉移能力。

　　冗餘的思路，在業務實現方向也能夠落地考慮，好比說重要數據的多介質存儲；重要組件的多版本選擇等等。

　　限流

　　大型微服務架構中的任何服務節點，無論我們怎麼優化，怎麼拓展，都會有能力上限。若是達到能力上線，系統服務奔潰的可能性增長，這種狀況也很容易形成整個微服務應用的雪崩效應。

　　做爲一個面向用戶的網站，有時候咱們會面對流量激增的情形，若是這時候達到了咱們某個或者多個服務的能力上限，咱們應該怎麼保證系統的穩定性?

　　限流在這種情形下就起到了做用。

　　限流的目的

　　就是當服務器的壓力劇增的狀況下，爲了保證服務不被拖垮，對一些流量採起拒絕或者降級的策略，以此來保證核心服務的正常運轉。這是一種有損的技術手段。

　　將部分流量進行限制速率，控制輸入和輸出，將超過限制速率部分的流量，進行拒絕服務、或者排隊等措施。以此來達到系統的自我保護目的。

　　限流策略：

　　限流策略有三種經常使用方式：

　　1. 總量計數限流：併發量或者訪問量超過設定的閾值，將拒絕提供服務；

　　2. 漏桶限流算法：一個固定容量漏斗，任意速率流入或者生成併發或者訪問，但會以一個固定的速率執行這些併發或者訪問。若是超過固定容量的部分將被拒絕；

　　3. 令牌桶限流算法：一個固定容量的令牌通，令牌按照固定速率放到桶中，請求到來時候先去令牌通獲取令牌，若是獲取到則能夠進入業務邏輯部分，獲取不到則不會執行。

　　三者的區別：

　　

　　限流的維度

　　以下圖所示，限流思考從三個維度去思考：

　　

　　限流的實現

　　1. 基於 AtomicLong 來實現單機(接口)總量計數法限流；

　　2. 基於 Semaphore 信號量來實現單機(接口)總量計數法限流；

　　3. 利用 Guava limiter 來實現令牌通的算法；

　　4. 對於分佈式限流，咱們能夠考慮，利用 Redis 的 Incr 來進行實現。

　　降級

　　降級的目的

　　1. 削弱非核心服務資源佔用；

　　2. 保證業務核心服務穩定性。

　　舉例來講：

　　一個交易平臺，有用戶下單，支付等功能，同時也有用戶評論，商品推薦，廣告推薦等模塊。在促銷活動期間，用戶大批量的進入，那麼這時候因爲功能模塊很是多，流量或者機器資源消耗很是大。形成系統總體負載太高。那麼極可能出現一個可怕的狀況，用戶沒辦法進行正常交易。

　　面對這種狀況，咱們應該怎麼作？這時候降級就體現了它的實用價值。

　　降級策略

　　降級策略有不少方面須要思考與落地，在這裏總結一下常常用到降級策略。

　　頁面降級：非核心頁面模塊，佔用緊張資源，關停該頁面，減小訪問；

　　服務降級：將功能分類，分爲核心服務與非核心服務，將非核心服務進行關停；

　　依賴降級：將依賴服務梳理分類，保證核心依賴的穩定，將非核心進行降級關停；

　　讀寫降級：將直接讀寫數據庫切換爲讀寫緩存； 對於緩存依舊能夠進行備份冗餘；

　　延遲降級：頁面的異步加載策略； 數據寫入異步消息隊列等。

　　降級實現

　　降級就須要一個分佈式開關，經過開關來肯定降級策略的啓動與否。 分佈式開關的實現方式，咱們也簡述一下：

　　基於 Redis 實現；

　　基於 ZK 來實現；

　　基於內部數據庫來實現。

　　每一個具體的實現方式你們若是感興趣能夠查閱一下資料，基本上都是功能實現相對簡單。

　　合理降級瞭解了降級方法以後， 咱們還須要清楚不是全部服務都能降級，也不是等到故障發生了之後，纔去選擇或者肯定哪些服務能夠降級。故障的降級策略必定是要提早去規劃與思考。

　　系統或者服務須要分爲核心系統和非核心繫統(核心服務和非核心服務)來區分。核心服務是咱們力保不能有任何問題的主流程服務 P0； 非核心服務，又能夠根據重要性進行再次分層。能夠劃分爲 P一、P二、P3 服務。

　　P0 服務網爲主服務，是力保穩定性的對象，他們掛了整個業務也就崩潰；

　　P1 服務爲與緊密主服務相關，但能夠後續異步補償來操做的服務，好比說，結算流水，訂單統計；

　　P2 服務與主服務有點相關，但關閉了對主服務任何業務邏輯沒有影響，好比說，訂單評價，商品推薦等；

　　P3 服務於主服務沒有相關，關閉以後對主服務沒有任何影響 好比說，廣告推薦，用戶喜愛，評論瀏覽等。

　　在梳理服務等級的時候，須要注意 2-8 原則 也就是 20% 的系統爲核心系統，80% 的系統爲非核心服務。

　　回滾

　　根據經驗，線上的大部分 BUG 都是因爲新需求或者新的工程改動形成的。

　　那麼當系統出現 BUG 或者不穩定的時候，考慮到尋找或者排查問題耗時會比較久，咱們通常都會選擇先回滾而後再去尋找問題具體緣由。這種方式在必定程度上保證了系統的穩定性狀態。

　　回滾定義：快速恢復到變化以前的狀態，讓程序或者服務恢復到改動以前的穩定狀態。回滾目的：及時止損，減小線上問題排查付出的代價回滾影響：新改動的需求會延遲生效

　　那麼咱們回滾的方向又有哪些呢？

　　回滾方向：

　　1. 代碼版本，也就是新舊代碼的轉換；

　　2. 系統服務，就是講新上線部署的功能給予回滾操做，讓服務恢復到新上線前的狀態；

　　3. 數據內容，將修改的數據內容從新修改成歷史數據版本。

　　怎麼才能科學的回滾？

　　若是想把回滾的工做作好，須要處理好下面的主要內容：

　　發佈信息規範：每次發佈包，都有惟一的版本號；命名必定要規範。包含主要內容。 舉例：工程名稱 - 模塊名稱 - 代碼版本 - 環境類型 - 日期版本 .jar(war)

　　代碼管理科學：代碼分支管理科學、 代碼 review 機制、工程結構統一化。

　　代碼 review 時機：

　　大版本(需求)代碼必須 review；

　　線上 case 修復，代碼必須 review；

　　測試前代碼 review (保證測試質量)；

　　週期固定時間，造成團隊習慣。

　　數據管理規範：避免線上庫直接操做、任何變動必須有回滾腳本、線下驗證 。

　　注意事項:

　　儘可能避免線上數據庫手動操做；

　　若手動，須要執行詳細規範；

　　不斷設計減小手動操做頻次。

　　

　　工程上線規範：上線窗口避免流量高峯，灰度驗證避免全量上線，及時驗證迴歸測試，上線通告。

　　重試

　　重試目的

　　配合超時機制，正確的獲取結果，同時保護系統資源服務；

　　利用屢次訪問策略，減小外部抖動對系統結果形成的影響；

　　藉助冪等概念，保證信息提交成功，達到分佈式一致性。

　　重試的場景能夠有 異常重試，超時重試。

　　異常重試：咱們訪問某個依賴接口的時候，若是出現接口返回異常的狀況，咱們能夠進行訪問重試，從而獲取正確結果。

　　超時重試：接口在規定的超時時間內沒有獲得相應的結果數據，進行重試操做。

　　全局思考重試策略

　　如何進行合理的超時重試策略設定，須要結合業務特色來進行詳細的規劃與測試。若是設定很差，極可能形成線上問題。

　　超時時間過長，可能致使服務阻塞； 超時時間過短，可能致使服務調用成功率下降。若是成功率下降，可能就會致使重試的機率加大。 重試必然會致使新的請求發生，增長一次訪問時間，可能在用戶體驗上存在影響。

　　若是不斷的重試，極可能致使不斷的新建訪問線程，重複請求，致使三方接口的壓力。

　　因此超時時間 重試策略 都須要根絕咱們業務特色進行驗證與設計，避免上面介紹問題的出現。

　　峯值應對策略

　　當咱們業務系統須要進行運營促銷活動的時候，或者面臨特殊日期將要給網站帶來高於平時流量的時候，咱們須要作好應對流量峯值的準備。咱們須要系統的思考如何在系統峯值時刻保證咱們大型微服務系統的穩定性。

　　咱們將峯值應對按照時間維度進行劃分：事前，事中，過後。

　　事前

　　前期準備

　　肯定模塊：肯定本次峯值影響的工程或者服務，梳理必定要完整；

　　團隊組建：根據影響模塊，肯定本次維穩參與同窗(注意跨團隊)，確認分工；

　　合做約定：週期性的溝通，好比周會、約會、事前會議、過後總結會議。

　　數據預估

　　容量預估方向：

　　

　　數據預估的時候不只僅要考慮峯值的應對時候的容量冗餘，同時也要考慮數據長期增量的準備。

　　系統壓測

　　系統壓測的維度由小到達來講：

　　

　　單接口壓測：接口維度的壓測，人工根據接口模型進行壓測數據；咱們可使用 Apach ab、Http load 來進行。

　　單機初級壓測：針對機器維度來進行總體壓測，能夠人工構造數據也能夠線上訪問流量的複製來構造壓測數據。咱們可使用 Jemeter、LoadRunner、tcp dump 等相關工具來進行。

　　單機負載均衡壓測：也是針對單機維度來進行壓測，與初級壓測不一樣的是，根據負責均衡，將線上流量進行實時轉發，將流量比例向壓測機器傾斜，從而達到壓測的目的。

　　全鏈路壓測：全業務後臺服務總體壓測，複製線上真實流量，進行壓測數據的改造，而後高併發的訪問業務系統，提早相對真實的模擬峯值到來的情形。

　　全鏈路壓測是最困難，涉及面最廣的一種壓測方式。同時也是最能發現系統瓶頸的一種方式，全鏈路壓測的挑戰有：

　　困難1：鏈路梳理複雜度；

　　困難2：多模塊，多服務，多團隊協同；

　　困難3：尋找短板，避免系統雪崩風險；

　　困難4：壓測數據準備，髒數據處理；

　　困難5：壓測統籌安排，數據採樣對比。

　　全鏈路壓測的流程如圖所示：

　　

　　容災演練

　　目的

　　主動觸發異常，熟悉異常處理流程；

　　驗證故障處理規範，不斷完善規範；

　　驗證服務異常狀態，驗證報警機制。

　　步驟：

　　目前內容，評估影響，方案確認；

　　制定故障 SOP 手冊，詳細到每一步執行；

　　根據 SOP 進行問題解決執行操做；

　　記錄故障數據與現象，監控報警確認；

　　故障分類：能夠快速解決，須要外部支持。

　　

　　容災演練的 SOP 建設：

　　

　　服務巡檢

　　在峯值到達以前的一段時間裏，咱們須要對系統服務總體巡檢，確保的咱們的各項指標都能正常工做，及時發現可能存在的風向。

　　定事：

　　1. 對業務、流量、系統、機器、日誌 進行數據指標的 check ；

　　2. 確保主要數據無遺漏，不重複，沒錯誤。

　　定人： 專人專事，責任明確，分工合理，推動平常巡檢工做 。

　　定時：

　　1. 根據業務特色週期性的進行服務巡檢，好比天天一次，每週一次；

　　2. 根據業務特色，合理的安排巡檢的時間，好比說中午、下午。

　　定方案： 根據巡檢出現的異常數據或者不合理數據，進行解決方案的制定 方案必須可執行同時有完成時間點。

　　事中

　　峯值應對值班

　　在面對峯值期間，咱們須要保證團隊資源的穩定，須要安排核心人員進行值班操做。值班過程當中須要作一下工做：

　　服務觀察：業務數據，服務監控，日誌報警，趨勢檢測； **熟悉 SOP **：容災操做 SOP ，值班 SOP ，同步 SOP；組織形式：站會，日報，總結。

　　數據觀察同步

　　爲了讓團隊其餘人或者合做團隊瞭解當前的系統運行狀況，咱們須要在固定的時間裏同步相關數據，及時檢查數據走向與趨勢。

　　天天固定時間進行數據同步（儘可能選擇峯值時間段）；

　　數據同步對象包含：業務、PM、QA、RD 多個團隊；

　　統計指標註意跨團隊的理解程度（可理解的形式來描述）；

　　對比屬性，好比說目前峯值是上次活動峯值的多少倍。

　　線上緊急狀況處理

　　處理準則：

　　

　　這裏特別重要的一點準則就是，快速止損是第一要務，問題排查以及解決是止損以後的動做。

　　這時候在快速恢復線上服務的時候，就能考察咱們前期的容災演練的效果了。

　　

　　上面圖形展現的操做規範都應該在容災 SOP 建設中覆蓋到。

　　過後

　　1. 全部報警異常的梳理與解決，全部不規範性的討論與優化；

　　2. 根據真實的場景進行 SOP 的優化，這個 SOP 可能包含我們的值班 SOP 以及容災演練 SOP 的建設；

　　3. 覆盤討論，須要根據業務數據、流量數據、系統服務狀況統一來進行復盤整理。覆盤的邊界，不只僅是應用後臺，還應該也包含前端研發、SRE、運營產品、中間件平臺等。

　　覆盤討論的內容通常包含：

　　應用後臺: 峯值期間業務數據、服務性能數據、總體穩定性數據；

　　前端研發：APP crash 率、性能表現狀況、DAU、各頁面轉化率；

　　SRE 運維：機房總體狀況、機器負載狀況、網絡寬帶狀況、資源利用率等；

　　運營產品：業務指標完成度、同比(環比)狀況、將來規劃；

　　中間件平臺：中間件峯值穩定性狀況、容量狀況、服務能力狀況。

　　性能優化策略

　　性能優化重要性：

　　用戶角度：網站體驗重要衡量標準；

　　系統角度：穩定性的基本要求保障；

　　研發角度：自身技術能力的競爭力。

　　在這裏因爲篇幅有限，咱們不針對每一塊優化的技術策略進行詳細的講解，咱們重點介紹一下技術優化的總體方向與策略，以及如何選擇方案。

　　

　　咱們在考慮網站性能優化方案選擇的時候，從收益與投入兩個方向綜合考慮。

　　應用技術棧對於後臺研發同窗來講是相對比較熟悉的技術內容，因此投入會相對較少，收益卻會很大。由於大部分性能優化的問題，還都在於代碼與技術方案層面。

　　數據庫方面也是須要重點投入的方向，可以避免業務數據獲取以及存儲方面的瓶頸。

　　其餘的三個方向網絡優化，容器組件，底層環境都不是業務後臺研發同窗常常學習的方向。因此這幾塊優化方向能夠考慮和公司的運維同窗進行共同思考與建設。

　　固然性能優化是一個長期重複執行的動做，須要進行不斷的總結，梳理出來符合本身業務的性能優化策略。

　　總結

　　本文介紹了大型微服務架構後臺應用系統穩定性技術策略的介紹。每一個技術點都須要咱們持續的思考與落地，全面總體的思考穩定性相關的建設動做。與此同時，還進行峯值應對過程當中穩定性的保障工做如何開展，但願對你們有所幫助。