雲上運維的架構設計與混合監控

鄧偉，別名柚子，雲計算架構師，5年運維經驗，AWS技術社群成員，有獨特思想的運維人。

本文整理自鄧偉在「監控與性能優化」社群中的分享。

「得雲者可以小勝，用雲者可以大勝，維雲者無往不勝！」

nn

大家好，我是鄧偉，引入了一位運維前輩的話作為今天分享的開場白。相信大家對公有雲已經再熟悉不過了，今天我們就來聊聊在AWS上的架構設計與混合監控。類似AWS的雲廠商的出現，讓應用架構的搭建更為快速，因為雲廠商已經做好了基礎服務的架構，而企業的IT部門要學會如何最大化利用雲服務，但這並不「簡單」。

基於雲的架構設計

以前，我們經常用Nginx做負載均衡，用智能DNS來輪詢伺服器；現在，利用雲服務就能快速的部署和響應。AWS目前提供上千種服務，需要根據自身的業務場景進行合理的架構設計，因此雲服務架構也並不是一件「簡單」的事情，這裡分享的是一套比較常用的架構設計，先來看一下架圖：

圖中從用戶層接入，這裡分了兩個訪問節點，Route 53（域名解析服務）是用戶訪問進我們應用的入口，而CloudFront也就是CDN，用來加速靜態文件或者下載文件提供給用戶。用戶通過Route 53 進入到負載均衡器（ELB），ELB會自動分配用戶即流量到後端伺服器（EC2），在多個EC2或同一台EC2不同埠之間進行容錯，保證用戶的訪問都是可用。

EC2作為虛擬伺服器（虛擬機），具備了自有伸縮與水平擴展的能力，而運維需要配置Auto Scanling組來讓他進行自動擴展，當用戶流量進來，先通過ELB進行流量分發，當某天流量爆發的時候，通過提前預設的規則EC2進行擴展，流量一旦下降，就自動回收，以節省成本。

利用AWS提供的VPC服務配置不同子網來把業務資源進行合理化的網路隔離，以提高網路安全性。在這裡S3起到了一個非常好的中繼服務，S3本質是一個存儲桶，你可以把他當成FTP，把日誌丟到S3、把靜態文件放在S3提供給上面提到的CDN去進行分發、也可以把打包好的代碼放到S3進行自動化部署。

這樣一來，企業就能減少了對伺服器本身的接觸與操作，再加上利用IAM服務對雲服務（資源）的許可權控制，以規範運維人員對線上資源的操作行為，降低人為風險。

這套架構設計並不複雜，從容的實現了高可用+安全性，但在架構設計中仍需考慮怎麼契合企業自身業務的特點，進行合理化調配與邏輯處理，既能滿足業務需求，又能降低成本。

雲應用的混合監控

當我們做好應用架構設計，就需要去監控這套架構和各種業務應用的運行了，監控各個節點上的服務是否按我們的配置正常運轉。AWS提供的CloudWatch可以針對資源的利用率監控，利用這一點可以構建自動化處理事件，用CloudWatch來監控服務資源，用腳本來監控伺服器內部服務的運行情況，當然就算所有的內部資源和服務都是正常，也不一定表示業務就正常。

因此在業務監控上選擇了雲智慧的監控寶，利用監控寶遍布全國各地和海外各主要國家和地區的數百個分散式監測點，實時檢測各地用戶訪問業務的真實體驗情況，第一時間發現因外部原因造成的業務不可用，從而確保業務交付的質量。

混合監控下的告警處理

大家會發現我們使用了CloudWatch+自定義腳本+監控寶，那麼問題來了，一旦業務出現異常，那必然是一場郵箱+簡訊的無敵轟炸，導致重要的報警淹沒在海量報警之中，無法及時跟進處理。

在這樣的混合監控下，要減輕運維人員的負擔，就需要一個控制中心把來自各方的告警與業務進行整合，在系統中先對告警優先順序進行排序，將不影響業務的輕告警放置在工作時間發出，重要告警整合不同告警來源的信息統一進行發送，第一時間引起運維人員重視，並判斷告警風險。

當告警準確的派發給運維人員，自然也就指定了處理責任人，在海量告警面前運維人員需要進行溝通、分配處理，可能導致處理不及時，責任不明確，甚至遺漏的情況。

在混合監控下，整合監控信息、分級處理，針對項目派發給運維人員並要求回執結果，即把合適的告警在合適的時間發給合適的人，處理效率將大大提升。利用服務架構來展現出來所有資源及業務的健康狀態，在平台上可以直觀了解業務是否健康，而不是被動的等著告警。

今天分享了一套雲運維的架構思路，希望可以幫助大家更好的運用雲服務，把救火的事情交給別人來解決。