Web應用託管服務（Web+）隱藏的十個上雲最佳姿式

隨着雲計算浪潮的推動，技術架構雲化已經成爲大勢所趨。特別是最近由CNCF推進的雲原生概念，將符合雲原生標準的各類開源技術方案推向了史無前例的高度。在這一波浪潮的推進下，愈來愈多的企業開始了自身的數字化征程，逐步將本身的IT基礎設施往雲上遷移。Web應用託管服務（Web+） 正是在這一波浪潮下應運而生的黑科技產品——以應用爲中心，爲應用編排所需的雲資源，並將中間件團隊支持近千家企業客戶上雲時遇到各種問題的解決辦法，造成一套最佳實踐沉澱到這個產品中呈現給你們。這篇文章，就將逐一貫你們揭祕隱藏在這個產品背後的十個最佳實踐。

基礎設施即代碼（Infrastructure As Code）

基礎設施即代碼，簡言之就是用代碼或配置文件來聲明應用系統使用的基礎設施資源。雲計算技術發展到如今，基礎設施即服務（IaaS）能力已經變得很是成熟了，其能託管的底層資源也愈來愈豐富，從計算資源、網絡資源、存儲資源到大數據資源、區塊鏈資源以及人工智能資源等等，均可以做爲基礎設施被按需取用。所以也產生一個問題，就是雲資源的使用變得愈來愈複雜，門檻愈來愈高，一個複雜一點的業務系統動輒集成十幾個雲計算產品是很是常見的狀況。不只如此，這些資源應該如何被編排與使用，有時須要富有云架構管理經驗的人員輔助才能得以順暢實施。這些都嚴重加重了雲計算能力向中小用戶滲透的難度，致使發展受阻。而基礎設施即代碼能夠很是優雅的解決這個問題，用戶再也不須要手動管理基礎設施，而只須要以代碼的方式提交對資源的聲明，即可由系統自動完成對資源的建立、編排與配置，極大下降了雲產品的使用難度。並且一套符合標準的基礎設施即代碼文檔是能夠被分發及複用的，這有助於打破雲廠商之間的產品界限，促進計算技術的革新與發展。

省錢之道：預留實例，包年的優惠按量的使用

提到雲計算，咱們都會想到其低廉的價格和按需使用的特性，所以按量付費也理應成爲雲計算產品的主流付費方式。設想假若用戶購買了一臺以包年包月方式計費的雲產品，他該如何才能作到按需使用呢？尤爲是遇到彈性伸縮這種場景——系統所使用的計算資源會隨着訪問量的大小而自動擴容或縮容，包年包月的付費方式顯然沒辦法如此靈活，並且也與雲計算倡導的按需取用的理念相違背。可是，包年包月的付費方式顯然也有其吸引人的一面，那即是價格優點——一般來講都會比按量付費要便宜。這也很是容易解釋，把包年包月看成是按量付費的一種批發形式就不難理解其價格差別了。那麼是否存在一種付費方式，既不違背按需取用的雲計算精神，又可以幫助用戶節約成本呢？這即是預留實例。咱們能夠把預留實例想象成遊戲機室使用的遊戲代幣，買得越多越便宜。而想要玩某一臺遊戲機的時候，僅需支付若干枚代幣便可。預留實例也是這個原理。用戶須要購買1年或更長時間的預留實例以得到優惠，而這個預留實例能夠用來抵扣按量付費產品產生的費用，也就是說若是使用了一個小時，那麼就會從預留實例中扣除一個小時的費用，直到消耗完畢。

合理使用配置

在The Twelve-Factor App的第三部分就提到了與配置有關的原則。本文所說的配置能夠涵蓋很是普遍的概念，除了狹隘意義上的應用程序配置文件，上文中提到的基礎設施即服務的有關文檔也能夠屬於配置的一部分。

配置與代碼分離。代碼做爲應用系統的構建來源，天然與產出物是密不可分的。咱們一般將應用程序或軟件包稱做爲「構件」也具備這層含義——即經過代碼編譯而造成的組件。從版本管理的角度來看，代碼能夠被認爲是具備不可變屬性的，代碼的變動一般意味着版本的升級。若是代碼變動與版本升級之間脫離關係，必然會形成軟件版本的混亂，給交付、部署和運維帶來困難。而配置卻不盡相同，雖然各類最佳實踐也是建議將配置以版本化的方式來管理，可是配置與代碼分離管理，是更好的解決方案。由於配置的變動與代碼的變動不必定是同步的，切換某臺主機的IP地址，更改某個數據庫鏈接池大小等等，這些都不依賴代碼的變動，也就是說在同一個版本的軟件包上能夠應用不一樣的配置。在微服務領域，系統配置一般會由一個獨立的配置中心服務來維護，其負責管理配置變動、配置版本以及配置推送，無論應用部署的是哪一個版本，只要需求和環境不發生變動，配置就能夠始終複用。

配置與環境共存。雖然配置不依賴代碼而存在，但其與環境的關係倒是很是密切的。舉個簡單的例子，一個應用系統從開發到上線一般都會存在開發環境、測試環境、預發環境以及線上環境等，而每一個環境的配置可能都是不一樣的。例如測試環境無需高可用，性能也不用特別優化，基本上知足系統可以運行起來就夠了。而線上環境就須要保證高可用、高性能與穩定性，天然環境配置也不相同。假若咱們把系統環境中的全部配置都固化下來，那麼這份配置與環境就是徹底映射的了，即使環境被銷燬，咱們也能夠經過這個配置從新啓動一套如出一轍的環境，這就是配置與環境共存的含義。

作好數據安全與審計

安全是個很大的話題，一般來講沒有絕對意義上的安全，也沒有單方面的安全責任，只要有互聯網存在安全就是永遠不能迴避的問題。從功能設計到代碼實現、從系統架構到部署實施、從底層資源到上層業務、從數據存儲到業務流程，每一個環節均可能會有被侵入的風險，所以安全須要是客戶與廠商共建的系統性能力。可是無論怎麼樣，有兩件最基礎的事情，咱們能夠先作好：1）作好數據安全；2）作好安全審計；以雲產品爲例子，請見下圖：
首先：數據安全是用戶最爲擔憂的問題，咱們建議從上傳開始，不用流轉太多的服務，就利用雲存儲的能力，直接到達您的「家裏」。
其次：全部須要針對機器下發的指令，建議走雲廠商提供的正規通道，這麼作的一個很重要的理由就是能夠作到能夠控制權限，也能夠作到審計。

使用 ECS 實例訪問角色

承上文，之因此可以實現數據鏈路的徹底隔離，還要得益於實例訪問角色的支持。簡單來講，運行在主機實例上的應用默認是沒有辦法直接訪問用戶的其餘資源的（圖中主機實例從共享存儲中讀取數據的鏈路）。想要實現此目標的辦法有兩種。一種是將用戶帳號的AK/SK配置到應用中，讓應用以該帳號的權限訪問用戶資源。這種辦法的優點就是簡單易用，僅需生成並配置AK/SK，再經過API進行訪問便可，幾乎沒有什麼額外的開發成本。但其劣勢也是很是明顯的，即該AK/SK存在泄漏的風險，一旦泄漏，非法用戶即可以使用該組AK/SK訪問用戶的任何受權資源，結果將很是危險。另外一種辦法就是經過實例訪問角色，將訪問用戶資源的權限受權給主機實例的服務帳號，再由該帳號訪問用戶的資源，這種機制從如下三點保證了安全性：

• 時效性：訪問雲資源時，可根據一個臨時令牌是生成一對臨時的AK/SK，竊取訪問權限的難度倍增，且即使盜用成功，也僅在某一段時間內可用，過時後即失效。
• 隔離性：您能夠授予不一樣的主機實例，從而作到實例級別的身份隔離。即便黑客攻破了其中一臺，對其餘主機也不會產生影響。這樣作的好處也體如今無需額外配置AK/SK，直接從主機實例上就能獲取對應的訪問憑證。
• 可管控：能夠隨時在RAM控制檯上撤銷訪問權限，或者調整其權限，從而作到對實例級別的精確控制。

計算與存儲分離

計算與存儲分離，便是一種架構理念的革新，也是一種運維習慣的轉變。在架構上，咱們推薦您儘可能將服務用的計算集羣與數據存儲用的存儲集羣進行隔離。這樣一來，咱們針對計算集羣只須要作簡單的擴容，就能應對特定場景下流量的突增；而同時，針對存儲集羣作針對性保護。在運維上，計算集羣與存儲集羣也須要分開部署，由於不少狀況下不是同一組人員在維護計算與存儲集羣。
在雲上，經常使用的數據服務如：緩存、日誌、數據庫、分佈式存儲和雲盤等，已經可以知足絕大部分的業務須要了，而針對特定場景（如大數據和NoSQL等）雲廠商也提供了相應的解決方案。這些成熟的方案，能夠爲您解決部署、運維、數據同步和備份等諸多問題。

水平擴容優於垂直擴容

雲計算帶來的資源革命，主要體如今對待資源的申請方式上，即：從以前的什麼都規劃好到按需申請、按量訪問，儘可能利用雲的彈性能力得到最高的利用率。因此在雲時代，咱們推薦是須要資源的時候就按需申請，不須要的時候就歸還回去。這意味着，不推薦一上來就使用很大規格的機器，而是先申請一臺較小規模的，等到須要的時候再擴容。由多臺小規格機器組成的服務集羣，比單一一臺大規格的機器，既方便伸縮，也可以獲取更多資源（如：帶寬和磁盤等），更重要的是它會讓您的服務自然具備高可用的能力。

儘可能複用 SLB

每個服務須要對外提供服務時，若是是一個集羣，須要以統一的出口對外，這個時候須要用到SLB的能力。阿里雲的SLB目前由統一的集羣負責，能夠實現四層、七層的轉發。隨着您的應用個數或者對外暴露的服務愈來愈多，能夠選擇複用SLB——即選擇同一個SLB ，使用域名或者URL的方式，將流量轉發到不一樣的服務器組，以下圖所示： 

這樣作有兩個好處：
一、安全：減小對外暴露IP個數，加強整個服務集羣的安全性。
二、節約成本：複用SLB能夠最大限度的利用到單個SLB的帶寬，由於SLB的費用主要依賴實例個數和對外流量。

雲助你輕鬆高可用

高可用這個話題若是從廣義上說，從代碼編寫、軟件設計、部署架構都會或多或少的影響到服務的高可用，咱們這一小節主要是講部署結構。傳統意義上的高可用，體如今部署結構上主要有：同城容災、異地多活、兩地三中心等常見的架構。而異地多活和兩地三中心牽涉到更多的是須要自身業務架構師調整架構設計，其中很難處理的如數據同步與服務切換，就與業務有着莫大的干係，這些都須要業務團隊針對自身的架構特色有專門的工具來作支撐才能完美支持。不過同城容災在雲上是很好作到的，具體來講，咱們能夠從如下三個方面討論。
一、流量高可用：不過既然是集羣，就須要保持高可用的能力，咱們推薦您在開SLB時選擇 「多可用區」 的模式讓其具有此的能力。
二、存儲高可用：存儲節點以阿里雲的RDS爲例，自己就自帶了主備、集羣等高可用的模式，若是選擇主備模式，默承認以作到跨可用區的同城容災模式。並且，雲上提供的幾乎全部的數據服務，都會帶備份的功能。
三、計算高可用：若是存儲和計算分離以後，計算節點的高可用方式，能夠直接根據可用區均勻分佈；雖然可用區之間物理上有必定隔離，可是不影響訪問速度。

監控與日誌

集羣規模在某個數量之內的時候，咱們查看監控與日誌的成本都是能夠接受的，當咱們的規模超過某個數量（好比：3）臺以上，甚至是一個微服務的大集羣后，應用維度的日誌查看、分析聚合甚至診斷、以及監控報警會瞬間變得迫在眉睫。業內針對這些領域，都有對應的開源的方案，如：日誌聚合的ELK，監控報警的Zabbix、診斷領域有各類類型的APM產品。
阿里雲上對應的領域也有對應的開源產品的商業化解決方案，如日誌服務SLS、APM產品ARMS 、雲監控等等。咱們推薦使用這些成熟的有人兜底的方案，免去本身運維與搭建的煩惱。

結語

雲產品Web應用託管服務（Web+） 的產品設計，正是默認給咱們的客戶提供了上述十點的最佳實踐，全力相助您在上雲之路上走的更加的順暢，產品永久免費，目前正在公測階段，歡迎體驗。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。