一、綜述

彈性伸縮是容器雲的一個重要特性，也是實施容器雲的一個重要業務場景，更是容器雲產品的重要賣點。這也是我們非常關注的功能。所以我們一直也在考慮服務彈性伸縮的問題。

目前Kubernetes支援CPU、Memory伸縮策略，但CPU和Memory很多場景並不適合。CPU和Memory的使用情況有時並不能真實反映實際業務的執行情況，而且用他們來擴充套件、收縮容器也顯得武斷，很可能導致沒有完成的業務請求的容器被回收，象我們證券涉及的都是錢、資金，如果在資金處理上出錯將是對客戶的極端不負責任，很容易失去客戶的信任。所以我們在考慮彈性收縮時就考慮的更多。

不過遺憾的是，目前我們接觸的廠商基本上都沒有實現對其他彈性伸縮策略的支援，比如系統吞吐量tps、響應時間response time、併發數量等，有廠商反饋是要跟隨Kubernetes版本的功能，不想維護多套產品，因為社群版本以後會支援更多策略。唉，很讓我無語。在Kubernetes社群版本的基礎上實現擴充套件支援，才能夠與眾不同，才能夠引領設計引領潮流，才能夠贏得客戶，才能有錢賺。總跟在人家屁股後面亦步亦趨，怎麼可能超越別人？

即便是Kubernetes社群版本不支援，擴充套件實現一些策略並不困難，或者至少提供對客戶自定義彈性伸縮策略的支援。只要整個容器雲平臺架構定義合理，並不影響後期Kubernetes新版本的新特性和功能，平臺升級也不會帶來什麼問題，況且，對客戶來說，關心的是應用服務，容器雲只是個工具、基礎載體，工具好用，在運營應用服務時才能得心應手。

我們說服務伸展時相對容易，收縮時就涉及業務，這就要求我們不僅僅考慮容器的回收就行了，也需要考慮在容器回收時是不是會影響到業務？會不會有容器在未處理完業務請求時就會被強制回收？如果出現這種情況該如何處理？是否有更好的方法可以避免這種情況？等等。我們需要一個整體的考慮，不只是容器雲的彈性收縮策略的支援，也包括在業務實現時支援彈性伸縮的架構等考慮。在此也是拋磚引玉，與大家共同探討。

二、彈性伸縮策略擴充套件

服務在實現彈性伸縮時，該選擇什麼樣的伸縮策略，很多時候是需要根據服務的架構和能力來選擇的，基於CPU和記憶體的伸縮策略是最簡單的策略，就象Hello World QuickStart演示程式一樣，基於很多假定，但現實往往這些假定都不成立，這些簡單的演示是不能滿足我們的需求的。

現實的需求複雜，那麼容器雲平臺能不能支援？能是肯定的，實現方式有很多種，但是否有簡單的方法來實現？這就是我們討論的問題。

比如併發數，如果我們有了併發數，那麼就可以使用它作為伸縮的策略，併發數大於某個臨界值，就可以擴充套件容器數量，從而擴充套件服務例項數量；如果低於某個臨界值，就可以按照一定的方式來回收容器，回收資源。這也是我們充分利用資源選擇容器化的初衷。

但併發數從哪裡能夠獲取？怎麼獲取？這也是很多人茫然的問題。我們覺得不能僅僅從容器雲平臺考慮，容器雲平臺最終是要支撐業務服務的，要支撐業務服務，就需要有相應的機制和元件，這就是我們強調的生態，不能割裂開來。所在需要在容器雲平臺搭建支撐業務服務，業務應用的服務化生態能力，比如服務註冊發現、服務日誌管理、服務監控告警、服務API Gateway等。從服務API Gateway是不是可以獲取到併發數、響應時間等？其實在我們看來，在容器雲平臺上對服務化或微服務的生態支援，並不和容器雲的排程管理框架後期對新的彈性策略的支援相悖，可以是並行的。同時也和服務化或微服務的整個設計架構有關係，我們強調不要割裂來看，我們不是玩過家家，我們需要全面考慮適用且實用的完整方案。微服務、容器化、分散式技術等相輔相成，從整體上考慮才能真正便捷的滿足我們的業務實際需求。

容器雲平臺也可以支援使用者自定義彈性伸縮策略，想清楚從哪裡取策略值、怎麼取策略值，實現就相對簡單了。

三、通過API Gateway

API Gateway是服務治理的一個重要元件，我們以後也會詳細討論。這裡我們嘗試通過API Gateway來獲取到我們實現彈性策略需要的併發數、響應時間、吞吐量等資料。另外也基於我們的服務化實施架構，對於涉及的編排的服務、組合服務中不同層次中的服務的伸縮及伸縮策略，做個討論。

我們實施服務化，特別微服務化，通常需要實現一個API Gateway來負責服務請求的認證授權、路由、協議轉換、統計等功能。客戶端的所有請求都首先要經過API Gateway，然後由它將請求路由到合適的服務或微服務。

有了API Gateway，並且所有的請求都會通過API Gateway，那麼我們就有可能獲取到請求數、請求時間、請求處理結果返回時間等，從而計算出系統吞吐量等。有了這些資料，就可以用於服務的彈性伸縮場景。不過很遺憾的是，目前基本上容器雲廠商都沒有考慮到對這點的支援，都不提供API Gateway元件。容器雲只是一個簡單的基礎平臺，並沒有在其之上提供完整的服務或微服務生態支撐。

四、使用JMS Queue

JMS Queue提供了訊息中介軟體層的負載均衡能力。在服務化實現過程中帶給我們很多便利。在內部服務呼叫中，可以採用JMS 介面，基於JMS Queue本身的特性，可以部署多例項來實現服務例項間的負載均衡。同時，JMS Transaction機制和JMS message Acknowledge機制也可以保證事務處理的完整性和滿足訊息處理的效能和可靠性之間達到需求平衡。目前我們在ESB系統中就採用這種方式，通過監控JMS Queue上pending的messages數量，在請求併發數持續增長時，可以部署（自動或手動方式擴充套件，監控可以實現即時告警）更多的服務例項，來均衡和保證服務的處理能力及響應時間。在請求併發數恢復正常，訊息被正常處理之後，可以回收資源，停止部分服務例項。當然這需要業務服務設計中一些機制的協同支援，很難僅靠一種方法滿足這麼多要求。

JMS Queue上待處理的訊息數量可以使用JMS API或者JMS訊息中介軟體工具來取得。通過監控JMS Queue上的待處理訊息數量和大小，來作為是否擴充套件服務例項的一個策略。

我們這裡只是討論彈性伸縮的一種實現方式，JMS Queue上訊息的持續增長，並不一定非要通過擴充套件服務例項來解決。

另外我們需要說明的一點是：服務的整個處理流程各層服務要都具有可擴充套件性，不能有瓶頸，否則無法實現整個服務鏈路的能力擴充套件。比如如果資料庫服務處理能力有限，無論怎麼擴充套件其他服務的處理能力，瓶頸會始終存在於資料庫，整個服務鏈路效能無法提升。

五、自定義策略支援

作為一個平臺產品，很難羅列使用者潛在需要支援的各種彈性擴充套件策略，一個好的方式是提供一種機制，可以讓使用者自定義彈性伸縮策略，就象我們開發軟體時習慣提供幾種通用的模板之外，使用者可以按照自己的實際需求去定義自己的業務流程。那麼怎麼能夠相容使用者的自定義彈性伸縮策略？有了上面的思考，我們知道，首先要明確策略值從哪裡來，然後明確如何和容器雲平臺整合，我們才能使用這些策略值來定義彈性伸縮的條件。

策略值從哪裡來？源應該是多種多樣。象我們提到的資源CPU、Memory使用率、請求數、響應時間、吞吐量；還有累積的待處理訊息量(Pending MSG Count)等其他可能選項。容器雲平臺要想用這些值，它得能夠採集得到，這就是和容器雲集成問題。CPU、Memory最容易採集，所以目前Kubernetes等只支援CPU、Memory策略，其他的怎麼辦？這是我們考慮容器雲產品也關心的問題。

1、容器雲是不是可以提供一個定時回撥機制，具體的彈性伸縮策略在回撥機制中由使用者實現？比如回撥函式。如同對JMS Queue Pending Msg Count，我們可以通過Java 程式碼來連線檢查JMS Queue上的訊息數，這樣就可以在回撥函式中實現，容器雲平臺呼叫此回撥函式，就採集到了JMS Queue上的訊息數。使用此值，就可以在容器雲平臺定義自己的彈性伸縮策略了。

2、或者是否可以實現一種通知接收機制，容器雲平臺接收通知，然後根據定義執行相應的操作（伸展或收縮）。這是一種被動機制。容器雲平臺不需要主動去採集策略值，只是在某項策略值達到臨界值時，能夠接收到此策略值即可。

六、彈性伸縮之收縮

我們談彈性伸縮，往往只是“伸”沒有“縮”。在我們接觸的廠商中，很少考慮到收縮時的問題。我們不能率性的、武斷的把容器停掉就行了，那會影響到實際的業務的。理想很豐滿，現實很骨感。所以我們需要考慮收縮時怎麼做才能保證被收縮的容器不會影響到實際的業務的。

有廠商是按照容器編號來管理的，先建立的容器先回收。這往往是不合適的。容器回收時需要保證容器已經不再接收新的服務請求，並且已經處理完了接收到的所有服務請求。這種情況下容器才可以被回收，實現服務例項收縮。

交流過程中也有廠商提到通過監控來實現，監控容器中服務滿足上面條件，但我們感覺複雜化了。其實也不好操作。

我們的想法是，結合Load Balancer的Load Balance策略，比如權重，來實現。在服務例項伸展時，可以根據實際情況設定不同的權重值。或者提供服務例項權重值實時更改能力，這樣會更好。這樣，在併發量大的情況下，權重低的服務例項也會處理請求；併發量小時，權重低的服務例項就空閒了，可以做回收收縮處理。

還有一種方式是操作Load Balancer，收縮時，先把服務例項從Load Balancer上移除，不讓它接收新的服務處理請求。等它把它所有的請求都處理完之後，空閒情況下，通知容器雲平臺可以回收了。

不同的Load Balancer有不同的策略支援，我們在選擇時可能需要考慮和驗證下。

轉自：http://www.sohu.com/a/215757068_151779