1. 從一臺永遠在線的虛擬電腦說起很多人第一次接觸云服務器腦子里冒出來的第一個問題就是我到底買了個啥是一臺放在別人機房里的物理機嗎還是一臺虛擬機其實這兩種說法都對也都不完全對。拿亞馬遜云科技的EC2來說它給你的是一臺可以隨時開機、隨時關機、按秒計費的虛擬電腦你可以像操作自己桌上的那臺機器一樣裝系統、配環(huán)境、跑服務、開端口唯一的區(qū)別是它不在你腳下而是在某個你根本不需要關心的數據中心里。EC2這三個字母是Elastic Compute Cloud的縮寫翻譯過來就是彈性計算云。彈性這兩個字是整個產品的靈魂也是我這些年用下來覺得最值錢的地方。傳統物理服務器你要么買一臺放機房要么租一臺按月付費配置定死了想升級就得停機換硬件想降配就得浪費錢。EC2不一樣你今天覺得2核4G夠用明天業(yè)務漲了點幾下就能升到8核16G后天流量回落了再降回去計費跟著配置走不用為閑置資源買單。這篇文章我打算把EC2從里到外拆一遍包括實例類型怎么選、計費模式怎么挑、存儲和網絡怎么配、安全組怎么設、快照和鏡像怎么用以及那些只有踩過坑才知道的細節(jié)。適合剛上手云服務的新手也適合用了一段時間但總覺得好像哪里沒配對的老用戶。我不打算照本宣科念文檔而是按一個實際項目從零到上線的順序把每個環(huán)節(jié)的決策邏輯講清楚讓你看完能直接照著做。2. 實例類型與規(guī)格別讓選型變成選坑2.1 實例家族的命名規(guī)則到底在說什么EC2的實例類型名字看起來像亂碼比如m5.large、c6g.xlarge、r5.2xlarge其實每個字母和數字都有含義。拿m5.large舉例m是實例家族family代表通用型5是代次generation數字越大越新large是規(guī)格大小size決定CPU和內存的具體數量。再比如c6g.xlargec是計算優(yōu)化型6是第六代g表示用的是ARM架構的處理器xlarge是規(guī)格。理解這套命名規(guī)則的好處是你看到一個新實例名字大概就能猜出它適合干什么。通用型m家族CPU和內存比例均衡適合Web服務器、中小型數據庫、開發(fā)環(huán)境計算優(yōu)化型c家族CPU強內存少適合批處理、視頻編碼、高性能計算內存優(yōu)化型r家族內存大CPU相對少適合內存數據庫、大數據分析、緩存服務。還有存儲優(yōu)化型i家族、加速計算型p和g家族等等各有各的專長。我個人的經驗是新手最容易犯的錯就是無腦選最便宜的或者無腦選最貴的。最便宜的那檔往往是突發(fā)性能實例T系列它的CPU積分機制后面會細說用不好會導致服務卡頓。最貴的那檔可能是GPU實例你跑個靜態(tài)網站根本用不上。選型的核心原則是先搞清楚你的應用是CPU密集、內存密集還是IO密集然后對應選家族再根據負載量選規(guī)格。2.2 突發(fā)性能實例的CPU積分機制T系列實例是很多人的入門首選因為便宜。但它有一個非常特殊的機制叫CPU積分CPU Credits。簡單說T實例有一個基準CPU性能比如t3.micro的基準是10%意思是它平時只能用到10%的CPU。當你需要更多CPU時它會消耗積分來透支性能最高可以沖到100%。積分在你CPU用得少的時候會慢慢積累用得多了就消耗。這個機制聽起來很美好但坑在于如果你的應用持續(xù)高負載積分很快耗盡CPU就會被限制在基準水平服務直接變慢。我見過有人用t3.micro跑一個持續(xù)有流量的API服務白天還好到了晚上積分用完響應時間從50毫秒飆到2秒。所以T系列只適合負載波動大、平時比較閑的場景比如個人博客、測試環(huán)境、低流量后臺。如果你的服務是7x24小時穩(wěn)定吃CPU的老老實實選m家族或c家族。判斷方法很簡單在控制臺看CloudWatch的CPU積分余額指標如果經常接近零說明你選錯了?；蛘吒纱嘤脽o限模式Unlimited Mode積分用完可以繼續(xù)透支但月底會按超出量額外收費賬單可能比你升級實例還貴。2.3 架構選擇x86還是ARM最近幾代實例里出現了帶g后綴的型號比如m6g、c6g、r6g這些是基于ARM架構的。相比同規(guī)格的x86實例ARM實例通常便宜10%到20%性能卻不相上下某些場景甚至更好。聽起來很香但有一個前提你的應用得能在ARM上跑。大部分主流語言和框架都已經支持ARM了比如Python、Node.js、Java、Go、Nginx、MySQL、Redis這些都沒問題。但如果你用的是某些商業(yè)軟件、老舊的二進制包、或者自己編譯的C擴展可能就沒有ARM版本。我一般的做法是新項目優(yōu)先考慮ARM省錢又省電遷移老項目時先在測試環(huán)境跑一遍確認所有依賴都有ARM版本再切。還有一個細節(jié)是ARM實例和x86實例的鏡像不通用。你創(chuàng)建實例時選的AMI系統鏡像必須匹配架構選錯了啟動會失敗。這個在控制臺里其實有提示但如果你用命令行或API創(chuàng)建很容易忽略。3. 計費模式按需、預留、競價到底怎么選3.1 三種主流計費模式的適用場景EC2的計費模式主要有三種按需實例On-Demand、預留實例Reserved Instances、競價實例Spot Instances。按需就是隨用隨付按秒計費最靈活也最貴。預留是你承諾用一年或三年換取大幅折扣通常能省30%到60%。競價是你在一個動態(tài)市場上出價價高者得能省70%甚至90%但隨時可能被回收。怎么選我的判斷邏輯是這樣的如果你的服務是長期穩(wěn)定運行的比如生產環(huán)境的Web服務器、數據庫用預留實例最劃算反正你本來就要一直開著。如果是臨時性的、可中斷的任務比如批量數據處理、視頻轉碼、CI/CD構建用競價實例能省一大筆。如果是開發(fā)測試、短期項目、不確定要不要長期用的用按需靈活第一。這里有個容易忽略的點預留實例不是綁定某臺具體機器的它綁定的是實例家族、區(qū)域、操作系統這些屬性。你買了一個m5.large的預留只要在這個區(qū)域創(chuàng)建m5.large的實例就自動享受折扣不用管具體是哪臺。而且預留還有可轉換和不可轉換之分可轉換的貴一點但能換成其他家族或規(guī)格適合業(yè)務可能變化的場景。3.2 競價實例的中斷處理策略競價實例最大的風險是中斷。當市場價超過你的出價或者容量緊張時系統會給你兩分鐘警告然后回收實例。兩分鐘聽起來很短但如果你的架構設計得當完全可以從容應對。我的做法是把競價實例用在無狀態(tài)、可重試的任務上。比如一個視頻轉碼隊列每個任務獨立實例被回收了任務重新排隊到另一臺機器繼續(xù)跑就行。關鍵是任務狀態(tài)不能存在本地磁盤要存在外部數據庫或對象存儲里。另外我會混合使用按需和競價比如一個集群里70%是競價30%是按需保證即使競價全被回收核心服務也不斷。還有一個技巧是使用競價隊列Spot Fleet或容量優(yōu)化分配策略讓系統自動在多個實例池里找最便宜且穩(wěn)定的容量。不要只盯著一個實例類型出價多選幾個備選中斷概率會低很多。3.3 隱藏成本流量、存儲、快照很多人算EC2成本時只看實例本身的價格結果賬單出來發(fā)現超了不少。EC2的隱藏成本主要有三塊數據傳輸費、EBS存儲費、快照費。數據傳輸方面入站流量通常免費出站流量按量收費而且跨區(qū)域傳輸比同區(qū)域貴。如果你的服務要往外發(fā)大量數據比如視頻、圖片這部分費用可能比實例還高。優(yōu)化方法是把內容放到CDN上或者盡量讓數據在同區(qū)域內流轉。EBS存儲是按配置容量收費的不管你用沒用滿。比如你掛了一塊100G的gp3卷即使只用了10G也按100G收費。所以創(chuàng)建卷時別貪大按實際需求來不夠了再擴?？煺帐前磳嶋H存儲的數據量收費的但如果你頻繁創(chuàng)建快照累積起來也不少。建議設置生命周期策略自動刪除過期的快照。4. 存儲與網絡把地基打牢4.1 EBS卷類型的選擇與性能對比EBS彈性塊存儲就是EC2的硬盤主要有幾種類型gp3、gp2、io1、io2、st1、sc1。gp3是通用型SSD性價比最高基準3000 IOPS和125MB/s吞吐可以額外付費提升。gp2是老一代通用SSD性能跟容量掛鉤容量越大IOPS越高但價格比gp3貴。io1和io2是高性能SSD適合對IOPS要求極高的數據庫io2的耐久性更好。st1是吞吐優(yōu)化型HDD適合大數據處理。sc1是冷存儲HDD最便宜但性能最低。我的建議是絕大多數場景直接用gp3除非你有明確的IOPS需求。gp3的好處是性能和容量解耦你可以買一塊很小的卷但配很高的IOPS這在gp2時代是做不到的。比如一個20G的gp3卷你可以額外買3000 IOPS總共6000 IOPS成本比買一塊大容量gp2低得多。還有一個細節(jié)是EBS卷只能掛載到同一可用區(qū)的實例上。如果你的實例在可用區(qū)A卷在可用區(qū)B是掛不上去的。創(chuàng)建卷時一定要看清楚可用區(qū)。另外一塊卷同一時間只能掛載到一個實例除了io1/io2的多掛載特性別想著幾臺機器共享一塊盤。4.2 安全組與網絡ACL的區(qū)別和配合安全組Security Group和網絡ACLNetwork ACL都是防火墻但工作層次和方式不同。安全組作用于實例級別是有狀態(tài)的你允許了入站流量出站響應自動放行。網絡ACL作用于子網級別是無狀態(tài)的入站和出站規(guī)則要分別配置。實際使用中安全組是主力網絡ACL是補充。我一般這樣配安全組按角色劃分比如Web服務器的安全組允許80和443入站數據庫的安全組只允許來自Web安全組的3306入站。網絡ACL用默認的允許所有就行除非你有特殊的安全合規(guī)要求才去細化。安全組有一個很重要的特性你可以引用另一個安全組作為源而不是寫IP地址。這樣當你的Web服務器擴容或IP變化時數據庫的安全組不用改。這個技巧在多環(huán)境、多層級架構里特別有用。還有一個新手常犯的錯改了安全組規(guī)則后發(fā)現不生效。其實安全組規(guī)則是即時生效的但如果你是通過域名訪問可能是DNS緩存的問題。另外安全組默認拒絕所有入站允許所有出站這個默認行為要記牢。4.3 彈性IP與公有IP的區(qū)別EC2實例可以有兩種IP公有IP和彈性IPEIP。公有IP是自動分配的實例停止再啟動后會變。彈性IP是你手動申請的可以固定綁定到實例上實例重啟也不變。如果你需要一個固定的公網地址比如給客戶配置白名單就必須用彈性IP。彈性IP有一個收費規(guī)則要注意綁定到運行中的實例上是免費的但如果沒綁定或者綁定到停止的實例上會按小時收費。這是為了防止有人占著IP不用。所以如果你暫時不需要某個彈性IP最好釋放掉別留著吃灰。另外彈性IP是區(qū)域級別的資源不能跨區(qū)域使用。你在區(qū)域A申請的EIP只能綁定到區(qū)域A的實例上。如果你在多個區(qū)域有業(yè)務每個區(qū)域都要單獨申請。5. 鏡像、快照與自動化讓重復勞動歸零5.1 AMI的制作與復用AMIAmazon Machine Image是實例的模板包含操作系統、應用、配置等。你可以從公共AMI啟動實例也可以自己制作AMI。自己制作AMI的好處是新實例啟動后直接就是配好的環(huán)境不用再手動裝一遍。制作AMI的流程是先啟動一個實例裝好所有軟件、配好所有參數然后從這個實例創(chuàng)建AMI。創(chuàng)建過程會重啟實例可選不重啟但可能不一致所以最好在業(yè)務低峰期做。AMI創(chuàng)建后你可以用它啟動任意數量的相同實例非常適合橫向擴容。我的經驗是AMI要定期更新。比如每個月打一次安全補丁然后重新制作AMI。舊AMI可以保留幾個版本方便回滾。另外AMI是區(qū)域級別的跨區(qū)域復制需要手動操作而且會產生傳輸費用。5.2 快照的增量備份機制EBS快照是卷的備份第一次是全量之后是增量。增量意味著只備份變化的數據塊所以后續(xù)快照很快也很省空間。但要注意刪除快照時如果后續(xù)快照依賴它系統會保留必要的數據塊不會導致數據損壞?？煺湛梢杂脕韯?chuàng)建新卷也可以跨區(qū)域復制?？鐓^(qū)域復制對于災備很有用比如你把生產環(huán)境的快照復制到另一個區(qū)域萬一主區(qū)域出問題可以在備區(qū)域快速恢復。復制是按數據傳輸量收費的所以別復制太頻繁。我一般會設置一個快照策略每天凌晨自動打一次快照保留最近7天每周打一次保留4周每月打一次保留12個月。這樣既有細粒度的恢復點又有長期的歸檔。生命周期策略可以在控制臺里配不用自己寫腳本。5.3 啟動模板與自動擴縮容啟動模板Launch Template是創(chuàng)建實例的配方包含AMI、實例類型、安全組、密鑰對等所有參數。你可以基于模板創(chuàng)建實例也可以讓自動擴縮容組Auto Scaling Group用模板來動態(tài)增減實例。自動擴縮容的核心是策略。最簡單的策略是目標追蹤比如保持CPU利用率在50%系統會自動增減實例來維持這個目標。還有步進策略和簡單策略適合更復雜的場景。擴縮容組還可以跨可用區(qū)部署提高可用性。這里有一個坑擴縮容組在縮減時會終止實例如果實例上有未保存的數據就丟了。所以擴縮容組里的實例必須是無狀態(tài)的所有狀態(tài)存在外部。另外縮減時默認是隨機選實例終止你可以配置終止策略比如優(yōu)先終止最舊的實例。6. 常見問題與排查技巧實錄6.1 實例連不上的排查思路實例啟動后連不上是最常見的問題。排查順序我一般是這樣先看實例狀態(tài)是不是在運行中再看安全組有沒有放行你的IP和端口然后看網絡ACL有沒有誤攔接著看路由表有沒有指向互聯網網關最后看實例內部防火墻有沒有開服務有沒有監(jiān)聽。如果是SSH連不上還要檢查密鑰對是否正確。很多人創(chuàng)建實例時選錯了密鑰對或者用了.ppk格式但用ssh命令連。密鑰對的權限也很重要Linux下私鑰文件必須是600權限否則SSH會拒絕使用。還有一個隱蔽的問題是實例的公有IP變了。如果你沒綁彈性IP實例停止再啟動后公有IP會變你還在用舊IP連當然連不上。養(yǎng)成習慣需要固定IP就綁彈性IP。6.2 磁盤滿了怎么辦磁盤滿了是另一個高頻問題。EC2的根卷默認可能只有8G或20G裝幾個軟件就滿了。解決辦法有兩種一是擴容根卷二是掛載新卷。擴容根卷的步驟是先在控制臺修改卷大小然后在實例內部擴展分區(qū)和文件系統。Linux下用growpart和resize2fsext4或xfs_growfsxfs。注意擴容只能增大不能縮小所以別一次加太多。掛載新卷的步驟是創(chuàng)建卷、掛載到實例、在實例內分區(qū)格式化、掛載到目錄、修改fstab。fstab一定要用UUID而不是設備名因為設備名可能會變。改完fstab后先用mount -a測試確認沒問題再重啟否則可能開不了機。6.3 賬單異常怎么查賬單比預期高先別慌去Cost Explorer里按服務、按區(qū)域、按標簽拆解。常見原因有忘了關的實例、閑置的彈性IP、未刪除的快照、跨區(qū)域流量、競價實例的額外費用。我建議給所有資源打標簽比如項目、環(huán)境、負責人。這樣賬單出來能直接定位到是誰的什么資源。還可以設置預算告警超過閾值就發(fā)郵件避免月底才發(fā)現超支。還有一個技巧是用成本分配標簽把共享成本按比例分攤到不同項目。比如一個NAT網關被多個項目共用可以按流量比例分攤費用這樣每個項目的成本更準確。7. 我個人在實際操作中的幾點體會用了這么多年EC2踩過的坑不少總結幾條最值錢的經驗。第一永遠不要在生產環(huán)境用默認VPC的默認安全組那個安全組默認允許同組內所有流量很容易出安全問題。第二創(chuàng)建實例時養(yǎng)成打標簽的習慣哪怕只打一個Name標簽以后找資源會方便很多。第三定期檢查閑置資源停止的實例、未綁定的彈性IP、舊的快照這些都是隱形成本。第四自動化能省則省啟動模板、自動擴縮容、快照策略配一次省一輩子。第五多看看CloudWatch的指標CPU、內存、磁盤、網絡異常往往在出問題之前就有征兆。最后再分享一個小技巧如果你不確定某個實例類型適不適合你的應用可以用按需實例跑一天看看CloudWatch的指標再決定要不要轉預留或換類型。別一上來就買三年預留萬一選錯了退都退不掉。