建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 布加迪
創(chuàng)新互聯建站主要從事網站設計、網站制作、網頁設計、企業(yè)做網站、公司建網站等業(yè)務。立足成都服務常德,十載網站建設經驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18982081108
合理設計的微服務應遵循單一職責原則，因此分離應該被架構中的其他服務重用的通用功能很重要。Sidecar模式提倡通過識別每個服務中的通用功能來增強模塊性，將它們組合到庫中，或將它們移到單獨的服務中。
顧名思義，Sidecar模式提倡分離橫切關注點（cross-cutting concern），將橫切關注點從實際服務中移除，推送到單獨的模塊、庫或服務，然后這些功能可被架構中的其他服務重用。
本文討論了微服務架構中哪種功能可以作為候選功能或可以被視為Sidecar，以及Sidecar的實現方法和優(yōu)缺點。
Sidecar候選功能
面向切面編程帶來了分離橫切關注點這個值得關注的概念；簡而言之，從代碼中移除通用功能，只關注業(yè)務邏輯，這就是在服務內的每個方法/函數中重復相同代碼的意義所在。
Sidecar模式本質上相似；唯一的區(qū)別是，Sidecar模式從微服務方面進行對話。將代碼的通用部分抽象出來變得更重要了。
一些最重要的候選功能包括如下：
?日志聚合
?安全
?錯誤處理，并在發(fā)布錯誤日志或將錯誤事件推送到Kafka主題或監(jiān)控隊列之后采取必要的動作。
?項目中的通用功能類似于實體（數據庫模型）或其他服務也使用的特定業(yè)務邏輯。
?其他服務正常運行所需要的服務或數據庫配置、Kafka配置、隊列配置等方面的配置更改。
?緩存需求（如果有這種需求的話）。
所有這些通用功能/Sidecar可以附加到服務上，就像邊車附加到摩托車上那樣。
優(yōu)缺點
?優(yōu)點
實施這種模式的最大優(yōu)點是，所有通用功能都可供架構中的所有服務使用，它通過將通用功能抽象到不同的層，大大降低了架構的復雜性。
微服務本質上是多語言的，這些通用功能可以使用最適合該特定操作的技術或編程語言來開發(fā)。
模式隱式避免了代碼重復，因為我們不需要在每個服務中編寫這種重復的代碼。
服務和Sidecar候選功能之間是松散耦合的關系。
?缺點
Sidecars具有單獨的可維護性，這可能是庫或單獨的服務。如果我們在應用程序中有大量的Sidecar，那么它會影響服務的性能。需要確定Sidecar功能是否需要獨立于主服務進行擴展；如果是，需要將這些Sidecar作為單獨的服務來托管。
實施方法
?將Sidecars保存在單獨的庫中
最常見的方法是將Sidecars保存在單獨的庫中，并將這些庫單獨導入到微服務中，比如將數據庫模型保存在單獨的庫中，然后通過該庫將這些模型導入到所有微服務，有各種構建工具（比如Maven、Gradle或SBT等）可用用于配置。
這種方法有以下缺點：
Sidecar過載：設想一個項目中維護多個Sidecar，比如架構中存在的日志、緩存、配置和安全都可能會在所有微服務中帶來Sidecar過載的問題。
版本不一致：維護每個庫的正確版本對于開發(fā)人員來說將是一場噩夢，想象一下cache-lib Sidecar擁有服務A在使用的最新版本1.1，但我們忘了提及仍在使用cache-lib版本1.0的服務B的正確版本，這會在應用程序中產生明顯的不一致，而這種不一致很難調試和識別。
解決這個問題的一種方法是創(chuàng)建一個含有所有這些Sidecar庫的Uber庫，然后我們需要做的就是在微服務中維護Uber庫的正確版本，我們需要確保Uber庫經過更新，使用最新版本的Sidecars，比如說cache-lib 1.1應該在Uber庫中可用。
?將Sidecars保留為單獨的服務
另一種方法是在單獨的服務中各自維護Sidecar。但是為每個操作調用服務調用會帶來嚴重的性能問題，但理想情況下，我們通常不為日志或通用功能創(chuàng)建服務。安全或緩存可能是理想的獨立的服務候選功能。
這種方法的最大缺點是，始終需要優(yōu)化服務間通信以獲得更好的性能。在這種情況下，它就像架構中的另一個微服務，總是需要擴展，監(jiān)控哪種有悖Sidecar的用途。
結論
Sidecar模式是一種非常有用且簡潔的模式，它使橫切關注點遠離實際的服務實現。合理設計的微服務應該始終遵循單一職責原則（SRP），而Sidecar模式通過遠離重復功能來補充SRP原則。每個設計原則都有優(yōu)缺點，在庫中維護Sidecar以及保留最重要功能的混合方法應該在單獨的服務中加以維護。
文章題目：微服務模式：Sidecar
當前URL：http://m.5511xx.com/article/coipdsg.html
