雲端計算時代，我們所說的彈性伸縮，彈的到底是什麼？

現在，我們經常聽到的一些高大上的詞彙，比如彈性伸縮、水平擴充套件和自動化擴縮容等等，你能否說一說，這些技術手段的主體是誰，也就是誰的水平擴充套件？彈性伸縮的是什麼？同時，這些名詞之間又有什麼關係呢？

下面我們就從彈性伸縮入手一起來分析討論。

彈性伸縮的主體是誰？

彈性伸縮，一說到這個詞，我們可能很自然地會聯想到資源的彈性伸縮，伺服器的彈性伸縮，容量的彈性伸縮，應用的彈性伸縮以及業務的彈性伸縮等等。我想這些理解都沒有錯誤，但是可以發現，當彈性伸縮這個動詞前面增加了這麼多不同的主語之後，我們一下子就不知道到底該做什麼了。

其實有這樣的困惑很正常。我們在講標準化的時候就提到，做運維和做架構的思路是相通的，我們碰到問題後，一定要找到問題的主體是什麼，通過問題找主體，通過主體的特性制定問題的解決方案。

對於運維，一定要準確識別出日常運維過程中不同的運維物件，然後再進一步去分析這個物件所對應的運維場景是什麼，進而才是針對運維場景的分解和開發。

這裡可以看到，彈性伸縮其實是一個運維場景，但是我們並沒有定義這個場景的主體是誰，所以就會出現上面這些不同的主體。我們來假設以下幾種主體。

• 伺服器的彈性伸縮。針對這個場景，假設業務是執行在私有云或公有云上，那我們只要能夠通過雲平臺的API申請和釋放資源，申請時初始化我們的作業系統，釋放時銷燬資源就可以。不過，在私有云環境下，為了能夠保障彈性，我們必須自己提前採購、上架、裝機、配置然後交付資源，需要大量的準備工作，公有云上就可以省去這些步驟，可以即拿即用。

• 應用的彈性伸縮。這個場景下其實是預設包含第一步的，就是我們首先必須要拿到應用執行的伺服器資源才可以，這一步做到了，下面就是應用的部署、啟動以及服務上線接入流量。

• 業務的彈性伸縮。我們可以再進一步思考，通常一個業務可能會包括多個應用，所以為了保障整個業務容量充足，這個時候擴容單個的應用是沒有意義的，所以這時要做的就是擴容多個應用，但是這裡面就會有一個順序問題，先擴哪個，後擴哪個，哪些又是可以同時擴容而不會影響業務正常執行的，再進一步，業務承載的服務能力提升了，那網路頻寬、快取、DB等等這些基礎設施需不需要也同時擴容呢？

到這裡，這個問題就已經變得非常複雜了，而且已經不僅僅是彈性伸縮這個詞的表面含義所能覆蓋的了，因為這個問題確實很複雜，所以這裡暫時不做詳述。

好了，分析到這裡，我們就可以看到針對不同的運維物件，彈性伸縮這個概念背後的含義是不一樣的，所執行的動作以及制定的方案也是不一樣的。通過上面的分析過程，我們在日常思考和工作開展中應該注意以下兩點。

• 第一，一定是從實際問題出發，找到問題的主體，然後才是針對問題的解決方案。要反覆問自己和團隊，我們解決的問題是什麼？解決的是誰的問題？切記，一定不要拿著解決方案來找問題，甚至是製造問題。

  比如彈性伸縮這個概念，它就是解決方案，而不是問題本身，問題應該是：業務服務能力不足時，如何快速擴容？業務服務能力冗餘時，如何釋放資源，節省成本？按照這個思路來，我們自然就提煉出業務服務能力這個主體，面對的場景是快速的擴縮容，然後針對場景進一步細化和分解。

• 第二，如果問題處於初期，且是發散狀態時，主體可能表現出很多個，這時我們一定要找到最本質的那一個，往往這個主體所涉及的運維場景就包括了其它主體的場景。

  比如上面我們看到的業務的彈性伸縮，就包含了應用和伺服器的彈性伸縮場景，它們只不過是子場景而已。從這個角度出發，我們的思路才能開啟，方案才會全面。不然如果只是聚焦在伺服器、應用、DB、網路等等這些非本質的主體上，提供出來的解決方案肯定也是片面的，而且經常會出現這樣的情況，每個人都只從自己的角度出發說問題，始終無法達成一致。問題的根本還是我們沒有一個共同討論的基礎，結果就是工作沒少做，卻始終沒有解決問題。

彈性伸縮、水平擴充套件和自動化擴縮容，它們之間的關係是什麼？

這個問題，我想已經不言自明瞭，找到它們的主體和要解決的問題，我們就會發現，其實它們之間的含義是一樣的。

總結

今天我們以彈性伸縮為例，討論瞭如何思考問題和分析問題。我們的討論和分析歸結到一點就是：獨立思考和分析的能力很重要，意識也很重要，切忌不可人云亦云隨大流，反而迷失了工作的方向。

現在業界各種技術上的Buzzword（時髦詞）層出不窮，讓人目不暇接，但是仔細觀察和思考，你會發現它們背後常常隱藏著很多共性的特點，一定要抓住它們背後所要解決的問題和本質，這樣也就不會亂花漸欲迷人眼了。

而且通過這樣的分析，我們會更容易發現工作中還需完善的地方，從而引導我們聚焦到實際問題中來，而不是浮於表面，把一些高大上的詞彙掛在嘴邊，卻不見效果。

關於今天我們討論的主題，你還有哪些想法和心得，歡迎你留言與我討論。

精選提問

1. 應用層面，服務要先下線，比如從lvs或nginx負載均衡器上下線，如果是服務化應用，則要從配置中心下線。下線完成，然後再做容器縮容。
   
   

2. 那另一個問題來了，下線的時候有業務咋辦，客戶請求了就沒有響應了啊，不過得重新整理和重試

   先下服務，從負載均衡上或者配置中心摘掉，沒有流量進來了，且預設靜默一段時間，再停服務，再做後面的操作。