老闆覺得冷，服務如何縮容？

原創：小姐姐味道（微信公眾號ID：xjjdog），歡迎分享，轉載請保留出處。

大環境穩中向好，公司卻不行了。為什麼？肯定是自己的問題，這怪不得別人。在任老闆緊裹大襖的今天，我們也沒必要穿著秋褲耍帥，保暖措施是一定要跟上的。

這些保暖方案，除了要降本增效把可憐的勞動者變成靈活勞動者，原則上我們還可以對服務執行的寄主，這就是躺在機房裡的那些硬體採取一些措施。

假如CPU一直沒跑滿，我們就要想著讓它一直極限執行；如果磁碟富餘，那可以使用MinIO再在上面搭建一套檔案系統；JVM的記憶體分配也要省著點，方便以後進行混合部署...

如果老闆覺得很冷，作為員工xjjdog絕對不可以眼睜睜看他凍死。這樣的措施很多，我們要出方案，找抓手，真正的落實下去。

搭建監控系統

想要知道每個部件的溫度，看這些硬體有沒有偷懶，有沒有瞞報誤報，我們需要搭建一套完整的監控系統來對這些硬體進行監控，它們絕對逃不出我們的五指山。

傳統的資源是CPU、記憶體、網路、I/O，當然我們也可以擴大一點，把更上層的軟體勞動者也囊括進來，包括資料庫、MQ、SLB等諸多元件。

這套系統可以採用佔用資源較少的元件，比如Telegraf進行指標指標，Prometheus進行指標儲存，只儲存1天的時間。至於展示，一個Grafana就可以滿足需求，我們可以直接使用潛入的sqlite來儲存監控面板。至於報警，不要再發郵件、發簡訊了，花錢。我們人工去盯就可以了。

抓資料也要平衡花費，不能在保暖的步伐中首先凍死了自己。抓取的間隔可以調高到30s或者1min；引數也要調整好，像CPU利用率，我們只抓總的就好了，沒必要抓取單核的。

覺得冷一般是一個整體覺得冷，抓單核CPU不符合平均主義的精神。有了監控系統，我們就相當於有了抓手，這措施就有一定的針對性，在縮容的程序中就多了一些掌控度。

去容器化

容器很好，但有成本。無論Namespace隔離的再好，總有執行成本。再加上k8s的維護人員，映象的儲存倉庫，所謂的雲原生等一系列Proxy，在公司勢必會造成大的浪費。

先別再研究什麼ServiceMesh了，我們先把容器去掉。

對於Java來說，WAR包、JAR包，都是比較好的執行方式。對於其他語言來說，二進位制也很好，不用再用Docker包上一層。

使用Jenkins來替代Rancher或者採購的k8s系統，可以省下一部分授權費用，而且服務執行的更清爽。順便，也可以把k8s團隊整個給優化掉，因為他們在縮容的環境中根本不是那麼重要，反而是公司的累贅。

xjjdog在十幾年前，一個Tomcat，一個ssh遠端命令列，服務就能執行的很好。縱觀這些年，容器化發展縱然迅速，但公司的業務卻每況愈下。這證明了先進的技術並不能助力業務的發展。

夠用就好。有時候追求潮流反而尾大不掉，企業有縮容的需求，去容器化就是必須要實行的。

去微服務化

接下來，我們要把公司的業務進行單體化。把原來拆的七零八落的微服務模組給合併起來。

公司下行，業務也變的穩定，微服務的魔力已經一去不復返，是時候把它們放在一個Idea專案中來運行了。

ERP、CRM、Shop、Front？沒有什麼不是一個獨立的git專案不能管理的。相對於RPC這些耗時的呼叫，直接方法內呼叫會節省下大量的硬體。流量的節省，機器的節省，這都是微服務不能比擬的。

微服務到單體的改造，我們要從下游開始，逐步向上游靠攏。原來是RPC呼叫，現在我們只需要把它封裝成一個jar包，然後讓業務進行整合就好了。

這個過程可能是痛苦的，但一旦完成了改造，什麼註冊中心、日誌手收集、熔斷、分散式鎖等元件，都可以說bye了。

公司沒業務，與其讓開發人員在那裡閒著沒事做，不如加加班，把微服務改造成單體。這部分省下來的錢，換量新車，再不濟出去旅個遊，不爽麼？

其實，把微服務做成單體，還可以降低遷移成本。這個我們接下來說。

去雲化

千萬不要買什麼雲上的產品，比如RDS或者MQ或者什麼Log服務，這些開源元件都是現成的，雲服務商簡單的包裝了一層就拿來賣錢。它們的棉襖倒是厚了，作為企業我們都沒有褲頭穿。

這不能忍。

要用雲服務，也就簡單的買裸機就好。就買那種大容量的，大cpu大記憶體。如果一臺機器的利用率沒有漲上去，我們就可以再在上面新增一些服務，就是這麼簡單。

隨著業務的訪問量越來越少，這些大容量的機器可以越來越少。這是後話，我們首先要幹掉的就是雲產品。

像MySQL，你搞那麼多例項幹什麼？通過開不同的賬號，我們可以讓所有的系統使用同一個MySQL例項。這樣備份都好做，只需要掛上個從機，或者定期拉一下Binlog就好了。

像MQ、快取，各種系統，沒有什麼不是不能共用的。你買了雲廠商十幾二十個例項，結果發現最後搭建一個就滿足需求了，何苦花這個錢、費這個勁，來滿足一個半死不活的業務呢？

完成混合部署

很多年前，混合部署還是一種潮流。容器出來之後，混合部署就逐漸落於下成。主要是混合部署，服務之間會相互影響，也無法進行資源隔離。

但今日不同往昔了兄弟們，公司幾百個服務的執行情況，已經是可以預見的處於那種水平，再也不可能來個10倍流量，百倍秒殺這樣的場景了。

把這些可憐的小傢伙們部署在一塊，是必然的選擇。況且，經過我們的單體化改造，微服務已經沒有了，這些服務數量上必然是可控的。為了讓實施速度快一點，我們也推薦買大容量的CPU、記憶體等，這樣也方面我們日後調整。

資源調整

當這一切完成之後，你會發現，縮容竟然也是這麼的美妙。人變少了，團隊好管理；機器變少了，掌控力就變強。有些公司，在進行這些非常Nice的改造之後，會發現一臺16C32G的機器，就能夠Hold住公司的所有業務了。

但16C32G也是錢啊，而且每個月都付，我們的縮容還沒到極致。這時候監控系統的作用必須要體現。

如果某臺機器的CPU一直處於低水位執行，說明你的服務排程是不合格的，你需要調整每臺機器上部署的服務的情況。這通常是拷貝一下程式，修改一下Ng的配置檔案就能完成的事。

JVM的記憶體監控也要走起來，除了堆，像什麼MetaSpace、堆外記憶體也要控制起來，夠用就好。如果你擔心一些突發情況把程序搞Down了，那麼可以使用systemctl做個自動重啟。相信對於技術高超的你來說，這都不是問題。

其他

當然，上面的縮容都是一些指導思想。我們的目標就是降低機器使用的數量。像效能優化、日誌縮減這些就不多談了，因為它們對技術要求比較高。

另外，任何花錢的地方，都可以讓它不花錢。就拿HTTPS來說啊，證書要花錢，沒必要讓使用者的資料走什麼安全通道。況且現在移動端訪問誰也看不出到底是不是HTTPS，證書這種東西能去掉就去掉吧，沒人在乎。

高可用建設的這一塊，從DNS到元件的主從，甚至某些服務的負載均衡。只要能處理業務，也沒必要為了這些幾乎永遠看不到的風險點花這些冤枉錢。

退一萬步講，假如縮容之後，我們的公司還是很冷，活不了幾天。我們還可以把這些單體應用開源出去，做點教程賣錢。

單體應用，用滑鼠點吧點吧就能跑，學生、老闆和培訓機構們最喜歡了。

作者簡介： 小姐姐味道 (xjjdog)，一個不允許程式設計師走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎新增好友，進一步交流。