Monorepo vs Polyrepo
- 微服務即是應用程式元件分開且獨立地開發與佈署
- 所以該如何在Git上面(這邊就是GitLab)管理這類的程式碼?
- 簡單點狀況就是單一個應用程式對應單一個Git Repository(尤其是Monolith架構下)
- 而微服務會有多個程式專案,會有兩個主要選擇(如下圖):
Monorepo解說:
- 也就是單一個Repository包含了許多個程式專案
- 而如何結構化來放置多個程式專案呢?
- 一個簡單方式就是依據目錄來切分不同的程式專案:
- 讓程式的管理與開發更為容易
- 因為只要一個clone,就拿到所有專案
- 程式異動可以一起追蹤,一起測試,一起release
- 共用程式甚至Library還有IaC基礎設施(Helm Chart,docker-compose…etc)的定義也可以寫在一起
Monorepo的挑戰(缺點):
- 程式專案很緊密的耦合在一起
- 容易地違反某些標準,程式也容易耦合在一起
- 尤其是Junior可能對這個Repo不熟,也許有專案有互相關聯牽扯的部分沒注意到
- 太大包,這個在打包拉Code的時候就會導致變慢了
- 並且多數Pipeline設計只能對應單一個Repo,所以其中單一個程式專案做CICD就會需要額外多寫一些邏輯做拆分
- 要更多邏輯來判斷現在改的是其中哪一包專案,並且要進行測試
- 在某個程式專案調整時導致Main Branch有狀況,則會直接地影響其他為服務專案
- 但是還是有大公司採用這種做法(Ex:Google,Fackbook)
Polyrepo解說:
- 又可以稱多個Repo
- 也是講師比較建議採用的一個!
- 程式都是獨立分開在不同的Repo內
- Clone或其他Git操作都是獨立分開進行
- 不過即便這些Repo都分開,我們還是會希望某些微服務專案間有一定關聯
- 這時候可以仰賴GitLab的Groups建立這些分開Repo的微服務專案的關聯
- 透過GitLab的Groups也能提供良好的Overview!
- 另外也能針對Groups建立共用的Secrets,CI/CD Variables,Runners
- 然後在CI/CD Pipeline方面,也就很單純各自微服務專案分別對應一個Pipeline
Polyrepo的挑戰(缺點):
- 要針對一整個系統做統一的調整(Cross-cutting changes)會比較困難
- 對於統一的設置或統一都有的程式調整變成要一個個微服務專案獨立進行
- 也就是各自Merge,各自PR(GitLab的MR)
- 切換專案也比較麻煩
- 透過一些開發工具要在多個微服務專案搜尋,測試,debug,都顯得困難
- 共用一些外部如基礎設施檔案(k8s元件,Helm manifest,docker-compose...etc)也變困難
所以不管Monorepo或是Polyrepo都有各自的優缺點
在都是多個微服務程式專案情況下抉擇上大概可以簡單如下:
- 較小的微服務專案 →選MONOREPO
- 跨太多團隊或更高的修改程式等的權限管控或更清楚的專案切分,自己管自己的Pipeline等考量→選POLYREPO
後面就會逐一介紹
