最近看到了幾個事情，一個是某保險系統，為了快速上線，全量上雲，結果生產正式執行後每月賬單高達幾十萬。相關業務總扛不住這個支出，又勞師動眾，讓下面的專案經理、開發、運維、架構師花了3個月把業務全量從公有云遷移下來。相關人員被折磨的半死不活，而且大大拖慢了系統的迭代速度。
另一個是某個電商的案例，上雲後剛開始費用賬單也是很高，每月接近 20 萬，經過「降本增效」優化後，費用大幅度降低，每月費用降到了 4 萬左右，服務質量反而還有提升。
這 2 個故事告訴我們，雲時代的滾滾浪潮撲面而來，我們也應該根據公有云的特性（如：彈性、靈活、多種計費方式等），在不降低服務質量的情況下，最大限度地優化成本。
以下是一些最佳實踐。
公有云除了提供 IaaS（計算、儲存、網路等）外，也會提供 PaaS（微服務、中介軟體、資料庫、巨量資料、開發套件等）和 SaaS 服務。
在公有云提供的服務（如 MySQL 資料庫）可以滿足需求的前提下，建議首選公有云上的 MySQL 資料庫服務，而非自建。
理由簡單說明如下：
| 對比項 | 成本 | 效能 | 伸縮性 | 維護方 | 可靠性 | 監控 | 易用性 |
|---|---|---|---|---|---|---|---|
| 自建 | 高 | 低 | 弱 | 我方 | 低 | 無 | 難 |
| 雲上服務 | 中 | 高 | 高 | 雲提供商 | 高 | 有 | 易用 |
比如雲資料庫：
使用雲資料庫，這些步驟雲資料庫都幫你做了。其他 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 的概念一樣 |
| 線上使用者數 | 天 | 一天的活躍使用者數中，使用者同時在一定的時間段內線上的數量 |
| 並行使用者數 | -- | 指線上使用者數基礎上，某一時刻同時指向伺服器傳送請求的使用者數 |
具體的效能監控指標如何和業務指標進行轉換就先略過了。
這些公有云產品是基本上都會用到的，歷經檢驗，且比較實用的產品。
雲伺服器一般用於承載應用，推薦以更多臺數的中低配為主，避免資源的浪費。
建議一般設定不要超過：16C32G，主流設定為：
容器服務有諸多優勢，推薦無狀態應用使用容器服務。
在雲上，不要按照業務峰值購買全量的資源，而是推薦：買滿足日常需求的資源
在雲上，如果需要搞活動，再通過「容器」或「API + 映象 +快照」批次購買、彈性擴容。
比如在某手機的秒殺活動中，會瞬間開啟 200 臺機器且持續 2H 來應對，IT 資源花費 600 元人民幣：
這在傳統架構中，根本不可想象。比如傳統架構，搞「雙十一」，都要提前一個月準備 IT 資源。
另外上面的場景也可以利用 「彈性伸縮服務」或「容器 HPA」來動態調整。
既然雲的優勢是「分散式」，資源多，那麼 Ansible 這種批次的 DevOps 工具是必不可少的，可以大幅度提升效率。
具體應用，可以通過 Ansible，客製化對應的 Playbook，自動化批次安裝和運維。
先開通一臺雲伺服器，並對這臺雲伺服器做運維規範方面的系統調優、安全加固等措施。然後把這臺雲伺服器做成一個基礎映象，批次開通 其他同樣環境的伺服器，可以大大提升部署效率。
上雲的最後一步，是要將域名的 IP 解析到 負載均衡 公網 IP 上。但需要提前在共有云上對域名進行備案，如果到最後域名解析到公有云上後才發現域名被拉黑，業務存取被拒絕，這將會變得非常麻煩。因此需要提前通過公有云進行域名備案，或者已經在其他供應商進行備案，那麼需要將域名備案轉接入公有云。
近期國際形勢愈演愈烈，中美摩擦進一步升級，形勢緊張。要做最壞的打算：美國可能會斷掉您的 .COM 域名的解析。
另外國家最近有指引，不要使用外國管控的根域名作為基礎設施的一級域名。
.cn 是國家根域，.com.cn、net.cn、org.cn 等這些都是可以的。
出於安全（受攻擊面太大）和成本（公網IP都是錢）的考慮。
而且沒必要，如果是業務存取，入向通過負載均衡進來，出向通過 NAT 閘道器出去。
如果是運維，推薦通過VPN + 跳板機（中小企業）或專線 + 堡壘機（大企業）來實現運維管理。
原因：可靠性更高，更安全。
對於中小規模企業，如果您的系統經常搞活動，網路負載差距很大，那麼推薦：「大頻寬按量付費」而不是「固定頻寬固定計費」，比如：「1Gbps峰值頻寬按量計費」對比「100Mbps固定頻寬」：
以某客戶上雲前後為例，在 IDC 機房，200Mbps 的獨享電信頻寬，一年的成本大概是 1Mbps/100元/月 x 12 個月 x 200 = 24萬。而在雲端，採用 1Gbps 峰值的 BGP 多線 SLB 頻寬，在頻寬質量上面提升了幾個量級。另外，頻寬費用採用按量付費，大大降低了維護成本。
推薦使用公有云提供的負載均衡，可以作為反向代理，防止使用者端直連雲伺服器帶來的安全和穩定性風險。
加入 負載均衡 可以保障架構靈活擴充套件性：加入 負載均衡 後，架構變得更加靈活。典型場景是將所有域名先繫結到 負載均衡 上，然後轉到後端 Nginx，通過 Nginx 做虛擬主機等七層更靈活的控制。
採用 4層 負載均衡 保障效能：在實踐中，面對高並行效能的場景時，發現 7 層的負載均衡，相比 4 層的負載均衡，在效能上面有很大差距。7 層負載均衡只能達到萬級別並行，而 4 層的負載均衡能達到幾十萬級，甚至上百萬級的並行量。所以在電商等網站應用中，對於 負載均衡，優先選擇 TCP 層。四層 LB 能扛得住 10w-50w 的並行。
使用者的 DNS TTL 我們是無法控制的，如果調整了某域名的DNS記錄，可能某些使用者已生效，某些使用者沒有生效。
針對這種情況，需要在原有IP上做 302 重定向跳轉，將依舊存取原IP 的客戶引流到新IP上，這將大大提高使用者的存取體驗。
大規模應用。當後端有一兩百臺雲伺服器，而一臺負載均衡 效能有限時，可以採用多個 負載均衡，前邊通過DNS 負載均衡。典型如：淘寶、阿里雲官網。
DNS有個最大的問題，就是 本地 DNS 快取。
智慧解析 -- 跨地域分散式架構中必不可少。根據 ClientIP，選擇返回對應地域、運營商的IP。
如：DNS記錄：
如果有 BGP 線路，那就更簡單了：
如：使用者請求存取域名，DNS 自動判斷存取者IP 是「上海聯通」還是「北京聯通」，然後智慧返回設定的對應的「上海聯通」和「北京聯通」的伺服器 IP 地址完成域名解析。
海外：可以選擇「海外、海外大洲、海外（國家/地區）」來細分解析。
如:
雲上建議儘量不要使用類 NAS 的共用檔案儲存服務，而應該使用物件儲存服務來替代。
在傳統環境，NAS 的典型使用場景如下：
負載均衡：使用 LB + 多臺 雲伺服器（如：Web 伺服器）部署的業務。多臺 雲伺服器 需要存取同一個儲存空間，以便多臺 雲伺服器 共用資料。
程式碼共用：多臺 雲伺服器 應用，部署的程式碼一致。將程式碼放在同一個儲存空間，提供給多臺 雲伺服器 同時存取。程式碼集中管理。
紀錄檔共用：多臺 雲伺服器 應用，需要將紀錄檔寫入到同一個儲存空間，以便做集中的紀錄檔資料處理和分析
企業辦公檔案共用場景：企業有公共的檔案需要共用給多組業務使用，需要集中的共用儲存來存放資料。
容器服務的場景：部署的容器服務需要共用存取某個檔案資料來源，特別是在資源編排的容器服務。對應的容器可能會在不同的伺服器中進行服務漂移，所以檔案共用存取尤為重要。
備份的場景：使用者希望將資料備份到雲上，可以通過掛載檔案系統來儲存資料備份。
在某個客戶場景中，靜態資源放到 物件儲存 中，前端對靜態資源的請求通過 Nginx 反向代理轉發給 物件儲存。但這種做法，在雲端架構上是不推薦的，因為它會帶來幾個問題：
所以，新增 Nginx 做反向代理是多此一舉。雲端不推薦這麼做。該客戶這麼用，主要原因是業務程式碼側，靜態資源的請求，都是通過目錄劃分。如果將靜態資源單獨放在二級域名，跨域等問題程式碼側沒很好地解決，從而產生這種不倫不類的架構。最終在業務程式碼側進行了優化調整，對 物件儲存 靜態資源的使用規範如下：