雲端計算架構設計6大原則遵循了哪些？

　　2006年，雲端計算（Cloud Computing）產品誕生，雲端計算的概念也被提出，現在雲端計算幾乎已經滲入所有的行業和應用場景中。我們不一定能直接感受到雲端計算對日常生活、工作、學習的影響，但作為IT基礎設施，它卻悄然支撐著我們正在使用的各個應用。

　　

　　在很多書和雲服務商的官方文件中都介紹過雲端計算的概念、發展歷史、產品體系，我們不再贅述。我們可以從另一個角度去認識雲端計算的整體架構和服務能力，也就是雲端計算架構體系，如圖1所示，其中概括了雲端計算從下到上的組成結構，包括基礎設施、雲端計算作業系統、產品體系（包含安全與合規、監控與管理）、解決方案體系、服務體系。

　　

　　圖1

　　完整的技術架構設計也是有步驟可循的，先是收集需求分析，根據需求分析進行架構設計，再進行評估改進及交付實施，然後持續運營，如圖2所示。

　　

　　圖2

　　在架構設計的各個階段中，每個階段均匯入前一個階段的結果，經過當前階段處理後輸出設計方案或搭建環境，漸進式地推進完整解決方案的設計。

　　（1）需求分析階段由使用者輸入需求痛點，經過分析後輸出需求分析表。

　　（2）在架構設計階段中，根據需求分析表來匹配合適的設計模式，形成完整的架構設計方案。

　　（3）在評估改進階段，對已完成的架構設計方案進行評估，輸出經過評估和參考良好架構設計原則改進過的架構設計方案。

　　（4）在交付實施階段，根據經過評估改進的架構設計方案在雲平臺中搭建環境、部署業務，提供符合架構設計的雲端環境。

　　（5）在架構的持續運營中，輸入解決方案和當前業務執行狀況，持續巡檢、分析、評估（參見《雲端架構》一書的第11章），輸出改進措施，進行重構改進，並週而復始地根據新需求提供方案。

　　基於雲端計算進行架構設計，所有的技術解決方案都應遵循一定的原則，這也是架構設計中要追求的目標。

　　圖3所示為架構設計的6大原則，包括合理部署、業務持續、彈性擴充套件、效能效率、安全合規、持續運營。

　　

　　圖3

　　這6大原則代表了架構設計中需要考慮的不同角度，只有同時遵循這些原則才能設計出完善的架構方案，但在實際情況中，並不需要在所有架構設計中把所有設計模式都融入進去，構建繁雜的架構方案。後面會對這6大原則逐一展開介紹，從各個原則的子項中進行設計。

　 　1 合理部署

　　業務系統在公有云上的部署包括使用虛擬機器形式的雲主機，還包括效能更強的物理雲主機形式，託管服務包括託管應用、託管物理伺服器。

　　基於IT歷史資源狀況、合規性要求等，很多企業還沒有上雲，針對這種情況，將雲端計算作業系統抽取出來打包為獨立的軟體和服務，在使用者的私有化環境中進行部署。區別於公有云面向“任何”使用者開放使用，私有化部署僅面向少數指定的使用者使用。

　　混合架構能夠對公有云和私有化部署的平臺、傳統的VMware、OpenStack虛擬化平臺或物理伺服器等資源進行統一管理和排程，混合架構既享受了不變更本地環境、滿足合規要求的好處，又享受了雲平臺資源豐富、服務能力充足等優勢。混合架構也是當前企業轉型上雲的一種中間狀態，會長期存在。

　　在跨境電商、遊戲出海等場景下會使用到全球範圍內的多個地域，將業務和資料靠近使用者來部署可以減少網路延遲、提升訪問體驗。因此，納入了全球部署，來重點解決如何在全球範圍內儘可能靠近使用者部署的問題，也能實現資料同步儲存和處理的方案。

　　不能相信任何一塊硬碟、任何一臺雲主機、任何一個可用區、任何一個地域，也不能完全相信任何一個雲服務商，進行業務部署時應選擇多個公有云平臺，提升業務持續性，彌補單個雲服務商在資源和服務上的短板，遮蔽雲服務商的一些技術鎖定和商業繫結。

　 　2 業務持續

　　業務持續性主要是指高可用、高可靠、災難恢復三方面，在設計模式中也是按照這個邏輯展開的。

　　高可用（High Availability），是指當業務執行的資源出現故障時，透過冗餘等設計來避免業務中斷。

　　高可靠（Continuous Operations），是指業務執行的資源無故障，業務可持續提供服務。

　　災難恢復（Disaster Recovery），是指當業務執行環境遭到破壞時，在不同環境中恢復應用和資料的能力。

　　在架構設計的每一層中都應實現冗餘和業務持續性，沒有冗餘就意味著會出現單點，而單點一旦出現故障，就會造成區域性服務終止。

　　儲存產品：塊儲存透過三個副本實現冗餘，當一個副本出現錯誤時，透過其他副本來校驗和恢復資料；物件儲存中透過糾刪碼來實現資料冗餘校驗，提供可恢復能力；物件儲存提供跨區域複製功能，避免單個地域成為物件儲存的單點。

　　備份方案：在雲端透過跨可用區、跨地域的資料備份提升可靠性，避免只儲存一份資料；在混合架構中將資料備份到雲端，在本地環境資料損壞時，可透過雲端備份檔案進行恢復。

　　容災方案：對業務系統實現容災，避免當前業務環境成為單點，提升整體業務的可用性和抗風險能力。

　　高可用：透過跨可用區的負載均衡部署實現雲主機和可用區的冗餘；透過全域性負載均衡實現跨地域、跨雲平臺的高可用。

　 　3 彈性擴充套件

　　緊耦合的系統不容易擴充套件，在出現軟體Bug和系統故障時難以排查問題，呼叫每個系統元件的壓力各不相同，小問題逐級放大，容易造成整個業務中斷。要保持系統彈性擴充套件，首先要進行系統元件的解耦，包含動態資料和靜態資料解耦，解耦後的元件可實現功能單元化，各司其職。

　　解耦之後再對元件和服務進行擴充套件，即計算資源的縱向擴充套件、橫向擴充套件和自動伸縮，包括資料庫層的擴充套件，還有透過混合架構延展本地環境的計算、儲存備份、安全防護、產品服務能力。對應用和資料的遷移也算作整個系統的擴充套件，從一個環境遷移到另外一個環境，系統應保持彈性擴充套件，在需要遷移時能夠快速實施遷移。最後還要進行均衡，元件解耦、資源和服務擴充套件之後需要統一的接入入口，以遮蔽底層解耦與擴充套件帶來的介面不統一等問題，將這些都納入均衡和全域性負載均衡中來介紹。

　　在各個層面實現解耦，透過訊息佇列來解耦元件之間的通訊，並解耦事件；透過Redis等共享儲存實現狀態資料與計算資源的解耦；採用雲主機部署業務應該面向服務而非資源，將資源與業務解耦；儲存實現彈性可掛載和可解除安裝的雲硬碟，採用可繫結和解繫結的EIP；透過DDoS防護、WAF防護等解耦安全防護與計算資源；使用原生的計算能力、儲存能力將業務與雲平臺的特性解耦，實現業務在多個雲平臺中的可擴充套件。

　　元件解耦是實現可擴充套件的前提，可透過以下方式進行解耦。

　　保持無狀態，將狀態資料儲存到Redis中。

　　放到負載均衡中，擴容、縮容不影響整體業務。

　　透過訊息佇列、API Gateway解耦，生產者、消費者可擴充套件且互不影響。

　　實現業務的全域性負載均衡，後端業務能夠在混合架構、多雲環境中進行擴充套件

　　 4 效能效率

　　非常多的解決方案和案例中都涉及高併發、流量激增帶來的對效能的挑戰，在效能效率中，主要目標是發現和提升應用的效能，提高資源和元件的效率。

　　首先是計算效能，透過採用高配置的雲主機或物理雲主機來提升單機效能，透過叢集形式擴充套件整體服務效能。

　　其次是儲存和快取，透過Redis來快取熱點資料、儲存臨時狀態資料，在記憶體中進行計算能夠提升業務效能。在每一層使用快取，透過CDN快取靜態檔案，對沒有命中的檔案進行回源；透過Redis快取資料庫，加速資料庫的訪問；透過Redis快取熱點配置檔案、熱點資料，提前載入，減少訪問時間。

　　再次是對網路效能的最佳化，在業務實現全球部署時選擇資料中心，並且基於全球基礎網路、CDN及全球應用加速來提升網路效能，獲得請求加速效果。

　　最後介紹應用效能監測和壓力測試，從應用的角度上來評測當前的效能狀況、發現問題瓶頸，並針對性地解決問題。

　 　5 安全合規

　　安全合規一方面是為了滿足業務安全防護的自身需求，另一方面是滿足安全監管的合規要求，在具體實施時會將這兩方面交叉在一起。

　　首先，從使用者賬號和許可權管理切入，為合適的人員分配恰當的賬號、角色，授予許可權，對於透過API或CLI來訪問的程式或人員分配恰當的公鑰、私鑰和許可權，對於臨時訪問的物件儲存檔案Token等也進行嚴格管理。其次，還有在整個安全體系中的終端安全、資料安全、網路安全、應用安全，以及對日誌、行為、資料庫操作的審計。最後，還有等保2.0的要求、網站備案要求、滿足GDPR等各地區對業務和資料隱私要求的制度等。

　　在賬號體系中設定主賬號、子賬號，並對公鑰、金鑰進行管理；設定合適的角色，為賬號、角色分配所需要的許可權。

　　透過ACL控制網路訪問；透過安全組限制雲主機開放的埠等；透過子網和路由控制跨子網的通訊。將資料庫及只需要內部訪問的雲主機配置到內網VPC中，設定允許訪問的VPC，設定為不連通外網。

　　防止DDoS、cc、SQL隱碼攻擊、XSS等攻擊。

　　安全審計，保留訪問日誌、操作日誌，逐步實現低頻儲存、歸檔儲存等。

　 　6 持續運營

　　雲平臺提供的資源與服務均有SLA，雲主機的SLA通常為99.95%，使用者構建的業務系統都是基於雲資源和雲服務的SLA，在此之上構建可用性、可靠性更高的業務系統。對於自身業務系統，也需要制定SLA來表明服務可用性或其他指標，制定了使用者業務的SLA後，就可以按照SLA閾值來設定高可用限流值，綜合評估整體業務的服務可用性和資料可靠性，並指定故障應急措施。

　　在持續運營中會對雲資源、雲服務、事件及使用者的應用進行監控，並設定告警，在達到告警條件時，透過電話、簡訊、郵件、釘釘、微信等方式通知相關人員，將告警交給回撥函式，可實現自動化故障處理或相應的應急預案，減少人工介入。

　　應該在架構設計的每一層進行監控與告警，包括對雲資源、事件、應用執行狀況的全方位監控。對於使用者自定義的需要監測的資源與服務，需要配置合理有效的告警策略來及時發現異常情況。透過Advisor實現雲平臺巡檢，持續監測資源的變化，持續定期評估業務架構，及時發現業務架構是否還匹配業務需求。

　　此外，還需要具備自動化響應及處理功能，自動伸縮能夠透過監控CPU等指標自動擴容或縮容雲主機數量；透過定時器固定週期擴容或縮容雲主機數量。實現事件驅動響應，由事件訊息觸發執行指令碼、回撥函式等操作，實現智慧運維，根據事件和告警自動觸發運維操作，編排運維指令碼，透過智慧運維的方式來減少人工運維。

　　及時發現消費及業務成本的變化，並對成本進行最佳化。設定賬戶餘額告警值，避免快速消費，實現成本控制。評估資源使用時長，將按時計費的資源轉變為按月、按年計費，最佳化資源的使用。透過Advisor中建議的成本最佳化釋放沒有使用的EIP，根據CPU等指標來減少雲主機數量或降低雲主機配置，雲主機處理物件儲存時透過內網進行訪問，減少外網訪問的流量費用。透過多雲部署實現成本最佳化，綜合多個雲平臺的資源價格選擇資源，選用較優的組合方案，透過其他雲平臺更低單價的競價例項雲主機來處理OLAP的業務。