您好,登錄后才能下訂單哦!
這篇文章主要講解了“ASM實戰之如何理解服務發現”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“ASM實戰之如何理解服務發現”吧!
一、組件化
因此當項目足夠龐大復雜,需求足夠垂直之后,項目整體架構如何演進就變得頗為重要,如果拆分項目就是一個亟待解決的問題。而組件化則是其中較為正確的一種解決方案。
本質的思路:按需求類型維度(或其他的抽象維度)對整個項目進行模塊上的拆解,每個模塊按照對擴展開放,對修改關閉的原則進行依賴隔離的設計。在如此的指導下項目自然而然的就分而治之,化繁為簡,化整為零。這也就是常說的模塊化(組件化)。
個人看法:叫組件還是模塊,只是抽象的維度的不一樣罷了,沒什么好糾結的。
組件化的意義對于項目來說在于宏觀上的解耦,具體下的內聚。這種思想在設計模塊中經常被提到:高內聚低耦合。
這樣帶來的“好處”也是顯而易見的,復雜的工作被拆的足夠簡單,那么團隊的劃分便會更科學,執行也會更高效,畢竟只需要負責自己的一畝三分地,“鍋也就比較好分了”…
這似乎也是流水線模式下的一種應用吧,是好還是壞,作為打工人的我也不好評判什么,畢竟我也是被流水線上的一員。人生在世又有誰是自愿背上枷鎖的呢…
明確組件化的內核和意義,接下來我們就要思考如何去落地。想要徹底拆分和解耦,除了接口上的設計,編譯隔離也是必須要考慮的問題。而走到這一步,很多有經驗的同學應該意識到這其中的棘手的問題:既然面向的是接口,又是編譯隔離,那么如何拿到接口背后的實現呢?
路走到這里,也就該面對服務發現(或者接口發現)的問題了。
二、服務發現
咱們用一張圖來描述一下上述環節聊的這些內容:
從圖中,我們可以看到這里對組件化的方案,是增加了一個接口層,這層往下都是實現層。為了實現編譯隔離,所有的實現層只能依賴接口層,這樣對于實現層來說,就無法看到其他模塊的實現,也就不會干預到其他模塊。
因此如何方便的讓模塊彼此能夠方便的通過服務發現感知到其他模塊的實現便尤為重要。
感謝各位的閱讀,以上就是“ASM實戰之如何理解服務發現”的內容了,經過本文的學習后,相信大家對ASM實戰之如何理解服務發現這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。