SpringCloud核心問題

在微服務架構中一個非常棘手的問題是：一個實體類在不同系統中是否唯一？

方案一

• 一個實體類在多個系統中存在

  • 優點：
          這樣可以極大的降低程序之間通訊的頻率

  • 缺點：
          每次更新資料結構都需要在所有引用了被更新欄位的程式中進行更新，這會造成一個專案的更新引發多個專案都需要全部重啟。當然，如果更新的表字段不影響當前程序的業務，可以先更新專案（開發測試環境）中的實體類，待下次系統上線再一併更新線上系統。再者，這種方案在專案體積日益龐大必須分庫時，需在各個系統中從底層分解，帶來的工作量的巨大且完全沒有必要的。

方案二

• 一個實體類在多個系統中唯一，在客戶端建立VO接收來自服務端的物件

  • 優點：
          如果更新的欄位影響當前程序的業務，只需要更新客戶端的VO及唯一的服務端實體類，如果更新的欄位不影響當前程序的業務，則只需更新唯一的服務端實體類。且不影響分庫

  • 缺點：
          增加程序之間通訊的頻率，增加團隊之間協作的成本

總結

      筆者認為，以上方案一是不可取的，對專案維護極其不利。方案二雖然增加了通訊的開銷，也增加了團隊質檢的協作成本，但能用得起這種大型架構的公司其資料量和規模可想而知，也是各大廠在使用的方案。