建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 布加迪
創(chuàng)新互聯(lián)建站主要從事網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)常德,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):18982081108
合理設(shè)計(jì)的微服務(wù)應(yīng)遵循單一職責(zé)原則，因此分離應(yīng)該被架構(gòu)中的其他服務(wù)重用的通用功能很重要。Sidecar模式提倡通過(guò)識(shí)別每個(gè)服務(wù)中的通用功能來(lái)增強(qiáng)模塊性，將它們組合到庫(kù)中，或?qū)⑺鼈円频絾为?dú)的服務(wù)中。
顧名思義，Sidecar模式提倡分離橫切關(guān)注點(diǎn)（cross-cutting concern），將橫切關(guān)注點(diǎn)從實(shí)際服務(wù)中移除，推送到單獨(dú)的模塊、庫(kù)或服務(wù)，然后這些功能可被架構(gòu)中的其他服務(wù)重用。
本文討論了微服務(wù)架構(gòu)中哪種功能可以作為候選功能或可以被視為Sidecar，以及Sidecar的實(shí)現(xiàn)方法和優(yōu)缺點(diǎn)。
Sidecar候選功能
面向切面編程帶來(lái)了分離橫切關(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ì)話。將代碼的通用部分抽象出來(lái)變得更重要了。
一些最重要的候選功能包括如下：
?日志聚合
?安全
?錯(cuò)誤處理，并在發(fā)布錯(cuò)誤日志或?qū)㈠e(cuò)誤事件推送到Kafka主題或監(jiān)控隊(duì)列之后采取必要的動(dòng)作。
?項(xiàng)目中的通用功能類似于實(shí)體（數(shù)據(jù)庫(kù)模型）或其他服務(wù)也使用的特定業(yè)務(wù)邏輯。
?其他服務(wù)正常運(yùn)行所需要的服務(wù)或數(shù)據(jù)庫(kù)配置、Kafka配置、隊(duì)列配置等方面的配置更改。
?緩存需求（如果有這種需求的話）。
所有這些通用功能/Sidecar可以附加到服務(wù)上，就像邊車附加到摩托車上那樣。
優(yōu)缺點(diǎn)
?優(yōu)點(diǎn)
實(shí)施這種模式的最大優(yōu)點(diǎn)是，所有通用功能都可供架構(gòu)中的所有服務(wù)使用，它通過(guò)將通用功能抽象到不同的層，大大降低了架構(gòu)的復(fù)雜性。
微服務(wù)本質(zhì)上是多語(yǔ)言的，這些通用功能可以使用最適合該特定操作的技術(shù)或編程語(yǔ)言來(lái)開(kāi)發(fā)。
模式隱式避免了代碼重復(fù)，因?yàn)槲覀儾恍枰诿總€(gè)服務(wù)中編寫這種重復(fù)的代碼。
服務(wù)和Sidecar候選功能之間是松散耦合的關(guān)系。
?缺點(diǎn)
Sidecars具有單獨(dú)的可維護(hù)性，這可能是庫(kù)或單獨(dú)的服務(wù)。如果我們?cè)趹?yīng)用程序中有大量的Sidecar，那么它會(huì)影響服務(wù)的性能。需要確定Sidecar功能是否需要獨(dú)立于主服務(wù)進(jìn)行擴(kuò)展；如果是，需要將這些Sidecar作為單獨(dú)的服務(wù)來(lái)托管。
實(shí)施方法
?將Sidecars保存在單獨(dú)的庫(kù)中
最常見(jiàn)的方法是將Sidecars保存在單獨(dú)的庫(kù)中，并將這些庫(kù)單獨(dú)導(dǎo)入到微服務(wù)中，比如將數(shù)據(jù)庫(kù)模型保存在單獨(dú)的庫(kù)中，然后通過(guò)該庫(kù)將這些模型導(dǎo)入到所有微服務(wù)，有各種構(gòu)建工具（比如Maven、Gradle或SBT等）可用用于配置。
這種方法有以下缺點(diǎn)：
Sidecar過(guò)載：設(shè)想一個(gè)項(xiàng)目中維護(hù)多個(gè)Sidecar，比如架構(gòu)中存在的日志、緩存、配置和安全都可能會(huì)在所有微服務(wù)中帶來(lái)Sidecar過(guò)載的問(wèn)題。
版本不一致：維護(hù)每個(gè)庫(kù)的正確版本對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)將是一場(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è)問(wèn)題的一種方法是創(chuàng)建一個(gè)含有所有這些Sidecar庫(kù)的Uber庫(kù)，然后我們需要做的就是在微服務(wù)中維護(hù)Uber庫(kù)的正確版本，我們需要確保Uber庫(kù)經(jīng)過(guò)更新，使用最新版本的Sidecars，比如說(shuō)cache-lib 1.1應(yīng)該在Uber庫(kù)中可用。
?將Sidecars保留為單獨(dú)的服務(wù)
另一種方法是在單獨(dú)的服務(wù)中各自維護(hù)Sidecar。但是為每個(gè)操作調(diào)用服務(wù)調(diào)用會(huì)帶來(lái)嚴(yán)重的性能問(wè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模式通過(guò)遠(yuǎn)離重復(fù)功能來(lái)補(bǔ)充SRP原則。每個(gè)設(shè)計(jì)原則都有優(yōu)缺點(diǎn)，在庫(kù)中維護(hù)Sidecar以及保留最重要功能的混合方法應(yīng)該在單獨(dú)的服務(wù)中加以維護(hù)。
當(dāng)前名稱：微服務(wù)模式：Sidecar
分享網(wǎng)址：http://www.5511xx.com/article/coipdsg.html
