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

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

假如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。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。