譯者 | 布加迪 

合理設計的微服務應遵循單一職責原則，因此分離應該被架構中的其他服務重用的通用功能很重要。Sidecar模式提倡通過識別每個服務中的通用功能來增強模塊性，將它們組合到庫中，或將它們移到單獨的服務中。

顧名思義，Sidecar模式提倡分離橫切關注點（cross-cutting concern），將橫切關注點從實際服務中移除，推送到單獨的模塊、庫或服務，然后這些功能可被架構中的其他服務重用。

本文討論了微服務架構中哪種功能可以作為候選功能或可以被視為Sidecar，以及Sidecar的實現方法和優缺點。

Sidecar候選功能

面向切面編程帶來了分離橫切關注點這個值得關注的概念；簡而言之，從代碼中移除通用功能，只關注業務邏輯，這就是在服務內的每個方法/函數中重復相同代碼的意義所在。

Sidecar模式本質上相似；唯一的區別是，Sidecar模式從微服務方面進行對話。將代碼的通用部分抽象出來變得更重要了。

一些最重要的候選功能包括如下：

?日志聚合

?安全

?錯誤處理，并在發布錯誤日志或將錯誤事件推送到Kafka主題或監控隊列之后采取必要的動作。

?項目中的通用功能類似于實體（數據庫模型）或其他服務也使用的特定業務邏輯。

?其他服務正常運行所需要的服務或數據庫配置、Kafka配置、隊列配置等方面的配置更改。

?緩存需求（如果有這種需求的話）。

所有這些通用功能/Sidecar可以附加到服務上，就像邊車附加到摩托車上那樣。

優缺點

?優點

實施這種模式的最大優點是，所有通用功能都可供架構中的所有服務使用，它通過將通用功能抽象到不同的層，大大降低了架構的復雜性。

微服務本質上是多語言的，這些通用功能可以使用最適合該特定操作的技術或編程語言來開發。

模式隱式避免了代碼重復，因為我們不需要在每個服務中編寫這種重復的代碼。

服務和Sidecar候選功能之間是松散耦合的關系。

?缺點

Sidecars具有單獨的可維護性，這可能是庫或單獨的服務。如果我們在應用程序中有大量的Sidecar，那么它會影響服務的性能。需要確定Sidecar功能是否需要獨立于主服務進行擴展；如果是，需要將這些Sidecar作為單獨的服務來托管。

實施方法

?將Sidecars保存在單獨的庫中

最常見的方法是將Sidecars保存在單獨的庫中，并將這些庫單獨導入到微服務中，比如將數據庫模型保存在單獨的庫中，然后通過該庫將這些模型導入到所有微服務，有各種構建工具（比如Maven、Gradle或SBT等）可用用于配置。

這種方法有以下缺點：

Sidecar過載：設想一個項目中維護多個Sidecar，比如架構中存在的日志、緩存、配置和安全都可能會在所有微服務中帶來Sidecar過載的問題。

版本不一致：維護每個庫的正確版本對于開發人員來說將是一場噩夢，想象一下cache-lib Sidecar擁有服務A在使用的最新版本1.1，但我們忘了提及仍在使用cache-lib版本1.0的服務B的正確版本，這會在應用程序中產生明顯的不一致，而這種不一致很難調試和識別。

解決這個問題的一種方法是創建一個含有所有這些Sidecar庫的Uber庫，然后我們需要做的就是在微服務中維護Uber庫的正確版本，我們需要確保Uber庫經過更新，使用最新版本的Sidecars，比如說cache-lib 1.1應該在Uber庫中可用。

?將Sidecars保留為單獨的服務

另一種方法是在單獨的服務中各自維護Sidecar。但是為每個操作調用服務調用會帶來嚴重的性能問題，但理想情況下，我們通常不為日志或通用功能創建服務。安全或緩存可能是理想的獨立的服務候選功能。

這種方法的最大缺點是，始終需要優化服務間通信以獲得更好的性能。在這種情況下，它就像架構中的另一個微服務，總是需要擴展，監控哪種有悖Sidecar的用途。

結論

Sidecar模式是一種非常有用且簡潔的模式，它使橫切關注點遠離實際的服務實現。合理設計的微服務應該始終遵循單一職責原則（SRP），而Sidecar模式通過遠離重復功能來補充SRP原則。每個設計原則都有優缺點，在庫中維護Sidecar以及保留最重要功能的混合方法應該在單獨的服務中加以維護。 

原文標題：Microservices Patterns: Sidecar，作者：Sameer Shukla

鏈接：https://dzone.com/articles/microservices-patterns-sidecar