今年在原版spinnaker的基礎上我們和雲平臺廠商合作支持了阿里雲和騰訊雲，俗話說“是騾子是馬拉出來遛遛“，今年的跨年晚會彈性部分將完全交給spinnaker來處理。現在是聖誕夜，我和小夥伴們還在spinnaker平臺上加班做容災和擴容，希望一週後的”多雲多活極致彈性“能給2019年畫上完美的句號。
以下是雲平臺在實現spinnaker時遇到的一些問題，同時也是自動化持續部署需要注意的共性的地方，一起拿來出分析下，與君共勉。
1 彈性伸縮組帶寬瓶頸
無論是哪種雲，都需要考慮到一個彈性需要接入多個“流量入口“的場景。
阿里雲，需要考慮接入多個虛擬服務器組來根據path做不同轉發的場景，而且也需要要考慮作爲默認服務器組接入多個LB，因爲阿里雲的LB將會成爲帶寬瓶頸，通過對接多LB可以擴展入網帶寬。
騰訊雲的帶寬瓶頸配置在LB後端的實例上，實例的總帶寬決定了整體彈性帶寬能力，所以配置實例時需要把帶寬放到最大。
2 彈性需要具備多AZ的能力
彈性伸縮組配置時需要配置多子網，每個子網屬於不通的區，例如選擇北京CDEF四個zone。一方面是通過散列部署的方式避免雲平臺某個區出現故障時整個彈性掛掉，另一方面當雲平臺資源緊張時可以保證能擴展出實例。
這一點是阿里雲比騰訊雲做的優秀的地方，騰訊雲雖然雲控臺上支持多AZ，但是我親測後開出的機器都會落到一個區。
3 彈性需要具備多實例類型的能力
多實例類型並不是必須的，是爲了應對資源緊張時的一種方案，儘可能地開的出機器。
4 Deploy環節流量割接需要嚴謹的判斷服務能力
服務能力的判斷分爲兩個維度：能否提供服務和能否提供足夠的服務。
4.1 能否提供服務
LB通過健康檢查來判斷某個實例是否能夠提供服務，然後決定是否往這個實例調量，所以一定要保證LB中配置的健康檢查路徑代表真實的服務情況。工作中發現有些產品把nginx靜態文件作爲健康檢查路徑，這是大錯特錯的，因爲nginx活並不能代表你的服務是活的。
像搜索引擎等需要預熱的場景也要考慮周全，因爲那些服務需要把磁盤內容加載到緩存中才可以被調量，否則緩存層是空的壓力一下來直接被打死。
4.2 能否提供足夠的服務
一定要判斷彈性伸縮中實例的個數，這個是血的教訓。
Spinnaker中有一種紅黑髮布，可以選擇按照現有彈性伸縮組的實例個數來進行紅黑髮布，我平時使用中都沒有發現問題，直到跨年前資源比較緊張的時候由於雲資源內部實例售罄導致新的彈性伸縮並沒有開足，而LB到這個新的彈性伸縮所有實例的健康檢查都是通過的，所以就做了流量的割接，LB打往老彈性的流量全部放給了新彈性，結果新彈性由於服務能力不足險些被打掛。
後來緊急修復了這個bug，也給我敲醒了警鐘，凡是涉及生產流量割接的問題一定要對服務能力有充足的判斷。
5 彈性伸縮組中的彈性規則需要完整繼承
彈性伸縮組最大的好處是可以彈性伸縮，彈性伸縮是伸縮規則+伸縮觸發組成的。不同的雲平臺在配置上略有區別，但是原理都是相通的。先配置好伸縮規則，代表你的伸縮組是要縮容還是擴容，縮容擴容幾臺機器或者到什麼程度；再去配置伸縮觸發，一般包括schedule和報警規則兩類，前者適用於潮汐型的業務，後者用於非週期型也就是突發型的業務。
以上的配置基本都比較複雜，而且涵蓋了一線運維人員的部分心血，所以當spinnaker進行deploy版本迭代的時候一定要保證把這部分繼承過來，否則表面上看起來版本發佈成功，但是已經失去了彈性的特性。
6 臨時實例清理機制
Spinnaker是通過packer的方式來做bake的，正常運行中不會有問題，但是總會有些特殊情況會導致臨時實例刪不掉造成經濟上的浪費。
我目前能總結出來的場景有：1，bake過程中rosco異常 2，雲平臺申請不到bake所需要的實例 3 雲平臺內部錯誤導致鏡像製作超時。
所以我們需要一個至少以每天爲週期的掃描機制去雲平臺查詢有沒有packer沒有釋放掉的資源，在bake是給這些臨時實例規定命名規則或者標註tag，然後交給serverless定期去清理它們。
7 自定義鏡像一定要最小化
Bake用的基礎鏡像越小，基於這個基礎鏡像製作出的業務鏡像也就越小，從時間成本上講bake一次時間越短，從經濟成本上講，bake一次自定義鏡像佔用的磁盤越小，越省錢。我每次拿到200G甚至300G的鏡像時總是一臉茫然，當我去詢問爲什麼這些鏡像要做的這麼大的時候答案也是讓我哭笑不得。因爲有些業務場景必須把一部分內容落到本地，然後定期再從本地拿走，當訪問量特別高時就會佔用很高的磁盤空間。但是他們搞混了一個概念，鏡像大小和實例大小是不一樣的，我們可以拿50G的鏡像開出300G的實例，但是用300G的鏡像缺開不出50G的實例，所以鏡像一定是做的越小越好。
8 高併發前要把LB做散列
核心的LB列表需要提供給雲廠商讓他們後端幫我們做好散列，否則你的LB在雲後端都在一臺機器上也會有能力不足或單點故障的風險。
9 Spinnaker自身的調優
9.1 Redis擴容
Spinnake定期採集雲平臺資源緩存到redis，deck看到的資源都是redis中的信息，所以當跨年晚會這種高流量場景下我們擴展了機器後也需要關注spinnaker的redis能否支撐這麼多機器。
9.2 可以關閉Rosco
Rosco是負責做bake鏡像的微服務，但重大活動前往往會對軟件封版，所以我們可以關閉rosco爲其它微服務騰出足夠的硬件資源。
9.3 CloudDriver JVM調優
CloudDriver是調度和採集雲平臺資源的核心微服務，所以需要關注下它的服務能力能否足夠監控這麼多資源。