淺談微服務架構與服務治理的Eureka和Dubbo

前言

        原本計劃週五+週末三天自駕遊，誰知人算不如天算，週六恰逢颱風來襲，湖州附近的景點所有關停，不得已只能週五玩完以後，於週六踩着颱風的邊緣逃回上海。週末過得如此艱難，此次就聊點務虛的話題，一是淺談微服務的架構設計，二是聊聊微服務中普遍用於服務治理的Eureka與RPC框架Dubbo異同點。

1、微服務的架構設計

        之因此想聊一下這個話題，主要有感於最近接觸的兩個新的微服務項目--兩個項目的架構設計出自兩我的之手，卻不約而同的使用了相同的設計理念，項目結構很是相似。又想到就任於上家公司時接觸到的項目的結構設計，因而迸發出了些微的想法。用微服務的架構設計來做爲議題，頗有喧譁取寵的偏向，因此須要聲明一下，本文說的都是基於博主當前淺薄的軟件開發經驗與貧瘠的架構設計思想得出的淺見，僅是一家之言，並且其中一定包含了不少的確認型偏誤，對此如今沒法避免。本文的目的只是與你們分享一下本身的想法，僅此而已。

        言歸正傳，當前流傳的比較廣且提的比較多的設計理念，當屬2004年Eric Evans提出的Domain Drive Design，即領域驅動設計，簡稱DDD。該設計理念能夠說與微服務具備至關大的共生依賴關係，也所以，直到最近幾年微服務興起，DDD設計理念才大行其道。該設計理念就是先肯定領域，再在此基礎上進行設計開發。而領域怎麼理解？通俗的理解方式就是一個獨立的業務模塊，以業務的範圍來肯定領域的邊界。以電商項目爲例子，購物車能夠當作一個領域，下訂單當作一個領域，商城當作一個領域，而當某個領域發展的過於龐大的時候，再對其進行拆分，分紅更細分的領域，原則就是保證每個領域作的是一個單獨的事情，作到最大程度的解耦。

        以實際項目爲例，將一個項目劃分紅三個一級模塊，分別爲微服務啓動類模塊、核心業務模塊、通用的中間件等技術模塊。而每一個一級模塊中都有若干個二級模塊，每一個二級模塊就是一個領域，好比業務模塊下的二級模塊有：商城、購物車、下訂單、支付等。技術模塊下有：redis模塊、swagger模塊、數據庫模塊、消息隊列模塊等等。業務模塊與技術模塊中的二級模塊，都經過啓動類模塊進行統一的整合，即肯定哪一個微服務須要用到哪些模塊。這樣就能夠以最大的靈活性對已有模塊進行組合排列。

        稍微高深一些的技術人員都知道，沒有完美的架構設計，只有更適合當前場景的設計。良好的架構設計不能一勞永逸的解決將來全部的問題，但絕對能夠在解決問題時給你提供極大的便捷性。

2、Eureka與Dubbo

        如今網上，更多的是用Dubbo與Spring Cloud進行比較，從微服務的模塊功能上比較兩者的異同。但這樣比較未免有點偏，Dubbo的定位更多的是作服務治理，而不是提供一攬子的微服務架構解決辦法，因此比較的結果就是Spring Cloud這個功能有那個功能有，但Dubbo這個沒有那個沒有。今天我們從服務治理的角度，用Spring Cloud經常使用的Eureka與Dubbo進行比較，看看兩者的異同。

        要說這二者，不得不提一下分佈式架構中的CAP理論，即一個分佈式框架，只能同時知足C一致性、A可用性、P網絡分區容錯性這三者中的兩個，不可能同時兼備三者。

        從這個角度上來看，Dubbo推薦的註冊中心首選ZK，而ZK是一個知足CP的框架；Eureka因爲其架構設計，更多專一於AP。

        對於容錯機制，Dubbo自身實現了多個錯誤處理方式，好比失敗切換Failover、快速失敗Failfast、失敗安全Failsafe等，Eureka是藉助於Spring Cloud中的熔斷器Hytrix實現的容錯。

        對於負載均衡，Dubbo自身實現了多種負載均衡方式，好比隨機權重、哈希一致性等，Eureka一樣是將此功能外放，經過Ribbon等實現了負載均衡。

        服務註冊及發現，Dubbo自身封裝了NettyClient等通信工具，而Eureka都是採用的應用層通信HttpClient。

        由此能夠看出，微服務框架自己也是採用了領域拆分的設計理念，將相對獨立的不一樣功能拆分紅單獨的模塊，想用什麼模塊就組合什麼模塊。從這個角度上看，Dubbo更多的是提供了一個組合起來不可拆分的總體功能，而Eureka與其餘組件則簡單輕便的多。

後記

        其實能夠再延伸一步，感受微服務的這種DDD設計理念，能夠對比人類社會中的分工產生效能。每個工種表明一個領域，不一樣的領域內部作好本身的功能便可，經過分工能極大提高社會總體的生產力，而經過領域劃分，也能提高一個框架、一個組織的工做效能。萬事萬物皆有聯繫，古人誠不我欺。