雲上架構概述
雲上搭建架構不單單需要考慮到性能和可用性，還有安全性、可管理性、彈性等層面都需要注意，實際工作中每一個環節都需要顧及到。
傳統架構與雲上架構設計方法對比，傳統的架構設計周期會比較長，一般的企業架構都會考慮今後3到5年的規劃，解決的主要是有無的問題，是從0到1的架構搭建。雲上的架構設計周期相對來說比較短，需求明确且主要是解決或優化已有的問題。
雲上架構的高性能
什麼是性能
性能是很難衡量的，狹義上的性能指的是運作速度的快慢，廣義的性能則涉及更多的内容，如功耗、使用率、性能價格比、速度等。不同視角下關注性能的側重點不同，使用者視角下關注的是從請求發送到獲得響應的整個時間間隔，對使用者來說時間越長性能越差。從架構和開發者視角出發更多是關注響應延時、系統吞吐量以及并發處理能力，而更重要的是明确了解使用者反映問題的根源。
高性能架構設計的基本步驟
搭建高性能架構有4個基本步驟，首先要明确性能的目标，接着分析系統中影響目标實作的所有問題，找到問題後再着手解決這些問題，最後通過性能評估的手段來測試目前性能名額。如果評估結果與性能目标之前存在差異，就說明影響性能的問題還沒有被全部找到，這時需要重新開始進行之前的步驟。
整個過程其實是一個循環，即使某一次性能評估達标，但随着時間的推移業務的發展還是會出現新的性能需要。
進一步分析
性能目标指的是制定的符合高性能的名額，比如頁面響應時間小于1秒，并發使用者可以達到1萬，高峰期每秒處理10000萬使用者請求等。
然後要根據性能目标分析目前業務系統中不同層次有哪些影響性能名額的問題，比如網絡層方面的帶寬、延遲，計算層方面的Cpu處理能力、是否采用叢集，以及一些其他方面的影響因素。是以說系統性能高低由整體的處理能力決定，不由單一因素決定。
分析出問題後就開始解決問題，這時可以從兩個方面着手。一方面是最簡便也是大多數人首先會想到的，即提升系統硬體配置，如果硬體資源的更新能夠解決問題，那麼就直接采用這種方式，它最大的好處在于不用對現有的代碼邏輯做任何的修改。但是大部分的情況下往往無法簡單的通過硬體更新解決所有問題，還需要從架構的層次上入手，降低伺服器壓力，采用可擴充架構提高性能。
傳統的測試可以使用LoadRunner之類的工具，雲上則可以使用阿裡雲性能測試服務PTS。PTS與傳統的性能測試最大的不同在于LoadRunner需要自己搭建，同時搭建好的測試系統會受限于本身的服務上限，伺服器的數量決定了所能模拟的測試壓力。PTS則可以快速的模拟大量并發請求，因為是雲上是以PTS後端能夠通過叢集的方式模拟使用者需要的并發量。
上圖是我們提出的相對較好的架構方案，前端由負載均衡服務響應使用者請求，在把請求轉發給後端具體的伺服器之前會有一個前端緩存，用來提升響應時間以及減輕後端壓力。後端伺服器通過叢集方式響應使用者請求，同時應用之間通過異步進行互動。通路資料庫之前先通過緩存響應請求，在不能命中的時候再去通路資料庫。
使用緩存時有個問題需要特别注意，即緩存與資料庫的資料不一緻。針對這一問題解決方式是不同的，要根據不同的需求來選擇。比如有一種方式是在寫資料庫的資料同時更新緩存中的資料或者讓緩存失效，這樣使用者在讀取的時候，要麼擷取的是最新資料，要麼得從資料庫中重新讀取資料。
某客戶在阿裡雲上的高性能架構
上圖是我們某個客戶的雲上架構。前端使用者請求通過CDN服務響應，CDN主要用來做服務加速，對于可以滿足的響應直接使用CDN解決，無法滿足的請求轉發給後端SLB。
從圖中可以看到不同的應用使用的伺服器數量不同，這裡所有的服務都被部署到ECS上，ECS又挂載在SLB後面，另外其中還有OCS資料緩存，使用者請求的資料如果無法從緩存中擷取到，就從資料庫中讀取。
資料庫的設計同樣也非常複雜，首先它實作了一套讀寫分離，其次有一個DRDS分布式關系型資料庫，能夠挂載多個RDS執行個體，所有的請求都會發送給DRDS，而DRDS則相當于中間的路由代理，它會根據請求從不同的RDS中擷取資料。
使用DRDS有幾點需要注意，第一DRDS必須要和RDS結合使用，DRDS本身不存儲資料，資料的存儲都是在RDS上；第二DRDS後的RDS執行個體必須是Mysql資料庫；第三DRDS有兩種使用方式，一種是表的拆分一種是表的不拆分，如果不拆分DRDS會将表存在某一個RDS執行個體。
雲上架構的高可用
高可用的定義
從字面意思上來看高可用其實就是為了減少停工時間，保持服務高度可用性。系統做高可用首先要具備自動偵測、自動切換、和自動恢複的能力。
自動偵測：通過備援偵測發現運作的情況，将所彙集的訊息記錄下來，以供維護參考。
自動切換：确認對方故障，則正常主機代替故障主機工作。
自動恢複：故障主機修複後，自動切換回修複完成的主機上。
高可用設計的前提
進行高可用設計時一般建議事先對自身架構做階層化和子產品化的改造，按照應用層、基礎設施層進行高可用設計，再按照功能劃分子產品，子產品之間松耦合，且要求穩定可靠易于擴充，結構簡單易于維護。
高可用設計方式
高可用設計包含三種方式，分别是主從方式，主機工作，備機處于監控準備；雙機互備，兩台主機同時運作各自服務工作且互相監測；叢集工作，多台主機一起工作，各自運作一個或幾個服務。
高可用架構設計原則
假定失效設計：假定任何環節都會出問題，然後倒推設計；
多可用區設計：盡最大可能避免架構中的單點故障；
自動擴充設計：不進行設計調整，就能滿足業務量增長；
自我修複設計：内建容錯及檢查能力，應用能夠在部分元件失效時自我修複繼續工作；
松耦合設計：耦合度越小，擴充性越好，容錯能力越強
多可用區設計
在SLB執行個體下綁定不同可用區的ECS，進而避免因為單個可用區的故障而導緻對外服務的不可用。多可用區的雲資料庫RDS可以實作同城的資料災備，OSS存儲的資料預設會儲存在多個不同可用區中。
健康檢查自我修複
如果某台ECS執行個體不健康，導緻健康中執行個體數低于最小值，彈性伸縮就會自動建立健康的ECS執行個體代替不健康的執行個體。
松耦合設計
通過消息解耦将原應用拆分成獨立的子產品，子產品間的影響小，就不會因為部分失效導緻整體不可用。
原文釋出時間為：2018-06-12
本文作者：翟永東
本文來自雲栖社群合作夥伴“
資料和雲”，了解相關資訊可以關注“
”。