SpringCloud應用在Kubernetes上的最佳實踐是怎樣的

這篇文章將為大家詳細講解有關SpringCloud應用在Kubernetes上的最佳實踐是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

前言

在應用發布上線的時候我們最擔心的莫過于因為代碼的 bug 引發業務的問題，雖然我們可以通過灰度的方式分批發布減小影響范圍，但是如果能夠在發布的過程中從實時監控中快速的發現問題進行回滾，那么就能縮短業務受影響的時間。因此我們可以看到灰度、監控、回滾是整個發布過程中不可或缺的三大利器，有了這三大利器后，我們能夠做到隨時發布，從而加快業務的迭代和上線速度。而監控作為基礎設施的一個重要環節，是保障生產環境服務穩定不可或缺的一部分，目前 EDAS 提供了非常豐富的監控能力，下面我們從不同的場景來詳細介紹一下這些監控能力。

體系化監控能力搭建

監控體系，最怕的就是有覆蓋不到的地方，一個覆蓋全面的監控應該是從基礎設施到上層應用均有對應的手段去覆蓋：

• 首先，如果故障產生時，最先感知到的其實是業務的受損，如交易量下跌、登陸的 UV 下跌等等；

• 而如果繼續往下鉆，如果業務集群很大的時候，我們最先需要定位到某一個服務或者某一臺機器，這個過程如果沒有相應的工具相佐猶如大海撈針，所以一個分布式鏈路級別的應用監控會是建設 Spring Cloud 應用的很好的配搭；

• 等到我們找到了相應的服務要開始進行定位分析的時候，根據問題類型（是錯是慢？）接下來需要開始分析 JVM、內存、CPU 等維度的指標；  

• 最后我們可能會發現這個問題是由于業務代碼引起，也有可能由于基礎設施引起，而在 K8s 中，Prometheus 目前是屬于容器領域基礎監控最厲害的軍刀。

如上圖所示，目前 EDAS 結合阿里云上的某些云產品，完全能夠滿足日常的運維的需要并幫忙業務開發的同學快速的定位線上問題。

EDAS 常規監控能力

1. 系統監控

應用實例的基礎監控信息：

上圖功能提供了以應用實例的維度來查看每個實例的監控信息，提供的 JVM / CPU / Load / 內存等的監控信息也是我們經常需要關注的，當發現內存占用高，并且有頻繁的 FullGCC 的情況時，我們可以通過創建內存快照進行分析來快速定位問題。SQL 分析的能力也能快速幫助我們定位到慢查詢用來排查問題。

2. 應用服務監控

應用服務接口監控信息：

這里提供了以接口維度的監控信息，可以詳細的看到接口在最近一段時間的請求信息，這里重點介紹一下接口快照功能，通過接口快照我們可以看到該接口的請求耗時，以及請求的 TraceId，根據這個 TraceId 我們可以詳細的看到本次請求的調用鏈以及調用的方法棧。

調用鏈路的追蹤在分布式系統下是一個必不可少的工具，尤其是在排查上下游依賴中究竟是哪個系統拖慢了整個請求非常有用，在調用的方法棧中可以直觀的追蹤到調用出錯的地方。

3. 應用業務監控

在 EDAS 中我們支持應用自定義業務監控，這需要我們開啟高級監控的能力。從業務的視角來衡量應用的性能和穩定性，可以通過自定義來采集業務信息，來實時展現業務指標，幫助業務進一步完善監控信息。詳細的監控配置可以參考 ARMS 業務監控。

4. Prometheus 監控

監控產品的歷史由來已久，但是隨著云原生技術的持續火熱，Prometheus 作為新生代的開源監控系統，慢慢成為了云原生體系的事實標準。而在 EDAS 中的高級監控產品 ARMS 已經全面對接開源 Prometheus 生態，支持類型豐富的組件監控，提供多種開箱即用的預置監控大盤，且提供全面托管的 Prometheus 服務，更多的詳細內容可以參考 ARMS Prometheus。

通過以上這些監控能力，可以大大縮短線上問題從發現到定位再到解決的時間，提高開發和運維人員排查和解決問題的效率。

EDAS 應用發布場景中的監控

以阿里巴巴集團的經驗舉例子，超一半以上的大故障都是在發布過程中產生，EDAS 針對發布這一場景結合 Kubernetes 的能力做了結合，其中的精髓內容總結三個詞：先發、再看、再發。通俗的解釋就是可以利用 EDAS 中分批（灰度）發布能力，同時在發布視圖中，確保相關的指標回歸正常之后，再開始下一批發布了。

目前 EDAS 能夠提供在三個維度上的指標監控數據，用來判斷發布是否正常，列舉如下：

1. 應用業務指標

目前 EDAS 以接口的維度提供了每個接口在發布前后的總的請求數對比以及請求該比例的圖例，并且還能夠詳細的看到在發布前后該接口的錯誤數、響應時間以及單機的請求數對比，如下圖所示：

通過上圖，我們可以直觀的看到，當我們發布后應用的接口請求是否正常，以此來判斷是否會對業務產生影響。

2. 應用異常

在發布的過程中，我們也需要時刻的關注在發布中是不是有新的異常產生，我們想要有地方能夠看到異常信息，避免直接登錄到機器上去看業務日志，我們的發布監控提供了日志聚合分析的能力，可以在發布的過程提供實時的異常日志分析展示，如下圖所以：

3. 系統指標

在新的業務功能上線的時候，我們除了對業務本身的一些異常和指標進行關注外，還需要關注系統的指標，這關系到我們需要評估現有的機器是否能夠支撐我們的所有流量，是否需要進行水平擴容來更好的支持業務，我們的發布監控系統同樣集成了系統的監控的能力，為我們的發布過程來保駕護航，詳細的監控如下圖所示：

以上內容我們通過三個維度為大家展示了在整個發布的過程中 EDAS 為我們提供的完備的監控能力，通過這個能力可以讓我們的每一次發布都能做到不慌不忙，心中有數，每一次發布都能平滑讓業務進行升級。同時我們也提供了查看發布報告的功能，將發布監控信息形成了一份清晰的可視化分析報告供分享他人。

關于SpringCloud應用在Kubernetes上的最佳實踐是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。