真是頭疼，Proto 代碼到底放哪裏？

大家好，我是煎魚。

雖然我朋友他們已經從大單體切換爲微服務化有一定的年頭了，但一些細節方面的處理總會有不同的人有不同的看法。

而且時不時就會有人出來反覆問，這其中的一個重要討論點，就是 Proto 這個 IDL 的代碼到底放在哪裏？

實施方案

經過多輪討論對 Proto 的存儲方式和對應帶來的優缺點。

一共有如下幾種方案：

方案一：存放在代碼倉庫

直接將項目所依賴到的所有 Proto 文件都存放在 proto/ 目錄下，不經過開發工具的自動拉取和發佈：

缺點

  1. 項目所有依賴的 Proto 都存儲在代碼倉庫下，因此所有依賴 Proto 都需要人工的向其它業務組 “要” 來，再放到 proto/ 目錄下，人工介入極度麻煩。

  2. Proto 升級和變更，經常要重複第一步，溝通成本高。

優點

  1. 項目所有依賴的 Proto 都存儲在代碼倉庫下，因此不涉及個人開倉庫權限的問題。

  2. 多 Proto 的切換開銷減少，因爲都在代碼倉庫下，不需要看這看那。

方案二：獨立倉庫

獨立倉庫存儲是我們最早採取的方式，也就是每個服務對應配套一個 Proto 倉庫：

這個方案的好處就是可以獨立管理所有 Proto 倉庫，並且權限劃分清晰。但最大的優點也是最大的缺點。

因爲一個服務會依賴多個 Proto 倉庫，並且存在跨業務組調用的情況：

如上圖所示，svc-user 服務分別依賴了三塊 Proto 倉庫，分別是自己組的、業務組 A、業務組 B 總共的 6 個 Proto 倉庫。

缺點

  1. 假設你是一個新入職的開發人員，那麼你就需要找不同的業務組申請不同的倉庫權限，非常麻煩。如果沒有批量賦權工具，也沒有管理者權限，那麼就需要一個個賦權，非常麻煩。

  2. 在運行服務的時候，你需要將所有相關聯的 Proto 倉庫拉取下來，如果沒有工具做半自動化的支持，麻煩程度無法忍受。

優點

  1. 使得安全性較高（但 IDL 本身沒有太多的祕密）。

  2. 按需拉取，不需要關注其餘的服務 Proto。

方案三：集中倉庫

集中倉庫也是一些公司考慮的方式之一，是按公司或大事業部的維度進行 Proto 代碼的存儲。

這樣子只需要拉取一個倉庫，就可以獲取到所有所需的 IDL：

缺點

  1. 安全性下降，因爲其它業務組的 IDL 也全都 “泄露” 了。

  2. 非按需拉取，在查看原始文件時，需要關注一些多餘的。

優點

  1. 只需要拉取一次 Proto 倉庫就可以輕鬆把一個服務所需的 IDL 集齊。

  2. 倉庫權限管理的複雜度下降。

方案四：鏡像倉庫

結合上面幾種方案的特點，我們也可以得出鏡像倉庫的方式。

也就是自己服務的 Proto 文件存放在代碼倉庫的 proto 文件中，在本次 feature 提交或發佈後，自動同步到鏡像倉庫去。

你所依賴的其他服務 Proto 則直接通過讀取集中的鏡像倉庫的方式獲取：

這樣子的話，通過開發工具的配合，開發人員在開發時就只需要關注自己項目的 Proto 就好了。

集中的鏡像倉庫主要用於構建和部署，大幅度降低了多 Proto 的關注和切換開銷。

方案五：其他

本質上上述的所有方案多多少少都有一些利弊存在，並且都需要開發工具來進行支持，否則實操起來還是非常麻煩。

如果想一勞永逸，可以通過雲開發環境來解決，因爲在分配雲開發機時，你已經有了身份認證，你能夠擁有什麼權限，不能擁有什麼權限，基本都是明確的。

所以一般在組內、跨組聯調時，也可以直接調度，不需要像其它方案那樣進行過多的關注，甚至在自己本地運行一套微服務。

這需要大量的工具 / 資源支持，也需要研發有一定規模才能做。

小結

在本文中我介紹了比較常見的 5 種 Proto 代碼的管理方式，其各有利弊，不同公司不同人的理解或適配度都不一樣。

大家可以根據實際環境進行選用，並且建議拉上核心的人員進行討論和選型，因爲 Proto 代碼涉略面還是比較廣的，多多少少都有人有不一樣的看法。

關注煎魚，獲取業內第一手消息和知識 👇

你好，我是煎魚，出版過 Go 暢銷書《Go 語言編程之旅》，再到獲得 GOP（Go 領域最有觀點專家）榮譽，點擊藍字查看我的出書之路。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/cBXZjg_R8MLFDJyFtpjVVQ

猜你喜歡