你好，哈布爾！ 我提請您注意 作者對文章的翻譯 .
在IT世界逐漸走向微服務和像Kubernetes這樣的工具的時候，只有一個問題變得越來越引人注目。 這個問題 - 微服務版本。 儘管如此，IT界認為目前的情況比 上一代技術。 然而，微服務的版本控制是一個非常複雜的問題。 類似的文章可以證明這一點 .
如果您在閱讀本文後仍然不明白問題，讓我解釋一下。 假設您的產品由 10 個微服務組成。 現在，我們假設每個微服務都發布了 1 個新版本。 只有一個版本 - 我希望我們都能同意這是一個非常瑣碎且微不足道的事實。 然而現在，讓我們再看看我們的產品。 每個組件只有一個新版本，我們現在就有 1^2 或 10 種產品組合方式的排列。
如果還有什麼誤解的話，讓我來分解數學。 因此，我們有 10 個微服務，每個微服務接收一個更新。 也就是說，我們為每個微服務提供 2 個可能的版本（舊的或新的）。 現在，對於每個產品組件，我們可以使用這兩個版本中的任何一個。 從數學上來說，這就像我們有一個 10 位元二進位數一樣。 例如，假設 1 是新版本，0 是舊版本 - 那麼一種可能的排列可以表示為 1001000000 - 其中第 1 和第 4 個元件被更新，而所有其他元件則沒有更新。 從數學中我們知道一個10位元二進位數可以有2^10或1024個值。 也就是說，我們已經確認了我們正在處理的數字的規模。
讓我們繼續進一步推理 - 如果我們有 100 個微服務，每個微服務有 10 個可能的版本，會發生什麼？ 整個情況變得非常不愉快——我們現在有 10^100 種排列——這是一個巨大的數字。 不過，我比較喜歡這樣稱呼這種情況，因為現在我們不再躲在「kubernetes」這樣的字眼後面，而是面對問題本身。
為什麼我對這個問題如此著迷？ 部分原因是，我們之前在 NLP 和 AI 領域工作過，大約 5-6 年前我們就多次討論了組合爆炸問題。 只是我們用單獨的單字取代了版本，用句子和段落取代了產品。 儘管 NLP 和 AI 的問題在很大程度上仍未解決，但必須承認在過去幾年中已經取得了重大進展 （我認為，可以取得進展о如果業內人士少一點對機器學習的關注，多一點關注其他技術，那就更好了——但這已經是題外話了）。
讓我們回到 DevOps 和微服務的世界。 我們面臨著一個巨大的問題，偽裝成 Kunstkamera 中的大象 - 因為我經常聽到的是“只要掌握 Kubernetes 並掌舵，一切都會好起來的！” 但不，如果一切都保持原樣，一切都不會好起來的。 此外，由於其複雜性，此問題的解析解似乎不可接受。 與 NLP 一樣，我們首先應該透過縮小搜尋範圍來解決這個問題——在本例中，是透過消除過時的排列。
可能有幫助的事情之一是我去年寫的 。 同樣重要的是要注意，精心設計的 CI/CD 流程極大地有助於減少變更。 然而，如果沒有額外的記帳和追蹤組件工具，CI/CD 的當前狀況還不足以解決排列問題。
我們需要的是整合階段的實驗系統，我們可以在其中確定每個組件的風險因素，並且還有一個自動流程來更新各種組件並進行測試，無需操作員幹預 - 看看哪些有效，哪些無效。
這樣的實驗系統可能如下圖所示：
- 開發人員編寫測試（這是一個關鍵階段 - 因為否則我們沒有評估標準 - 這就像機器學習中的標籤資料）。
- 每個組件（項目）都有自己的 CI 系統 - 這個過程現在已經很完善，為單個組件創建 CI 系統的問題已基本解決
- 「智慧整合系統」收集各種CI系統的結果，將組件專案組裝成最終產品，運行測試，最終根據現有組件和風險因素計算獲得所需產品功能的最短路徑。 如果無法更新，系統會通知開發人員現有元件以及其中哪些元件導致了錯誤。 再次強調，測試系統在這裡至關重要——因為整合系統使用測試作為評估標準。
- CD系統接收來自智慧整合系統的資料並直接執行更新。 該階段結束循環。
總而言之，對我來說，現在最大的問題之一是缺乏這樣一個“智慧整合系統”，它將各種組件連接到一個產品中，從而使您能夠追蹤整個產品是如何組合在一起的。 我會對社區對此的想法感興趣（劇透 - 我目前正在開發一個項目 ，可以成為這樣一個智慧整合系統）。
我想提的最後一件事是，對我來說，對於任何中等規模的項目來說，單體都是不可接受的。 對我來說，嘗試透過返回整體來加快實施時間和開發品質會引起很大的懷疑。 首先，單體應用在管理元件方面也有類似的問題——在它所包含的各種庫中，然而，所有這些並不是那麼引人注目，並且主要體現在開發人員所花費的時間上。 整體問題的後果是幾乎不可能對程式碼進行更改，並且開發速度極其緩慢。
微服務改善了這種情況，但隨後微服務架構在整合階段面臨組合爆炸的問題。 是的，總的來說，我們已經把同樣的問題從開發階段轉移到了整合階段。 然而，在我看來，微服務方法仍然會帶來更好的結果，團隊更快地實現結果（可能主要是由於開發單元規模的縮小——或者 批量大小）。 然而，從單體架構轉向微服務還不足以改善流程——微服務版本的組合爆炸是一個巨大的問題，當我們解決這個問題時，我們有很大的潛力來改善這種情況。
來源： www.habr.com