老闆覺得冷,服務如何縮容?
原創:小姐姐味道(微信公眾號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,歡迎新增好友,進一步交流。
推薦閱讀:
3. 藍芽如夢
4. 殺機!
- ChatGPT 生態,毀滅人性的一次開源!
- 能夠公司呆下去,靠的是一份迷茫!
- 你在公司混的差,可能和組織架構有關!
- 再搞CRUD,就真的變成廢物獠!
- 來來來,快速擼 Redis 一遍!
- 分庫分表,可能真的要退出歷史舞臺了!
- 讓人噁心的多執行緒程式碼,效能怎麼優化!
- 架構師:比起 404,我們更怕 200!
- 完全使用Linux替換Windows之後,我覺得自己非常愚蠢
- sudo,代表了Linux的絕對霸權!
- 讀懂HikariCP一百行程式碼,多執行緒就是個孫子!
- 看到就是賺到!當 LinkedList 不是列表時,速度快的兔子都追不上!
- 讀懂HikariCP一百行程式碼,多執行緒就是個孫子!
- 老闆覺得冷,服務如何縮容?
- 這些傻白甜的Linux命令,不會有人教你!
- 這些傻白甜的Linux命令,不會有人教你!
- 使用systemd,把服務裝進 Linux 心臟裡~
- 不是所有有才華的人,都想當領導!
- 這些老系統程式碼,怎麼寫的這麼爛?
- 這些老系統程式碼,是豬寫的麼?