前言
最近看到了幾個事情，一個是某保險系統，為了快速上線，全量上雲，結果生產正式執行後每月賬單高達幾十萬。相關業務總扛不住這個支出，又勞師動眾，讓下面的專案經理、開發、運維、架構師花了3個月把業務全量從公有云遷移下來。相關人員被折磨的半死不活，而且大大拖慢了系統的迭代速度。
另一個是某個電商的案例，上雲後剛開始費用賬單也是很高，每月接近 20 萬，經過「降本增效」最佳化後，費用大幅度降低，每月費用降到了 4 萬左右，服務質量反而還有提升。
這 2 個故事告訴我們，雲時代的滾滾浪潮撲面而來，我們也應該根據公有云的特性（如：彈性、靈活、多種計費方式等），在不降低服務質量的情況下，最大限度地最佳化成本。
以下是一些最佳實踐。
最佳實踐
整體
首選公有云服務而非自建
公有云除了提供 IaaS（計算、儲存、網路等）外，也會提供 PaaS（微服務、中介軟體、資料庫、大資料、開發套件等）和 SaaS 服務。
在公有云提供的服務（如 MySQL 資料庫）可以滿足需求的前提下，建議首選公有云上的 MySQL 資料庫服務，而非自建。
理由簡單說明如下：
| 對比項 | 成本 | 效能 | 伸縮性 | 維護方 | 可靠性 | 監控 | 易用性 |
|---|---|---|---|---|---|---|---|
| 自建 | 高 | 低 | 弱 | 我方 | 低 | 無 | 難 |
| 雲上服務 | 中 | 高 | 高 | 雲提供商 | 高 | 有 | 易用 |
- 成本：
- 自建，需要人員維護和最佳化的成本，需要自行考慮高可靠（可能需要購買多臺伺服器）和高效能（可能需要購買高效能儲存），使得成本偏高。
- 雲上服務，透過規模效應、資源池化、引數調優等實現成本相對不高。
- 效能：
- 自建，不一定知道所有的引數最佳化項，也不一定同價位能買到專用的高效能硬體。
- 雲上服務，效能明碼標價，按需選擇適合自己的效能配置。
- 伸縮性
- 自建，伸縮較麻煩，要不手動，要不透過 歷經檢驗的 DevOps 指令碼，伸縮性弱。
- 雲上服務，很多PaaS類服務可以一鍵升配。
- 維護方
- 自建，我方自行兜底
- 雲上服務，雲提供商提供 SLA 兜底。
- 可靠性
- 自建，不一定能實現該元件的叢集模式或高可用模式的全部最佳實踐。
- 雲上服務，會做好網路高可用（甚至是跨AZ的高可用）、儲存多副本、計算跨物理伺服器/機架/AZ甚至region、服務監控及自愈、備份等多種措施保障可靠性。
- 監控：
- 自建，要不沒監控，要不監控需要從頭（採集端）到尾（告警通知）實現一遍
- 雲上服務，監控具備，且和公有云監控無縫對接。
- 易用性：
- 自建：一般沒有 Web 介面，需要透過線下或流程平臺或 CLI 來申請和操作
- 雲上服務：有易用的 web 介面，可以在 web 介面上完成大部分功能。
比如雲資料庫：
- 運維架構：
- 儲存的資料規模及後期擴充套件，採用的高可用架構；
- 異常切換
- 硬體及基礎環境部署
- 選擇什麼配置的伺服器，伺服器型號及對應磁碟陣列；
- 作業系統環境及核心設定；
- 資料庫安裝及最佳化
- 資料庫版本安裝部署及配置；
- 資料庫配置引數調優；
- SQL 語句最佳化；
- 慢查詢，對 SQL 語句及索引做最佳化
- 資料庫日常備份及恢復。
- 備份；
- 熱備還是冷備？物理備份還是邏輯備份？
- 備份策略、週期、頻率
使用雲資料庫，這些步驟雲資料庫都幫你做了。其他 PaaS（中介軟體、大資料、微服務、DevOps等）也類似。
做好安全防護
公有云最大的風險就是資料洩露。所以一定要做好安全防護。這個安全防護是多方面的。詳細見 安全 部分。
雲的優勢是「分散式」
如果對比單臺伺服器，可能雲主機的效能差一些。「分散式」是雲端計算的最大優勢。在實踐中，不要只追求單臺機器的效能，而是要透過分散式的設計思想來保障業務的高效能。最佳實踐推薦，伺服器標配 4C8G，低配也可以採用 2C4G 的配置。透過分散式充分壓榨了單臺伺服器的資源，從而最大限度地保障了最終的低成本。
所以，在雲上，一般情況下應用伺服器的選擇條件是：更多的低配的雲服務勝於更少的高配的雲伺服器。
所以，在雲上，對於資料庫來說，如果資料量非常大，也推薦使用「分散式資料庫」，而非在雲上自建 Oracle。
雲的優勢是「彈性」
所以，在雲上，不要按照業務峰值購買全量的資源，而是推薦：
- 買滿足日常需求的資源
- 高峰時，再提前購買一些彈性的資源，彈性擴容。
另外，不僅僅是伺服器資源，對於網路也適用，如果您的系統經常搞活動，網路負載差距很大，那麼推薦：「大頻寬按量付費」而不是「固定頻寬固定計費」。
動靜分離
靜態：放 CDN + 物件儲存上，或者放 NGINX 伺服器上也好，不要直接用應用伺服器（如tomcat或nodejs）來處理靜態資源。（浪費，術業有專攻）
動態：典型架構是 LB - NGINX - 應用伺服器 - redis - 資料庫。
上雲前做好業務量的評估
上雲前做好業務量的評估，為雲上的資源規劃做好資源預算。
可以透過：
- 壓測
- 已有監控資料分析
等方式評估業務量。
常用的業務量指標如下：
| 指標 | 計算週期 | 指標含義 |
|---|---|---|
| PV | 天 | Page View。指 B/S 架構中的 Web 類業務一天內頁面的訪問次數，每開啟或重新整理一次頁面，算一個 PV。 |
| UV | 天 | UV 是 Unique Visitor 的簡寫。指 B/S 架構中 Web 類業務一天內訪問站點的使用者數（以 cookie 為依據） |
| IP | 天 | B/S 架構中 Web 類業務一天內有多少個獨立的 IP 瀏覽了頁面，即統計不同的 IP 瀏覽使用者數量。 |
| 使用者數 | -- | 業務系統的註冊使用者數 |
| 活躍使用者數 | 天 | 註冊使用者數中，一天中實際使用了業務系統的使用者數量，跟 UV 的概念一樣 |
| 線上使用者數 | 天 | 一天的活躍使用者數中，使用者同時在一定的時間段內線上的數量 |
| 併發使用者數 | -- | 指線上使用者數基礎上，某一時刻同時指向伺服器傳送請求的使用者數 |
具體的效能監控指標如何和業務指標進行轉換就先略過了。
推薦幾個公有云雲產品
這些公有云產品是基本上都會用到的，歷經檢驗，且比較實用的產品。
- 雲伺服器
- 關係型資料庫
- 負載均衡
- 物件儲存
- VPC（Virtual Private Cloud）：專有網路
- CDN
- Redis
- 安全類的基本產品（如：安全組、ACL、漏掃、WAF、DDoS防護等）
計算
雲伺服器配置以中低配為主
雲伺服器一般用於承載應用，推薦以更多臺數的中低配為主，避免資源的浪費。
建議一般配置不要超過：16C32G，主流配置為：
- 4C8G 甚至更低
- 8C16G
推薦使用容器服務
容器服務有諸多優勢，推薦無狀態應用使用容器服務。
- 資源粒度更細，細粒度到: 0.1C, 記憶體 MB。
- 自動擴縮容更方便
- 擴容後 pod 自動加入負載均衡
- ...
按需購買
在雲上，不要按照業務峰值購買全量的資源，而是推薦：買滿足日常需求的資源
彈性擴容
在雲上，如果需要搞活動，再透過「容器」或「API + 映象 +快照」批次購買、彈性擴容。
比如在某手機的秒殺活動中，會瞬間開啟 200 臺機器且持續 2H 來應對，IT 資源花費 600 元人民幣：
- 搭建好環境，製作好映象；
- 活動前透過 API 秒開 200 臺伺服器來應對活動；
- 活動結束後，透過 API 瞬間釋放資源
這在傳統架構中，根本不可想象。比如傳統架構，搞「雙十一」，都要提前一個月準備 IT 資源。
另外上面的場景也可以利用 「彈性伸縮服務」或「容器 HPA」來動態調整。
使用 Ansible 等 DevOps 工具
既然雲的優勢是「分散式」，資源多，那麼 Ansible 這種批次的 DevOps 工具是必不可少的，可以大幅度提升效率。
具體應用，可以透過 Ansible，定製對應的 Playbook，自動化批次安裝和運維。
透過映象提升雲端部署效率
先開通一臺雲伺服器，並對這臺雲伺服器做運維規範方面的系統調優、安全加固等措施。然後把這臺雲伺服器做成一個基礎映象，批次開通 其他同樣環境的伺服器，可以大大提升部署效率。
網路
域名備案要先行
上雲的最後一步，是要將域名的 IP 解析到 負載均衡 公網 IP 上。但需要提前在共有云上對域名進行備案，如果到最後域名解析到公有云上後才發現域名被拉黑，業務訪問被拒絕，這將會變得非常麻煩。因此需要提前透過公有云進行域名備案，或者已經在其他供應商進行備案，那麼需要將域名備案轉接入公有云。
推薦必備 .CN 域名
近期國際形勢愈演愈烈，中美摩擦進一步升級，形勢緊張。要做最壞的打算：美國可能會斷掉您的 .COM 域名的解析。
另外國家最近有指引，不要使用外國管控的根域名作為基礎設施的一級域名。
.cn 是國家根域，.com.cn、net.cn、org.cn 等這些都是可以的。
嚴禁每臺伺服器都能訪問公網
出於安全（受攻擊面太大）和成本（公網IP都是錢）的考慮。
而且沒必要，如果是業務訪問，入向透過負載均衡進來，出向透過 NAT 閘道器出去。
如果是運維，推薦透過VPN + 跳板機（中小企業）或專線 + 堡壘機（大企業）來實現運維管理。
如果需要出公網，建議使用 NAT 閘道器而非在某臺機器繫結公網IP
原因：可靠性更高，更安全。
利用低成本高負載的按量頻寬
對於中小規模企業，如果您的系統經常搞活動，網路負載差距很大，那麼推薦：「大頻寬按量付費」而不是「固定頻寬固定計費」，比如：「1Gbps峰值頻寬按量計費」對比「100Mbps固定頻寬」：
- 費用可能更低
- 頻寬更大，活動期間可能會超過 100Mbps，那這時候固定頻寬就會影響使用者體驗，而 1Gbps 峰值頻寬是完全可以支撐的住的。
以某客戶上雲前後為例，在 IDC 機房，200Mbps 的獨享電信頻寬，一年的成本大概是 1Mbps/100元/月 x 12 個月 x 200 = 24萬。而在雲端，採用 1Gbps 峰值的 BGP 多線 SLB 頻寬，在頻寬質量上面提升了幾個量級。另外，頻寬費用採用按量付費，大大降低了維護成本。
推薦使用雲上軟負載均衡
推薦使用公有云提供的負載均衡，可以作為反向代理，防止客戶端直連雲伺服器帶來的安全和穩定性風險。
加入 負載均衡 可以保障架構靈活擴充套件性：加入 負載均衡 後，架構變得更加靈活。典型場景是將所有域名先繫結到 負載均衡 上，然後轉到後端 Nginx，透過 Nginx 做虛擬主機等七層更靈活的控制。
高併發情況下，推薦使用 4 層負載均衡
採用 4層 負載均衡 保障效能：在實踐中，面對高併發效能的場景時，發現 7 層的負載均衡，相比 4 層的負載均衡，在效能上面有很大差距。7 層負載均衡只能達到萬級別併發，而 4 層的負載均衡能達到幾十萬級，甚至上百萬級的併發量。所以在電商等網站應用中，對於 負載均衡，優先選擇 TCP 層。四層 LB 能扛得住 10w-50w 的併發。
DNS 記錄調整要注意
使用者的 DNS TTL 我們是無法控制的，如果調整了某域名的DNS記錄，可能某些使用者已生效，某些使用者沒有生效。
針對這種情況，需要在原有IP上做 302 重定向跳轉，將依舊訪問原IP 的客戶引流到新IP上，這將大大提高使用者的訪問體驗。
大型企業 - DNS 負載均衡實踐
大規模應用。當後端有一兩百臺雲伺服器，而一臺負載均衡 效能有限時，可以採用多個 負載均衡，前邊透過DNS 負載均衡。典型如：淘寶、阿里雲官網。
DNS有個最大的問題，就是 本地 DNS 快取。
- 可以讓 DNS TTL生效快一點；
- DNS配置的是負載均衡 IP，而不是雲伺服器的IP。
- 如果還是有部分使用者出問題，指導使用者清理 DNS 快取，或強制繫結本機 host 指向域名解析。
智慧解析 -- 跨地域分散式架構中必不可少。根據 ClientIP，選擇返回對應地域、運營商的IP。
運營商線路解析
如：DNS記錄：
- 預設線路：電信伺服器IP
- 網通：網通IP
- 移動：移動IP
- 教育網：教育網IP
- 海外：海外IP
如果有 BGP 線路，那就更簡單了：
- 預設線路：負載均衡的公網IP
地域線路解析
如：使用者請求訪問域名，DNS 自動判斷訪問者IP 是「上海聯通」還是「北京聯通」，然後智慧返回設定的對應的「上海聯通」和「北京聯通」的伺服器 IP 地址完成域名解析。
海外：可以選擇「海外、海外大洲、海外（國家/地區）」來細分解析。
如:
- 海外 - 亞洲地區 - 新加坡線路：指向新加坡伺服器的 IP
- 海外 - 北美洲 - 美國線路：指向美國伺服器的 IP
- 海外 - 歐洲 - 德國線路：指向德國伺服器的 IP
- 預設線路：指向新加坡伺服器的 IP
CDN 就是智慧解析的最佳實踐
儲存
雲上善用「物件儲存服務」
雲上建議儘量不要使用類 NAS 的共享檔案儲存服務，而應該使用物件儲存服務來替代。
在傳統環境，NAS 的典型使用場景如下：
-
負載均衡：使用 LB + 多臺 雲伺服器（如：Web 伺服器）部署的業務。多臺 雲伺服器 需要訪問同一個儲存空間，以便多臺 雲伺服器 共享資料。
- 替代方案：直接使用普通雲資料盤，透過 DevOps 等工具實現批次部署及資料一致。
-
程式碼共享：多臺 雲伺服器 應用，部署的程式碼一致。將程式碼放在同一個儲存空間，提供給多臺 雲伺服器 同時訪問。程式碼集中管理。
- 替代方案：程式碼放在程式碼倉庫中集中管理。
-
日誌共享：多臺 雲伺服器 應用，需要將日誌寫入到同一個儲存空間，以便做集中的日誌資料處理和分析
- 替代方案：日誌定期儲存到物件儲存中，可以根據策略、冷熱資料的實際情況選擇分別儲存到「標準物件儲存」、「低頻物件儲存」和「歸檔儲存」中進一步壓縮成本；或直接使用雲上的「日誌服務」。
-
企業辦公檔案共享場景：企業有公共的檔案需要共享給多組業務使用，需要集中的共享儲存來存放資料。
- 替代方案：使用物件儲存來替代。
-
容器服務的場景：部署的容器服務需要共享訪問某個檔案資料來源，特別是在資源編排的容器服務。對應的容器可能會在不同的伺服器中進行服務漂移，所以檔案共享訪問尤為重要。
- 替代方案：這種場景確實需要用到雲上檔案系統服務。
-
備份的場景：使用者希望將資料備份到雲上，可以透過掛載檔案系統來儲存資料備份。
- 替代方案：備份到物件儲存的「歸檔儲存」中，進一步降低成本。
錯誤用法：NGINX 做公網轉發到物件儲存
在某個客戶場景中，靜態資源放到 物件儲存 中，前端對靜態資源的請求透過 Nginx 反向代理轉發給 物件儲存。但這種做法，在雲端架構上是不推薦的，因為它會帶來幾個問題：
- 訪問靜態資源的流量走 雲伺服器 的頻寬流量，特別是中大型的 Web 應用中。流量走 雲伺服器 的頻寬，很可能出現效能瓶頸。
- Nginx 是透過公網將請求反向代理轉發給 物件儲存 的，所以在網路傳輸上會影響速度效能。
- 透過 Nginx 反向代理，不僅增加運維成本，還要維護 Nginx 配置檔案等。
所以，新增 Nginx 做反向代理是多此一舉。雲端不推薦這麼做。該客戶這麼用，主要原因是業務程式碼側，靜態資源的請求，都是透過目錄劃分。如果將靜態資源單獨放在二級域名，跨域等問題程式碼側沒很好地解決，從而產生這種不倫不類的架構。最終在業務程式碼側進行了最佳化調整，對 物件儲存 靜態資源的使用規範如下：
- 業務側使用單獨的二級域名來管理靜態資源（如：<pic-cdn.ewhisper.cn>)，靜態資源統一放在 物件儲存 中；
- 靜態資源的二級域名直接將 CNAME 繫結在 物件儲存 的 URL 地址上（訪問量很少的情況下），這樣就直接跳過「使用 Nginx 做反向代理」這個冗餘的步驟了
- 如果想要進一步提升 物件儲存 中存放的靜態資源的訪問速度，可以無縫接入 CDN。 CDN 的回源請求，會直接透過內網回源請求 物件儲存 中的源資料。相比 Nginx 反向代理走公網請求 物件儲存，速度和效率會提升得更高，價格特定情況下也會更划算。
資料庫
資料庫推薦雲服務 且必須有高可用保障
資料庫不推薦自建，推薦直接使用雲提供商的相關資料庫服務，且推薦必備高可用保障，如叢集模式或多副本，以及資料備份。
資料庫優先採用雲提供商的相關資料庫服務 ，低成本高效率：如果在雲上購買雲伺服器自建 MySQL 主從部署並維護的模式，使得後期的維護管理成本很大。即我們要監控及維護主從狀態，並且在出現問題時需要及時處理，保障業務對資料庫讀寫的連續性。在採用雲提供商的相關資料庫服務 後，這些問題都可以自動化解決。即對資料庫主從的監控、備份、後期維護、故障切換等，都是全自動。
對於可靠性要求特別高的DB，可以選擇跨AZ高可用的叢集方案
對於可靠性要求特別高的DB，可以選擇跨AZ高可用的叢集方案。比如：Redis、MongoDB、MySQL都有類似的跨AZ高可用的叢集方案提供。
按需選擇合適的資料庫
資料庫多種多樣，根據自己的實際需求進行選擇，以下列出部分：
- 關係型資料庫
- MySQL
- SQL Server
- Postgresql
- MariaDB
- 分散式資料庫（如OceanBase或TDSQL等）
- 非關係型：記憶體資料庫
- Redis
- Memcache
- 文件資料庫：MongoDB
- 列資料庫
- HBase等
- 時序資料庫
- InfluxDB
- TSDB
CDN
典型使用場景：CDN + 物件儲存
- 資料分發：適用於搭建下載行為較多的APP、音影片平臺、網站等，使用者可結合 CDN + 物件儲存 的能力，將靜態內容（包括音影片、圖片等檔案）託管在物件儲存中，並將熱點檔案提前下發至CDN邊緣節點，降低下載訪問延遲
- 網站託管：適用於官方網站等偏靜態的站點，將網站的靜態資源快速託管儲存在物件儲存中，同時透過 CDN + 物件儲存 分發，透過CDN 配置的域名作為靜態網站訪客的訪問地址入口，快速建好一個網站
安全
必須設定強密碼
典型如：MongoDB、Redis、ES，預設無密碼或弱密碼，已經發生過多輪、大規模的資料洩露事件，所以針對這些服務，一定要設定強密碼。
至於雲伺服器、雲賬戶、關係型資料庫等，更是要保障強密碼或者更強力的安全措施。
客戶端訪問必須 HTTPS
這個就不多說了。
- 給域名申請證書，放在 Nginx 或 LB上 管理。
- 業務側，保留 HTTP 80 埠，做80 -> 443 的重定向。LB 上 80 和 443 埠監聽都要開啟。
一定要配置安全組和ACL
最基本的安全防護
不要 root 直連
不要 root 直連，用普通使用者，登陸過去按需 sudo 切換到 root
建議暴露公網的 SSH 埠不要用 22
建議不要用預設的 22 埠，防止被掃描。另外還有建議用證書認證等方式，就不一一贅述了。
免費安全產品別忘領
如每開通一臺雲伺服器，都會贈送一些免費額度的「DDoS防護和主機安全防護」。有基本的防護，會比裸奔安全很多。
三人行, 必有我師; 知識共享, 天下為公. 本文由東風微鳴技術部落格 EWhisper.cn 編寫.