微服務與單體的區別

如果單體應用是一個人啥都幹，那微服務體系更像是一個團隊。相對於一個人大包大攬，一個團隊中每個人分工合作顯然對於整體來說是更輕鬆的，彈性也更強，但是團隊相對於個人研發無疑增加了溝通成本，也就是信息共享（數據共享）

數據共享的問題在哪

數據共享的問題，就如同大家都會講普通話，那大家就都用普通話溝通，但是不能前端頁面問題找 DBA 處理，這時候我們就需要統一各個成員之間的依賴關係，比如 A 前端關於樣式方面的問題需要找 B 設計師，C 後端關於數據庫方面的問題需要找 DBA，這也就是微服務間數據依賴關係的問題，服務與服務之前相互依賴構成一套微服務系統，服務獨立管理自己的職責，從而達到 <協同工作，小而自治>

在精簡的團隊裏，通常我支持每個成員單獨負責一個微服務模塊的開發，從而在團隊和架構層面都達到分而自治，然後在代碼走查階段互相閱讀‘找茬’，提高整體代碼質量同時團隊中成員能夠互相學習。

如何解決依賴關係

對於服務間的依賴通常是單向依賴，比如 A 服務依賴 B 服務的數據，但 B 服務不應該依賴 A 服務的數據，這樣能夠避免服務間關係混亂的問題，有利於問題排查和性能優化。

多個微服務如何依賴

現有三個微服務 A、B、C，其中 A 依賴了 B，B 依賴了 C，如果 B 提供 API 聚合了 C 提供的數據，這時候此 API 不建議直接提供給 A 使用，而應該 A 單獨調用 B 和 C 進行數據聚合。這樣的好處在於避免了層層調用，A 服務可以對 B、C 服務並行調用，性能也會更優。

聚合服務

對面上面 A 服務同時調用 BC 服務數據的情況，如果使用場景較多，這時候可以提供一個接口聚合服務，相當於一箇中間商，中間商將 BC 提供的數據組合後爲 A 提供服務。

HTTP API 通信

就像瀏覽器與服務器一樣，微服務兩兩之間也服務與客戶關係，而且兩兩之間應該一直是這種關係

微服務一方面爲客戶端提供 API 服務，也爲其它微服務提供 API 服務，所以在 API 設計要考慮到 2C API 與提供給微服務的 API 之間參數與返回值上的區別，通常返回給客戶端的 API 我們進行了包裝，包含了數據、狀態、錯誤信息等等，但是對於微服務之間的 API，直接一點更好，是列表就返回列表, 是對象就是對象，調用方只需考慮異常即可，而不用去考慮太 多了參數校驗等等問題。

對於服務與服務之間，是一種信任的關係，調用方更多考慮被服務方是否會出問題，而服務方更多是信任調用方是可靠的（約定大約限制），簡化調用方傳參及返回值結構；對於服務與客戶端之間的關係，更多是一種不信任的關係，我們要考慮客戶中有壞人，對參數進行嚴格校驗、對異常操作給出警告（錯誤信息）。

Redis 大緩存

對於微服務系統，通常有一個基礎系統（base-data），其它微服務依賴於此係統管理的基礎數據，如用戶的基礎信息，在微服務搭建的初期要將此類基礎數據劃分出來進行基礎管理。基礎系統管理大緩存，進行數據同步，其它微服務都依賴此緩存進行業務聚合。

小結

微服務相對於一體服務，數據共享與通信是關乎微服務性能及可靠性的問題，我們在服務設計階段要儘量簡化關係，高度抽取，服務能少則少的原則。

以上內容純屬個人在微服務開發體系下的一些理解與總結，如有誤區請指出，如果有補充歡迎在評論區交流。

作者：熱黃油啤酒

來源：https://juejin.cn/post/7070418676754677768

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