譯者 | 布加迪 

合理設(shè)計(jì)的微服務(wù)應(yīng)遵循單一職責(zé)原則，因此分離應(yīng)該被架構(gòu)中的其他服務(wù)重用的通用功能很重要。Sidecar模式提倡通過識(shí)別每個(gè)服務(wù)中的通用功能來增強(qiáng)模塊性，將它們組合到庫中，或?qū)⑺鼈円频絾为?dú)的服務(wù)中。

顧名思義，Sidecar模式提倡分離橫切關(guān)注點(diǎn)（cross-cutting concern），將橫切關(guān)注點(diǎn)從實(shí)際服務(wù)中移除，推送到單獨(dú)的模塊、庫或服務(wù)，然后這些功能可被架構(gòu)中的其他服務(wù)重用。

本文討論了微服務(wù)架構(gòu)中哪種功能可以作為候選功能或可以被視為Sidecar，以及Sidecar的實(shí)現(xiàn)方法和優(yōu)缺點(diǎn)。

Sidecar候選功能

面向切面編程帶來了分離橫切關(guān)注點(diǎn)這個(gè)值得關(guān)注的概念；簡(jiǎn)而言之，從代碼中移除通用功能，只關(guān)注業(yè)務(wù)邏輯，這就是在服務(wù)內(nèi)的每個(gè)方法/函數(shù)中重復(fù)相同代碼的意義所在。

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

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

?日志聚合

?安全

?錯(cuò)誤處理，并在發(fā)布錯(cuò)誤日志或?qū)㈠e(cuò)誤事件推送到Kafka主題或監(jiān)控隊(duì)列之后采取必要的動(dòng)作。

?項(xiàng)目中的通用功能類似于實(shí)體（數(shù)據(jù)庫模型）或其他服務(wù)也使用的特定業(yè)務(wù)邏輯。

?其他服務(wù)正常運(yùn)行所需要的服務(wù)或數(shù)據(jù)庫配置、Kafka配置、隊(duì)列配置等方面的配置更改。

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

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

優(yōu)缺點(diǎn)

?優(yōu)點(diǎn)

實(shí)施這種模式的最大優(yōu)點(diǎn)是，所有通用功能都可供架構(gòu)中的所有服務(wù)使用，它通過將通用功能抽象到不同的層，大大降低了架構(gòu)的復(fù)雜性。

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

模式隱式避免了代碼重復(fù)，因?yàn)槲覀儾恍枰诿總€(gè)服務(wù)中編寫這種重復(fù)的代碼。

服務(wù)和Sidecar候選功能之間是松散耦合的關(guān)系。

?缺點(diǎn)

Sidecars具有單獨(dú)的可維護(hù)性，這可能是庫或單獨(dú)的服務(wù)。如果我們?cè)趹?yīng)用程序中有大量的Sidecar，那么它會(huì)影響服務(wù)的性能。需要確定Sidecar功能是否需要獨(dú)立于主服務(wù)進(jìn)行擴(kuò)展；如果是，需要將這些Sidecar作為單獨(dú)的服務(wù)來托管。

實(shí)施方法

?將Sidecars保存在單獨(dú)的庫中

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

這種方法有以下缺點(diǎn)：

Sidecar過載：設(shè)想一個(gè)項(xiàng)目中維護(hù)多個(gè)Sidecar，比如架構(gòu)中存在的日志、緩存、配置和安全都可能會(huì)在所有微服務(wù)中帶來Sidecar過載的問題。

版本不一致：維護(hù)每個(gè)庫的正確版本對(duì)于開發(fā)人員來說將是一場(chǎng)噩夢(mèng)，想象一下cache-lib Sidecar擁有服務(wù)A在使用的最新版本1.1，但我們忘了提及仍在使用cache-lib版本1.0的服務(wù)B的正確版本，這會(huì)在應(yīng)用程序中產(chǎn)生明顯的不一致，而這種不一致很難調(diào)試和識(shí)別。

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

?將Sidecars保留為單獨(dú)的服務(wù)

另一種方法是在單獨(dú)的服務(wù)中各自維護(hù)Sidecar。但是為每個(gè)操作調(diào)用服務(wù)調(diào)用會(huì)帶來嚴(yán)重的性能問題，但理想情況下，我們通常不為日志或通用功能創(chuàng)建服務(wù)。安全或緩存可能是理想的獨(dú)立的服務(wù)候選功能。

這種方法的最大缺點(diǎn)是，始終需要優(yōu)化服務(wù)間通信以獲得更好的性能。在這種情況下，它就像架構(gòu)中的另一個(gè)微服務(wù)，總是需要擴(kuò)展，監(jiān)控哪種有悖Sidecar的用途。

結(jié)論

Sidecar模式是一種非常有用且簡(jiǎn)潔的模式，它使橫切關(guān)注點(diǎn)遠(yuǎn)離實(shí)際的服務(wù)實(shí)現(xiàn)。合理設(shè)計(jì)的微服務(wù)應(yīng)該始終遵循單一職責(zé)原則（SRP），而Sidecar模式通過遠(yuǎn)離重復(fù)功能來補(bǔ)充SRP原則。每個(gè)設(shè)計(jì)原則都有優(yōu)缺點(diǎn)，在庫中維護(hù)Sidecar以及保留最重要功能的混合方法應(yīng)該在單獨(dú)的服務(wù)中加以維護(hù)。 

原文標(biāo)題：Microservices Patterns: Sidecar，作者：Sameer Shukla

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