《阿里雲運維架構秘籍》
主要講述的是：基於阿里雲的雲服務器如何進行調優運維。
雲端最熱門的互聯網應用，當屬電商、游戲、移動社交、金融等。
在技術層面上，無非是java、php、python等開發語言，oracle、mysql、sqlserver等關系型數據庫，以及mongodb、redis、memcache等非關系型數據庫。
架構層面，無非是集群、負載均衡、緩存、文件存儲、分布式等架構。
即使業務千奇百怪，回到架構層還是一樣的，只不過針對不同業務，在架構中的考量和偏移會有所不同。
雲端電商架構應用
業務特點：優惠活動、商品圖片（靜態資源幾乎占了業務請求流量的80%）
技術特點：高並發
技術解決：彈性伸縮（解決促銷活動的時候，訪問人數、並發數量增大）、CND緩存（解決商品圖片、視頻比較多，變化不大，但經常訪問）
雲端移動社交
業務特點：海量（用戶、圖片、視頻）
技術特點：大量信息存儲
技術解決：非關系型數據庫存儲、OSS對象存儲分布式文件系統、CND緩存（全是為了解決圖片、視頻、文件等資源的存儲和訪問）
雲端金融架構應用
業務特點：安全
獨立公有雲，單獨部署金融雲（主要解決的是安全，其他方面根據實際業務調整）
阿里雲主要常用有5個雲產品
ECS(Elastc Compute Service)彈性雲服務器
RDS(Relational Database Service)關系型數據庫
SLB(Server Load Balance)負載均衡
OSS(Object Storage Service)對象存儲服務
VPC(Virtual Private Cloud)專有網絡
使用雲服務五個技術優勢
1 安裝配置方面
2 調優方面（比如mysql調優）
3 備份方面
4 高可用（比如ECS和OSS都是三副本的數據冗余）
5 安全性方面（不用考慮攻擊）
| 指標 |
計算周期 |
含義 |
| PV |
天 |
Page View的簡寫，頁面瀏覽量或點擊量。一般指web類業務一天內頁面的訪問次數。每打開或刷新一個頁面，就算一個PV。 |
| UV |
天 |
UV是Unique Visitor簡寫，獨立訪客數。Web類業務一天內訪問站點的用戶數（以Cookie為依據）。如果更換了IP但不清除cookies，再訪問相同網站，UV是不變的。如果不保存cookies訪問/清除了cookies，計數會加1。00：00-24：00內相同客戶端多次訪問一個網站只計為1個訪客。 |
| IP |
天 |
Web類業務一天內有多少獨立的ip瀏覽了頁面，即統計不同的IP瀏覽用戶數量。同一IP不管訪問了幾個頁面，獨立IP數均為1；不同的IP瀏覽頁面，計數會加1。IP是基於用戶廣域網IP地址來區分不同的訪問者的，所以，多個用戶（多個局域網IP）在同一個路由器（同一個廣域網IP）內上網，可能被記錄為一個獨立IP訪問者。 |
| 用戶數 |
|
一般指業務系統的注冊用戶數 |
| 活躍用戶數 |
按天 |
指注冊用戶數中，一天中實際使用了業務系統的用戶數量，跟UV差不多 |
| 在線用戶數 |
按天 |
指一天的活躍用戶數中，用戶在一定的時間段內的在線數量 |
| 並發用戶數 |
|
指在線用戶數基礎上，某一時刻同時向服務器發送請求的用戶數 |
一個網吧里有5台電腦使用同一個IP，此時五個人同時打開同一個網站，並且每個人都刷新了2次。這種情況，網站的數據為：10個PV，5個UV，1個IP。
一天的80%業務請求主要發生在40%的時間內，這成為我們計算PV值對應請求的依據。
PV請求計算模型如下：
每秒處理請求數量=（80%*總PV量）/（24小時*60分*60秒*40%）
用戶數、活躍用戶數、在線用戶數計算模型：
用戶數*業務因子（10%-30%）=活躍用戶數
活躍用戶數*業務因子（10%-30%）=在線用戶數
在線用戶數*業務因子（10%-30%）=並發數 約=每秒請求數
1台8核16G的雲服務器基本一天能處理web應用上百萬的請求，所以可以對應100萬PV。因此可以參加如下表：
PV量和服務器配置、RDS配置性能對應表
| PV（萬） |
服務器配置 |
RDS（數據庫服務器）配置 |
| 1萬 |
1核/1G/1台 |
無 |
| 10萬 |
2核/4G/1台 |
1核/1G |
| 50萬 |
4核/8G/1台 |
2核4G |
| 100萬 |
8核/16G/1台 |
4核/8G |
| 500萬 |
8核/16G/10台 |
8核/16G |
| 1000萬 |
8核/16G/20台 |
16核/64G |
互聯網企業的服務器CPU利用率平均在10——20%，磁盤空間的利用率在20%——30%。在雲端，80%企業存在資源核存儲閑置浪費的現象。
阿里雲最常見的配置是1核1G、1核2G、2核4G、4核8G、4核16G、8核16G、8核32G、16核64G、16核128G等。不管多少核多少G，CPU核數與內存大小的比是1：1、1：2、1：4、1：8。他們的應用場景及適合部署的軟件服務匯總如下：
CPU與內存資源配比1：1
適用於個人網站、官網等小型網站部署，一般低配機器中，如1核1G，2核2G。基於雲端實踐，很少看到基於4核4G、8核8G、16核16G的配比。
CPU與內存資源配比1：2
1：2的處理器與內存配比可獲得最優計算資源性價比，不管是線下IDC的物理服務器，還是雲端ECS服務器的配置，1：2均為黃金比例。比如1核2G、2核4G、4核8G、8核16G、16核32G，這些都是實踐中的黃金比例配置。1：2的配適用於絕大部分業務場景部署，尤其是需要消耗高資源的計算。如端游、頁游、手游。在電商類高並發、秒殺活動類應用中使用得也特別廣泛。使用最多的是8核16G，8核16G這個偏向與中大型web服務器/應用類部署。Tomcat適合中低配2核4G或者4核8G。因為Tomcat是單進程多線程的模式，是個輕量級且並發求請求數最多只能跑到1000左右。所以單台高配置的Tomcat的服務器並不能跑滿服務器性能，會造成很大資源浪費。如果想跑滿，常規做法是一台服務器上部署多個Tomcat。
CPU與內存資源配比1：4
比如2核8G、4核16G、8核32G。這類配比的配置偏向與內存，特別適合數據庫類的應用。1：4尤其適合型數據庫。8核32G是保障數據庫具有良好性能的經典配置。但數據庫數據是需要持久化，也就是寫在硬盤上面的。需要SSD雲盤提供高存儲低讀寫延時。所以數據庫對服務器首先要求的是I/O,其次才是內存。高內存會有效提升數據庫的緩存性能，很大程度上提升數據庫的性能。數據庫其實對CPU要求並不高，所以偏向內存的配置，適合數據庫部署。
CPU與內存資源配比1：8
比如2核16G、4核32G、8核64G。這類是高內存資源占比。尤其適合內存型數據庫應用，比如redis、memcache的部署。在實踐中，如果用8核16G部署一台Redis，會造成性能過剩。redis是單進程單線程模式，對多核利用得不太好，所以適合向1：4或者1：8的高內存資源配比考慮。如果想要redis把多核性能利用好，可以考慮一台機器上多部署幾個redis。
磁盤空間選擇參考如下
如果沒有文件存儲，只有linux系統日常基礎日志存儲，系統磁盤就足夠了。
如果是部署代碼的應用（如Java編寫后生成的jar包或者war包放到tomcat上面），一般tomcat要輸出日志，程序本身也有日志輸出。所以系統盤默認的40G容量空間不夠，一般選用100G-300G磁盤空間是標配。如果還需要存儲用戶上傳的文件，可根據具體情況在評估。數據庫類的應用，磁盤空間一般需求較大，都是500G以上。要存儲數據庫的Binlog、數據文件、備份等。數據庫需要對數據讀寫有要求，即對磁盤I/O要求，一般采用高效雲盤或者SSD雲盤。
通過實踐發現，100G、300G、500G存儲空間對企業服務器配置是標配，但80%企業服務器磁盤利用率僅在20%-30%。
帶寬選擇8/2原則
很多人選擇固定帶寬。比如1Mbps、2Mbps、5Mbps、10Mbps、20Mbps，事實上，大多數情況沒有必要。80%應該選擇按量帶寬。20%選擇固定帶寬。如果每天按量下載的量合計費用超過帶寬平均每天費用，則使用固定帶寬。
DevOps發展的四個階段
1 人工階段
2 腳本階段
3 平台化階段
4 智能化階段
雲端共享文件存儲的方法
1 Rsync文件共享部署
不是實時同步的，需要手動執行或者定時任務
Rsync只適合兩台服務器之間同步
2 Rsync+Inotify文件共享
Inotify是監控工具，監控目錄或文件的變化，然后調用Rsync進行數據同步。
Inotify實現工具工具有3款：Inotify本身、Sersycn、Lsyncd。實踐中建議選擇Sersycn。
3 NFC文件共享實踐
Rsync、Rsync+Inotify、Sersycn更多應用於定時/實時單向同步，很少雙向。如果是墮胎機器的數據共享。一般建議NFS（Network File System，網絡文件系統）。開源的解決方案中，NFC是標准的文件共享解決方案。
4 NAS文件共享（阿里雲）
5 OSS文件共享（分布式存儲）
監控方案一：Shell/Python
應用場景：通過Shell或者Python腳本完成監控。這個監控解決方案一般用於不懂運維的研發人員，他們一般沒聽說過監控系統，所以就用自己擅長的開發語言，來完成日常的監控需求。
功能特點：主要通過腳本編碼做些系統基礎監控指標（CPU/內存/網卡/磁盤）報警
缺點：缺乏中間件、應用層監控。缺乏監控數據存儲、數據查看等監控集中管理平台。
監控方案二：Nagios
物理機體系下，用的比較多的監控軟件是Nagios
應用場景：IT基礎架構監控，主要應用在主機系統、交換機路由等網絡設備的監控上。
功能特點：偏向主機系統、交換機路由器等網絡設備監控。
缺點：圖形化差、很多功能通過插件化來實現，對技術能力要求很高、偏向主機層監控，在Nginx、Tomcat等應用中間件方面監控少
監控方案三：Nagios+Cacti
Cacti可以單獨部部署使用以監控網絡流量、監控數據圖形界面展現效果比較好。
應用場景：Nagios+Cacti是物理機階段最佳監控解決方案。
功能特點：Cacti良好的數據展示，彌補了Nagios監控軟件的不足。
缺點：對技術能力要求很高、偏向主機層監控，在Nginx、Tomcat等應用中間件方面監控少
監控方案四：Zabbix
應用場景：企業級IT監控。
功能特點：主機、網絡、中間件、日志等性能監控成熟完善。詳細報表圖標繪制、支持自動發現網絡設備和服務、支持分布式集中管理、完善的API，支持企業定制化開發。
缺點：Zabbix用的是mysql為主的關系型數據庫，服務端數據庫有局限性。
需要在監控的目標主機中安裝Agent，存在安全隱患。
對容器監控支持的不太好。
監控方案五：阿里雲監控、駐雲監控
監控方案六：Prometheus+Alertmanager+Grafana
Prometheus主要監控容器
應用場景：監控系統、時序數據庫。只要有標准的HTTP協議的Metric數據，就能監控到Prometheus。
功能特點：
基於時序數據庫（NOsql數據庫）的多維數據庫模型，同樣適用於物聯網海里數據存儲及監控。
靈活的數據模型，特別適用於對於動態靈活性高的容器監控。
不需要Agent，只要監控目標能安卓標准的HTTP協議提供數據，即可完成監控。