使用雲效在阿里雲上進行一站式開發運維

摘要： 雲效，一站式企業協同研發雲,提供從「需求->開發->測試->發佈->運維->運營」端到端的協同服務和研發工具支撐。雲效將計劃與其餘雲產品合做，進一步優化一站式體驗。

導讀

做爲一站式企業協同研發雲，雲效提供從「需求->開發->測試->發佈->運維->運營」端到端的協同服務和研發工具支撐。同時雲效與其它經常使用的雲產品緊密集成，提供以應用爲核心的一站式研發體驗。先上一張大圖：

 

爲何須要雲效來集成各個雲產品？

重複的概念

目前阿里雲提供了大量的優秀的雲產品，好比ECS，SLB，雲監控，日誌服務，幫助用戶進行線上服務的部署，運維，監控，告警。

但實際用起來以後，你會發現一個很明顯的問題。那就是有些概念，好比機器分組，會在多個產品中重複實現。假設我如今有一個線上的Web應用，包含了5臺機器。那麼我須要在日誌服務中將這5臺機器配置到一個分組，而後再在雲監控中把一樣的5臺機器分到雲監控的分組，再把這5臺機器掛在某個SLB下。不過這個事情其實也容易理解，由於缺少了一個基礎的公共概念，那就是應用。

而云效做爲一個研發協同平臺，天生就是以應用爲核心的。應用下面有不一樣的環境，每一個環境對應一個機器組，使用這個機器組的概念，就能夠將各個雲產品的機器組的概念統一塊兒來。經過Open API的方式，雲效能夠在建立應用的同時，就把上述的這些相關服務配置好。同時應用也會成爲一個訪問其餘各個雲產品的快捷入口。

不一致的配置

讓咱們再進入到單獨的一個雲產品來看看。好比日誌服務。日誌服務須要配置日誌收集的路徑。通常來說用戶會對每一個應用單獨的、重複的進行配置。有些應用的配置多是相同的，有些多是不一樣的。設想一下，若是全部應用的日誌路徑配置都是相同的，或者提及碼是有規律的（好比阿里巴巴內部的大多數應用的日誌都會放在/home/admin/<應用名>/logs這個目錄下），那麼雲效就能夠在您建立應用時候，就自動將收集路徑配置好。那麼如何才能作到應用的日誌路徑是一致的呢，雲效的方案很簡單，那就是使用代碼模板。經過雲效的一站式解決方案嚮導建立的出來的代碼庫中就包含了標準的日誌配置（好比logback.xml）。

機器上除了應用的日誌以外，您可能還須要關心Web Server（Nginx/Apache）及應用容器（Tomcat）的日誌。這些日誌的位置就不是代碼模板能夠解決的了。雲效提供的解決方案是ECS模板。您能夠自定義ECS模板，也可使用雲效默認提供的模板。有了模板，那麼Web Server和應用容器的日誌的位置也就肯定下來了，雲效也能夠自動的幫您建立出來。

來源於阿里內部的解決方案

上面提到的這些問題，僅僅是一部分。而上面提到的解決方案也偏偏是阿里內部的思路。雲效的阿里內部版本服務了整個集團幾萬人的的研發人員。把應用的整個生命週期與各個相關的服務（日誌，監控，VIP等）有機的串接起來，最大限度的減小重複性的工做。一個阿里的同窗建立一個新的應用，基本上都感受不到這些服務的存在，只有當機器真的出現問題時候，你纔會收到告警。這種體驗，說真的，真是棒極了。

咱們也很是期待使用這套理念來服務更多的雲上用戶。

基於雲產品進行更多的場景化

上面主要是講解如何以應用爲核心來串接各個雲產品。在此基礎上咱們就能作更多的場景化的事情，好比藍綠髮布和動態伸縮。下面用藍綠髮布這個場景舉個例子。

藍綠髮布

藍綠髮布是業界經常使用的實踐。基於阿里雲的SLB咱們也能夠手動的實現藍綠髮布，無非也就是：

1. 建立並部署新的機器
2. 將SLB的流量手動切換到新部署的機器
3. 若是出現問題，則手動再切換回到舊的那一批機器
4. 若是沒問題，則銷燬舊的那一批機器

固然每次手動作這件事情，也是很是痛苦的。因此雲效能作的事情，就是在SLB等基礎設施的基礎上編排場景。幫助您屏蔽這些細節。

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：