話題背景

在軟件開發(fā)領(lǐng)域，代碼倉庫的管理方式對項(xiàng)目的效率和協(xié)作有著重要影響。

隨著項(xiàng)目結(jié)構(gòu)的日益復(fù)雜和開發(fā)挑戰(zhàn)的不斷增長，傳統(tǒng)的單一代碼庫（Monolith）在應(yīng)對多項(xiàng)目、多庫和多服務(wù)的情況下顯得力不從心，正是在這個(gè)背景下，Monorepo（微服務(wù)大倉）和Multirepo（微服務(wù)多倉）的概念應(yīng)運(yùn)而生。

你怎么看待大小倉之爭？

今天就讓我們來一起聊聊“為什么要用大倉，monorepo比multirepo好在哪里？”

鵝廠工程師的看法

@cheater-CSIG模型開發(fā)組長▼

我寫過一篇文章《單一大倉實(shí)踐與工業(yè)化》。里面講到大倉主要好處是：

• 能在同一個(gè)地方建設(shè)輔助開發(fā)者的工具
• 保證開發(fā)者對整個(gè)項(xiàng)目的可見性，易于獲取性
• 能批量集中地修復(fù)任何一類工程問題。

有人說，他們用了monorepo，實(shí)際上是一個(gè)超級大shi山。但是，同樣是shi山，集中在一起，就比散落在很多地方的無數(shù)小shi堆，治理起來要容易一些。在monorepo下，我們能評估治理的工作量，如果是無數(shù)小shi堆兒，根本就沒法治理了。

@tide-CSIG后臺開發(fā)工程師▼

個(gè)人感覺，monorepo是面向管理者的，是為了簡化項(xiàng)目管理者的管理難度，增加對開發(fā)過程的控制力度的工具。

有些一體性強(qiáng)的超大單體應(yīng)用可能還比較適合，但是對于一個(gè)追求靈活、快速迭代的分布式系統(tǒng)強(qiáng)行使用就是災(zāi)難。

@thom-PCG后臺開發(fā)工程師▼

分布式和集中式類似的區(qū)別，集中在一個(gè)點(diǎn)做好 ，程序員對代碼有理想的追求是值得肯定的，另外上面的都想一次性就做好，每次都更新到最好的版本，最好的代碼，所以可能傾向選擇monorepo。

但是一般理想很美好。顯示很骨感， 通常我們可能都在快速迭代，尋找新的業(yè)務(wù)增長點(diǎn)，這個(gè)時(shí)候

multirepo容錯(cuò)性更好，迭代更快各有優(yōu)劣～開發(fā)好了，就可以一直不改，不動(dòng)了。

結(jié)論：multirepo和monorepo都是工具，作為工程師把工程做好，業(yè)務(wù)做好才是王道，誰優(yōu)誰劣都要根據(jù)一定的應(yīng)用場景

@les-CSIG后臺開發(fā)工程師▼

換一個(gè)角度，多倉庫 + 倉庫多版本，倉庫之間又常常存在依賴關(guān)系，這可以將多倉管理規(guī)約到依賴管理問題上，而后者又可以規(guī)約為3-sat問題，眾所周知，這是NPC問題… 

也就是說，帶有多版本的multirepo，使用者容易陷入版本泥潭，腦容量不夠用… 而規(guī)避這個(gè)由管理模式導(dǎo)致的依賴管理問題，一個(gè)簡單直接的方式：只用一個(gè)倉庫??

@lucasz-WXG前端開發(fā)工程師▼

大倉可能是一種重構(gòu)后的選擇，也可能是一開始的選型方案，因?yàn)闃I(yè)務(wù)下的項(xiàng)目呈現(xiàn)是動(dòng)態(tài)的。

主要優(yōu)勢是能夠更低成本統(tǒng)一和維護(hù) 多應(yīng)用的工程化方案，當(dāng)然也會帶來工程復(fù)雜度的上升。因此判斷條件無非是收益和成本的權(quán)衡，以下是可以去考量的幾個(gè)點(diǎn)：

• 人員在多個(gè)單倉來回開發(fā)的上下文差異，導(dǎo)致切換倉庫開發(fā)的成本越高，大倉收益越高
• 工程化方案的中配置即代碼的部分占比越大，即工程通過代碼復(fù)用，大倉收益就更高
• 復(fù)用更統(tǒng)一先進(jìn)的工程化方案的收益 VS 分散開獨(dú)立支撐業(yè)務(wù)小步快跑獨(dú)立性的收益
• 分散的單倉間工程化統(tǒng)一的難度 VS 集中力量應(yīng)對工程復(fù)雜度提升的難度

@folger-CSIG前端開發(fā)▼

大倉擔(dān)心CI，試試CNB，現(xiàn)在在公測中～

@jom-PCG客戶端開發(fā)▼

大倉（Monorepo）與多倉（Multirepo）有各自的優(yōu)缺點(diǎn)，兩者往往可以互補(bǔ)，具體選擇哪個(gè)取決于項(xiàng)目的規(guī)模、具體需求、以及團(tuán)隊(duì)的分布，從Monorepo的優(yōu)缺點(diǎn)來講：

優(yōu)勢：

• 復(fù)用工程化基建：可以統(tǒng)一工程化配置和DevOps流程，包括但不限于Lint規(guī)則、構(gòu)建腳本、測試、CICD流程等，基建的事情只需要做一遍，包括后續(xù)統(tǒng)一改造和升級，從而降低多項(xiàng)目維護(hù)成本。
•  利于代碼復(fù)用：由于所有代碼都在一個(gè)倉庫內(nèi)，依賴的管理可以更加簡化和一致（本地npm包，自動(dòng)解決依賴關(guān)系），依賴的安裝也更高效（共同依賴只會安裝一次）。這樣帶來的好處就是極大降低代碼復(fù)用成本，比如需要抽離新的「復(fù)用代碼」，創(chuàng)建個(gè)npm模塊子項(xiàng)目就能直接進(jìn)行開發(fā)、調(diào)試，而如果是Multirepo，需要手動(dòng)進(jìn)行npm link或者npm發(fā)布，還要手動(dòng)處理依賴關(guān)系，后續(xù)的版本升級也比較繁瑣，久而久之，就會降低大家做此類抽離工作的積極性。
• 版本控制更統(tǒng)一：各個(gè)項(xiàng)目和模塊可以更容易保持版本的一致性，所有的依賴關(guān)系和代碼變更可以在同一個(gè)提交中進(jìn)行更新，能確保整個(gè)代碼庫的一致性，這樣也更利于做跨項(xiàng)目的自動(dòng)化工作流。
• 團(tuán)隊(duì)協(xié)作更簡單：代碼的可見性高，有助于跨團(tuán)隊(duì)的知識共享和代碼審查，同時(shí)團(tuán)隊(duì)成員之間的協(xié)作也更加順暢。

不足：

• 規(guī)模和性能問題：隨著項(xiàng)目和代碼量的增長，clone和構(gòu)建的時(shí)間可能會拉長，互相之間的影響也會被放大，任何變更都可能對其他項(xiàng)目產(chǎn)生連鎖反應(yīng)，增加了變更管理的復(fù)雜性，需要更謹(jǐn)慎的規(guī)劃和協(xié)調(diào)。比如A項(xiàng)目修改了BCD都依賴的公共模塊，則需要BCD都經(jīng)過完整的驗(yàn)證才能一起發(fā)布上線，而不是BCD先保留舊版的公共模塊，按照自己的節(jié)奏實(shí)施升級；
• 復(fù)雜度更高：對于小團(tuán)隊(duì)和項(xiàng)目，大倉可能會引入沒必要的復(fù)雜性；
• 工具鏈要求高：對工具和基礎(chǔ)設(shè)施提出了更高要求，需要構(gòu)建和維護(hù)適合大型代碼庫的復(fù)雜工具鏈和基礎(chǔ)設(shè)施。比如使用lerna，rush 或者 Nx 來做Monorepo，要與司內(nèi)各基建平臺打通就不是那么簡單。

綜上，Monorepo可能更適合大型組織或需要緊密協(xié)作的大團(tuán)隊(duì)，而Multirepo則更適合獨(dú)立發(fā)展且相互依賴性較小的項(xiàng)目。

@shugen -CSIG應(yīng)用開發(fā)▼

對基礎(chǔ)依賴的統(tǒng)一管理和升級很舒服，也更方便做底層能力封裝，CI/CD 方便也簡單不少。