上雲實踐操作（漫步雲端）之上雲動力

上雲之前

在選擇使用阿里雲之前，整個技術部門採用的是自購伺服器+機房託管的方式來部署所需要的程式。並且考慮到不同區域的業務以及災備的問題，一共在南北兩個城市的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當中進行備份儲存。
在配置沙河環境的時候同樣採用了以上的思路，只是具體機器配置上比正式環境的略低幾個檔即可。

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