Categories
程式開發

微服務——版本組合爆炸!


隨著IT領域向微服務的轉變,以及諸如Kubernetes之類工具的蓬勃發展,一個揮之不去的問題開始慢慢地全面顯露出來。這就是各種微服務版本的組合爆炸(Combinatorial Explosion of versions)。社區的期望是,它至少要比以前的依賴地獄(dependency hell)好一些。但儘管如此,對基於微服務的產品進行版本控制仍然是一個相當困難的問題。為了證明這一點,像《把我的單體應用還給我》這樣的文章會立刻浮現在腦海中。

微服務——版本組合爆炸! 1

組件版本的組合爆炸

讓我來給你解釋一下這是怎麼回事吧。假設我們的產品由10個微服務組成。現在假設每個微服務都有一個新版本。只有一個版本(這是我們都清楚的,這聽起來很微不足道)。現在回過頭來看下我們的產品。每個組件只有一個新版本,那麼我們現在就有2^10種組合,即可以對我們的產品進行1024種排列組合。

如果還沒有完全弄清楚,讓我用數學解釋一下吧。我們有10個微服務,每個都有一個更新。因此,每個微服務都有兩個可能的版本(舊版本或更新後的版本)。現在,對於每個組件,我們可以使用這兩個版本中的任何一個。這相當於一個有10位的二進制數。例如。假設1代表新版本,0代表舊版本,所以,在只更新第1個和第4個組件其他組件無更新的情況下,會得到一個排列1001000000。利用數學,我們知道10位的二進制數有2^10或1024種變化。這正是我們要處理的數字。

現在,繼續我們的思考。假設我們有100個微服務和10個可能的版本,又會怎樣呢?整個事情會變得很糟糕。它將是10^100個排列組合,這是一個很大的數字。對我來說,這樣很好,因為現在我們不是躲在“kubernetes”這樣的字眼後面,而是要面對這個棘手的問題。

為什麼我對這個問題如此著迷呢?部分原因來自NLP/AI領域,我們在5-6年前就已經在積極討論這個領域的組合爆炸問題了。我們只是用不同的詞代替了版本,用句子和段落代替了產品。現在,雖然NLP和AI的問題基本上還沒有解決,但事實上,最近已經取得了實質性的進展(對我來說,如果人們對機器學習不再那麼痴迷,對其他技術考慮得更多一些,進展可能會更快一些,但這是題外話)。

現在,回到容器和微服務的DevOps領域。我們面臨著一個巨大的問題,我經常會聽到:只要使用kubernetes和helm,一切都會好起來的。你猜怎麼著,光靠自己是不行的。更重要的是,封閉式地解決這類問題是行不通的。就像在NLP中一樣,我們首先應該通過限制搜索空間來解決這個問題,即修剪過時的排列。

”修剪過時的排列“對此很有幫助,我去年在這篇“生產中需要維持最小版本跨度”博客中也提到過。此外,值得注意的是,良好的CI/CD過程對修剪變化也有很大的幫助。但是,如果沒有適當的核算、跟踪和工具來處理組件的實際排列,CI/ CD的當前狀態是不夠的。

我們需要更大規模的集成階段實驗,在那裡我們可以建立每個組件的風險因素,通過自動化的過程來升級不同的組件,並在沒有人為乾預的情況下進行測試,看看哪些組件是有效的,哪些是無效的。

所以這個系統應該是這樣的:

  1. 開發人員編寫測試(這一點至關重要,否則就沒有參考點了,它就像是在ML中標記數據一樣)
  2. 每個組件(項目)都有自己定義良好的CI管道,到目前為止,這一過程已經被很好地建立了,每個組件的CI問題基本上已經基本解決了
  3. “智能集成引擎”位於各種CI管道的頂部,將組件項目組裝到最終的產品中,運行測試,並在給定當前組件的情況下找出完成功能所需的最短路徑,併計算風險因素。如果不能進行升級,引擎就會向開發人員發出警告,告訴他們最佳候選對像是什麼以及是哪些地方導致地失敗。同樣,測試也是至關重要的,集成引擎會使用測試作為參考點。
  4. 然後,CD管道從智能集成引擎中提取數據並執行實際的發布。這樣就完成了整個循環流程。

總之,對我來說,目前最大的困難之一是缺少一個集成引擎,該引擎可以將各種組件組合到產品中,從而可以對整個產品的實際工作方式進行適當的跟踪。如果你能提出這方面的想法建議,我會很感激的(劇透下,我目前正在Reliza上開發“智能集成引擎”。 )

最後我想說的是,對我來說,“單體”(monolith)並不是任何大型項目的最終答案。因此,我非常懷疑是否真的有人試圖通過回到“單體”來改善交付週期和交付質量。首先,”單體“在不同庫之間存在類似的依賴管理問題,只是它在很大程度上被隱藏在開發階段了。因此,人們無法真正地在“單體”上做出任何改變,所以整個過程都會慢如蝸牛。

微服務使事情變得更好了,只是隨後它們在集成階段遭遇了版本控制的爆炸。是的,本質上,我們是將同樣的問題從開發階段轉移到了集成階段。但是,在我看來,它仍然是變得更好的,團隊使用微服務後實際上運行地更快了(可能只是因為批處理的規模更小)。儘管如此,到目前為止,我們通過將“單體”分解為“微服務”所取得的進步還遠遠不夠,組件的版本爆炸是一個巨大的問題,我們還有很大的潛力使事情變得更好。

請鏈接到HN進行討論。

原文鏈接:

Microservices – Combinatorial Explosion of Versions