前言

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

一、微服務的架構設計

        之所以想聊一下這個話題，主要有感於最近接觸的兩個新的微服務專案--兩個專案的架構設計出自兩個人之手，卻不約而同的使用了相同的設計理念，專案結構非常類似。又想到就職於上家公司時接觸到的專案的結構設計，於是迸發出了些微的想法。用微服務的架構設計來作為議題，很有喧譁取寵的偏向，所以需要宣告一下，本文說的都是基於博主當前淺薄的軟體開發經驗與貧瘠的架構設計思想得出的淺見，僅是一家之言，而且其中必定包含了很多的確認型偏誤，對此現在無法避免。本文的目的只是與大家分享一下自己的想法，僅此而已。

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

        以實際專案為例，將一個專案劃分成三個一級模組，分別為微服務啟動類模組、核心業務模組、通用的中介軟體等技術模組。而每個一級模組中都有若干個二級模組，每個二級模組就是一個領域，比如業務模組下的二級模組有：商城、購物車、下訂單、支付等。技術模組下有：redis模組、swagger模組、資料庫模組、訊息佇列模組等等。業務模組與技術模組中的二級模組，都通過啟動類模組進行統一的整合，即確定哪個微服務需要用到哪些模組。這樣就可以以最大的靈活性對已有模組進行組合排列。

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

二、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設計理念，可以對比人類社會中的分工產生效能。每一個工種代表一個領域，不同的領域內部做好自己的功能即可，通過分工能極大提升社會整體的生產力，而通過領域劃分，也能提升一個框架、一個組織的工作效能。萬事萬物皆有聯絡，古人誠不我