上云之前

在選擇使用阿里云之前，整個技術部門采用的是自購服務器+機房托管的方式來部署所需要的程序。并且考慮到不同區域的業務以及災備的問題，一共在南北兩個城市的IDC機房都部署有服務器來支撐日常業務的運行。在IDC模式的運維工作上面，首先帶來的問題是日常的巡檢和維護，當某一個機房的設備如果出現了硬件損壞的情況，運維通常可以聯系機房進行臨時的設備替換，并重新申請購買新的設備，并到機房去安裝。 這樣的話，首先就是當損害一旦產生，某些服務或者程序所提供的算力會在某一段時間內降低，而且對于設備損壞重新購買所申請的費用，在預算控制上面也是一個比較難以估計的問題。再者，當新設備回來后，還是得需要運維人員到機房現場去替換設備，這樣隨之而來的也就產生了一些不必要的差旅費用，這些臨時費用的產生，對于整個部門的預算管理都是一種挑戰。
假設上架的服務器都沒有問題，穩定的渡過了3年的時間，或者因為業務做得特別好，需要對機房進行擴容，這個對于在傳統機房部署上又是一個比較頭疼的問題。從選擇什么樣的機器，機房是否有足夠的機柜，機柜間的網絡狀況，給供應商簽署合同，發貨，機器到貨上架，整個流程會非常的長，如何選擇最經濟合適的方案來采購機器以匹配現有的業務，這個應該是對決策者比較考驗的問題。 如果我們把整個IDC機房的運行時間和設備采購的成本以放到5年來看，我們會發現下面的一個情況。

從上圖我們可以看得出來，根據逐年的業務提升，總是會發現IDC的服務無法滿足業務的要求，從而再次對IDC機房進行擴容，擴容后的某一段時間內是可以滿足業務的需要，但是再某些時候IDC機房所能提供的能力又大于業務的需求，造成了資源的浪費，圖形中的兩條線并不是平滑匹配的。
為了解決以上的問題，我們再2018年的時候開始考慮使用云計算的方案來替代我們現有的IDC的機房結構。

準備上云

上云之需求
說到為什么要上云，其本質上并不是說要去追尋什么現在主流的上云趨勢。而是要實實在在解決我們在上一個章節中遇到的問題，總結來說，上云需要解決：

• 預算控制問題
• 日常運維的快速響應問題
• 算力擴容問題
• 業務與機器平滑匹配的問題

帶著以上的幾個問題，我們也開始著手去調研過一些云廠商的產品與服務。最后從提供的產品，價格的方面考慮還是選擇了阿里云。最初在選擇的時候我們調研到了阿里云的以下幾個產品能夠滿足我們的需求：

• ECS （提供與日常服務器一致的功能）
• EMR （提供hadoop集群功能）
• RDS （提供Mysql和Redis的功能）
  但如果只是僅僅考慮到以上的幾個產品就去上云感覺無非就是把云服務當成了普通的服務器來使用，并沒有什么太大的優勢。但是結合到阿里云提供的一些其他產品，整個系統的結構會發生大的變化，所以我們最后選擇使用的產品有：
• VPC
• NAT 網關
• RDS
• SLS
• OSS
• MaxCompute
• CDN
• PAI
• EMR
• SLB
  最終組成的業務架構圖如下：

首先通過EIP按照業務的需要向外暴露服務，整個服務都裝在VPC當中，通過NAT網關的DNAT和SNAT進行指向，進入的流量由SLB的規則分發到指定的ECS當中進行業務的處理，ECS當中的PHP，Python, Go 等程序可以通過讀寫RDS當中的數據進行處理，處理后的日志文件交由SLS統一收集并推送到Maxcompute 當中進行一些業務計算。計算后的最終結果再次寫入到RDS當中供前端程序展示。計算中間結果存入OSS當中進行備份保存。
在配置沙河環境的時候同樣采用了以上的思路，只是具體機器配置上比正式環境的略低幾個檔即可。

以上的所涉及到的各個產品與服務將在后面的章節具體介紹。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的上云实践操作（漫步云端）之上云动力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。