"在 PaaS 層面，我們始終擁抱開源技術，並保持和社群版本相容的時效性；在企業特性上，例如服務治理、應用監控等方面，我們提供一個穩定成熟的產品，來降低企業構建網際網路化應用的門檻，例如企業級應用服務 EDAS 3.0就是這樣一個典型的產品。"

——阿里巴巴合夥人、阿里雲智慧基礎產品事業部高階研究員 蔣江偉

EDAS 3.0作為應用託管和微服務管理的PaaS平臺，支援 Spring Cloud、Apache Dubbo、Service Mesh 等服務執行環境，提供應用開發、部署、監控、運維等全棧式解決方案，同時平臺通過 AIOps (智慧運維)為託管應用提供效能和穩定性保障。

通常，企業在雲上構建網際網路應用，都會遇到以下這些問題：

• 如何來確定一個分散式系統的容量？

• 如何實現更加智慧的彈性的伸縮，用最低的成本，實現最高的容量？

• 當系統出現問題時，如何進行快速定位和診斷？

帶著這三個問題，我們來看看 EDAS 3.0的雲原生架構是如何滿足真實場景下的流控難題和單點故障引起的交易成功率下降的問題的，詳情如視訊所示：

演示系統

視訊中演示應用是模擬了一個電商購物交易系統主要包括：系統閘道器、交易中心、商品中心和購物車四個模組，各個模組之間選擇了 Dubbo 和 Spring Cloud 作為微服務框架進行系統間互動。整個應用選擇了阿里雲 ACK 容器服務叢集作為部署底座，同時將該叢集一鍵託管到EDAS 3.0平臺進行微服務治理、應用監控、以及應用部署運維操作。

整個演示流程，我們按照電商大促活動前系統壓測演練為背景，使用 PTS (Performance Testing Service效能測試)來模擬使用者請求流量， EDAS 3.0 通過限流降級、智慧彈性、故障診斷以及異常例項摘除等功能為整個壓測演練保駕護航。接下來，我們按照演示流程對每個環節中涉及到的技術進行一一解讀分析。

容量探測

對於大促系統壓測演練，首先我們需要知道壓測目標值(這個需要產品和運營根據歷史活動和使用者量進行評估)，視訊中的目標值為 8000TPS (Transaction Per Second, 每秒事務數)。明確目標值以後，我們需要進行壓測獲取單機水位，這裡我們利用了最佳壓力值結合介面 RT (Response Time,介面返回時間)進行單機容量評估。

如上圖所示，最佳壓力值指的是系統在最佳效能執行，連續成功率低於 98% 的點的前一個量級，同時結合我們對介面的 SLA 的 RT 上限 800ms 可以得出單機 TPS (Transaction Per Second, 每秒事務數)在 850 左右(視訊中選擇了4臺機器壓測)。可以看出單機容量評估流程需要一定人工經驗以及反覆測試才可以完成，目前 EDAS 3.0 已經在和 PTS 合作針對壓測場景進行自動化容量評估以及效能診斷。完成上述單機水位評估後，我們即可根據目標值對系統容量進行手動擴容，在 EDAS 3.0 系統中可以完成上述操作。完成擴容以後，通過 PTS 模擬需要壓測的目標值 8000TPS ，觀察擴容後的系統指標 RT 和交易成功率是否符合預期要求。

效能優化

像大多數首次上線的應用一樣，這個電商交易模擬系統作為一個全新 demo 系統，也是經歷了多輪壓測以及效能調優才達到最後視訊中展示的效果。作為一個典型的 Dubbo 微服務系統，這裡分享一下整個調優過程中兩個比較典型問題的除錯過程。整個除錯過程我們主要藉助EDAS 3.0的應用監控中心、日誌中心以及 Arthas 工具進行排查和診斷。

首先來看第一個問題，完成第一步容量探測此時 PTS 的壓力值為 3400RPS ，緊接著直接進行擴容來進行下一步目標值壓測，在完成擴容後可以看到RT監控指標反而有上升波動同時會出現一段時間請求錯誤，這個和預期不符的。我們利用 EDAS 3.0 監控的介面快照鏈路定位到下游 checkout 服務問題，同時利用例項監控定位具體是擴容前某個 pod 問題。接下來在日誌中心檢查該 pod 相應日誌發現了 Dubbo 執行緒池滿的錯誤日誌，同時發現 Dubbo 多次重試的錯誤日誌。綜合分析可以得出根因是，節點呼叫下游超時重試導致執行緒池沾滿，針對這種情況我們將超時時間、重試次數以及 Dubbo 執行緒池進行了調整，經過多輪壓測後得到合適引數。

完成上述優化以後，由於後續限流降級的需求我們程式碼引入了 AHAS 的 SDK ，同樣在容量探測完成以後直接進行手動擴容來進行下一步目標值壓測的時候，再次出現短暫的失敗率反而上升的問題。有了上一輪調優經驗，這一輪我們也是輕車熟路配合 Arthas 的使用以及 AHAS 引入時間點，定位到這次問題主要是 AHAS 的 SDK 初始化會導致 RPC 首次呼叫耗時增加，同時擴容後新節點自身需要預熱問題，大流量直接打在新節點上會導致超時失敗。針對這兩點問題，我們通過啟動主動呼叫 AHAS 的 SDK 初始化方法以及修改 Dubbo 的延時註冊和預熱配置進行解決。

作為一個交易核心鏈路新系統上線進行壓測是必不可少的環節，這也體現了雲上 PTS 的壓測系統對於使用者重要性，在壓測過程中遇到問題我們需要進行一輪輪調優，調優過程中 EDAS 3.0 的監控中心和日誌中心起到了重要作用，將整個條有過程變得有章可循同時節省了排查時間。最後，我們可以看到微服務執行緒池配置、超時配置以及重試配置等是比較常見的微服務問題，未來我們 EDAS 3.0 智慧運維(AIOps)可以將這些問題排查變得更加自動化幫助客戶節省更多時間。

限流降級

在當今日益複雜的應用環境下，應用設計應該遵循“面向失敗”的設計原則，對上下游的依賴零信任。藉助流量控制、熔斷降級模組，應用就有能力對流量採取限流控制，並對下游依賴進行降級處理。

面對視訊中超過系統預估容量的突增流量，服務限流降級功能顯得尤為重要了，我們知道一旦突發高流量將系統打垮，後續恢復將十分艱難，重啟應用的預熱，流量遷移等等給使用者帶來不好體驗。EDAS 3.0 提供的一鍵接入服務限流降級功能，只需要您在部署階段勾選接入限流降級服務，您的應用即可享受流量防護模組給您的應用全方位保護。目前該防護模組支援主流的 Java 框架，包括 HTTP 和 Dubbo ，同時可以實時監控框架的 QPS （Queries per Second，每秒查詢數）、執行緒數、響應時間、異常數等指標。

完成上述接入以後，在 EDAS 3.0 監控詳情頁的服務/介面監控的限流降級選單可以對介面進行規則配置以及實時指標監控，有了限流降級模組的保護，應用就可以從容面對線上突增流量的出現。

智慧彈性

在分散式應用管理中，彈性伸縮是很重要的一個運維能力。彈性伸縮能夠感知應用內各個例項的狀態，並根據狀態動態實現應用擴容、縮容，在保證服務質量的同時，提升應用的可用率。在彈性伸縮方面，EDAS 3.0提供了更加智慧豐富的彈性擴縮策略，包括監控指標策略和自定義彈性策略。同時，針對業務週期性我們還提供了定時彈性來支援該特定業務場景。

視訊演示流程中突發流量在限流降級模組的保護下，應用抵擋住了超過系統容量上限的流量。該應用同時配置了單機 QPS 自定義指標的彈性擴縮策略，智慧彈性模組會根據當前外部最新請求量進行智慧彈性擴容，從而將超過預估的流量一併吃掉，保證系統穩定性的同時也提升了使用者使用產品體驗。

離群摘除

在微服務架構中，當服務提供者的應用例項出現異常，而服務消費者無法感知時會影響服務的正常呼叫，並影響消費者的服務效能甚至可用性。離群例項摘除功能會檢測應用例項的可用性並進行動態調整，以保證服務成功呼叫，從而提升業務的穩定性和服務質量。目前，EDAS 3.0微服務治理中的離群摘除功能會在客戶端統計服務的指標資料，比如呼叫次數和錯誤次數，根據使用者的規則配置進行流量摘除。

智慧運維

網際網路時代，應用併發量激增，業務流程更加複雜，如何保證系統穩定性越發困難，系統可觀測性越來越重要。

EDAS 3.0系統在滿足應用執行態和釋出態可觀測性的基礎上，又進一步做到了智慧運維(AIOps)。目前，智慧運維已成為了應對IT系統與日俱增的複雜性的很好的解決方案， 它基於大資料、資料分析和演算法來提供洞察力，併為現代基礎設施和軟體所需的管理任務提供更高水平的自動化。

全球最具權威的IT研究與顧問諮詢公司 Gatner 公司最新 AIOps 報告預測到 2023 年，全球 40% 的 DevOps 團隊會使用 AIOps 工具。EDAS 3.0作為監管控一體化 PaaS 平臺，已經在 AIOps 領域深耕多年，並將其落地在應用執行態和釋出態等多個場景。

如上圖所示， Gartner 總結當下 AIOps 中涉及的三個主要流程 Observer、Engage 和Act， EDAS 3.0 的智慧運維(AIOps)也是依照上述流程進行整體診斷分析。

整體來看， EDAS 3.0 智慧運維流程主要包含以下三個部分：異常檢測、根因分析和診斷處理。其中，異常檢測階段選擇了應用黃金指標中的 RT (介面響應時間)和錯誤率作為檢測目標，利用演算法和應用歷史指標資料進行異常檢測分析。

在根因分析階段，系統會根據單機、服務以及關聯事件三個維度對異常進行解釋和分析。通過三個維度指標檢測最終會給出故障可能的原因，在複雜的微服務系統中可以很好的輔助運維人員對故障進行排查和覆盤。

在完成根因分析以後， EDAS 3.0 智慧運維繫統會根據分析結果進行相應的修復建議、運維自動化處理，同時會給出一份診斷報告對本次故障進行問題定位分析幫助開發同學進行問題排查。診斷報告包含了故障定界、根因分析結果以及相應的建議或者推薦。

演示視訊中，通過製造下游節點 fullgc 故障，從而引發上游介面 RT( 響應時間)的上升。EDAS 3.0 智慧運維繫統自動會檢測到此次 RT (響應時間)上升的異常，並會針對 RT 突增異常進行分析檢測，最終根據檢測結果進行相應的修復手段，如視訊中所見在檢測出是下游的單機 fullgc 問題後，智慧運維繫統通過 EDAS 3.0 微服務治理提供的離群摘除能力將故障機器進行隔離，隔離後故障恢復。

最後綜述， EDAS 3.0 作為分散式架構、數字化轉型上雲的首選線上業務應用託管平臺，在微服務治理、應用釋出變更以及智慧運維等多個維度為使用者應用提供智慧化、自動化的解決方案，歡迎大家使用，點選文末“閱讀原文”，瞭解更多產品相關。

掃碼加入釘群，可諮詢產品相關問題：

作者資訊：

陳晨，花名陸昆，阿里雲中間件技術開發，2017 年加入阿里巴巴，專注於分散式任務排程系統、PaaS平臺開發以及AIOps。