雖然公司已經從大單體切換為微服務化有一定的年頭了，但一些細節方面的處理總會有不同的人有不同的看法，這其中一個討論點，就是 Proto 這個 IDL 的程式碼到底放在哪裡？
目前來看，一共有如下方案， 我們一起來探討一下 Proto 的儲存方式和對應帶來的優缺點。
方案一：存放在程式碼倉庫
直接將專案所依賴到的所有 Proto 檔案都存放在 proto/ 目錄下，不經過開發工具的自動拉取和釋出：
缺點
- 專案所有依賴的 Proto 都儲存在程式碼倉庫下，因此所有依賴 Proto 都需要人工的向其它業務組 “要” 來，再放到
proto/目錄下，人工介入極度麻煩。 - Proto 升級和變更，經常要重複第一步，溝通成本高。
優點
- 專案所有依賴的 Proto 都儲存在程式碼倉庫下，因此不涉及個人開倉庫許可權的問題。
- 多 Proto 的切換開銷減少，因為都在程式碼倉庫下，不需要看這看那。
方案二：獨立倉庫
獨立倉庫儲存是我們最早採取的方式，也就是每個服務對應配套一個 Proto 倉庫：
這個方案的好處就是可以獨立管理所有 Proto 倉庫，並且許可權劃分清晰。但最大的優點也是最大的缺點，因為一個服務會依賴多個 Proto 倉庫，並且存在跨業務組呼叫的情況：
如上圖所示，svc-user 服務分別依賴了三塊 Proto 倉庫，分別是自己組的、業務組 A、業務組 B 總共的 6 個 Proto 倉庫。
缺點
- 假設你是一個新入職的開發人員，那麼你就需要找不同的業務組申請不同的倉庫許可權，非常麻煩。如果沒有批量賦權工具，也沒有管理者許可權，那麼就需要一個個賦權，非常麻煩。
- 在執行服務的時候，你需要將所有相關聯的 Proto 倉庫拉取下來，如果沒有工具做半自動化的支援，麻煩程度無法忍受。
優點
- 使得安全性較高（但 IDL 本身沒有太多的祕密）。
- 按需拉取，不需要關注其餘的服務 Proto。
方案三：集中倉庫
集中倉庫也是一些公司考慮的方式之一，是按公司或大事業部的維度進行 Proto 程式碼的儲存，這樣子只需要拉取一個倉庫，就可以獲取到所有所需的 IDL：
缺點
- 安全性下降，因為其它業務組的 IDL 也全都 “洩露” 了。
- 非按需拉取，在檢視原始檔案時，需要關注一些多餘的。
優點
- 只需要拉取一次 Proto 倉庫就可以輕鬆把一個服務所需的 IDL 集齊。
- 倉庫許可權管理的複雜度下降。
方案四：映象倉庫
結合上面幾種方案的特點，我們也可以得出映象倉庫的方式，也就是自己服務的 Proto 檔案存放在程式碼倉庫的 proto 檔案中，在本次 feature 提交或釋出後，自動同步到映象倉庫去。
而你所依賴的其他服務 Proto 則直接通過讀取集中的映象倉庫的方式獲取：
這樣子的話，通過開發工具的配合，開發人員在開發時就只需要關注自己專案的 Proto，集中的映象倉庫用於構建和部署時就可以了，大幅度降低了多 Proto 的關注和切換開銷。
方案五：其他
本質上上述的所有方案多多少少都有一些利弊存在，並且都需要開發工具來進行支援，否則實操起來還是非常麻煩。
如果想一勞永逸，可以通過雲開發環境來解決，因為在分配雲開發機時，你已經有了身份認證，你能夠擁有什麼許可權，不能擁有什麼許可權，基本都是明確的，並且一般在組內、跨組聯調時，也可以直接排程，不需要像其它方案那樣進行過多的關注，甚至在自己本地執行一套微服務。
但這需要大量的工具/資源支援。
小結
在本文中我介紹了比較常見的 5 種 Proto 程式碼的管理方式，其各有利弊，不同公司不同人的理解或適配度都不一樣，大家可以根據實際環境進行選用，並且建議拉上核心的人員進行討論和選型，因為 Proto 程式碼涉略面還是比較廣的，多多少少都有人有不一樣的看法。