????? ? 踩坑”屎“寫到了dubbo這里，詳細很多人會好奇，我忽然想起來當年切換到spring cloud的決策過程還是滿艱辛的，整個過程，我自己做了許多調研，可能很多調研的細節都已經忘掉了，今天就把當初做決策過程的一些零碎的記憶拼湊在一起，寫個系列文章。

? ? ? ? 記得在17年的時候，dubbo還是很多公司的主流，即便到現在，我了解的公司里還是有很多公司依然在沿用dubbo，這里主要有幾點：

? ? ? ? 1、dubbo雖然只是一個服務化的體系，但在cloud全家桶沒有普及前，dubbo的周邊還是相當多的。

? ? ? ? 2、當時做服務化的時候，雖然也有一些服務化技術產品，但實際上資料最多的社區最火的還是dubbo，我記得當時有當當改版的dubbox（新加了一些feature具體請谷歌吧~）、微博的Motan、facebook的thrift、grpc等服務化架構，其中motan雖然開源的時候聲音較大，但實際上我沒聽到身邊有多少人采用。thrift雖然很好用，支持多語言，但在中國并不火，因為中國還是java占統治地位的。gpc出現的比較晚，并且，grpc有一個缺點就是，api還是需要通過工具去生成，略重，這點和dubbo很像。而dubbo我記得停止更新了很久了，最后一個版本是2.5.4吧，比起當當的dubbox還是缺少了一些有用的特性。

? ? ? ? 3、社區的活躍、網上的資料，dubbo是絕對統治級別的，尤其是在杭州這個地方，dubbo簡直就像是java一樣，是每個后端程序員必須會的。

? ? ? ? 因此，dubbo在spring cloud沒有全面崛起之前，在17年一樣是很多公司的首選。當時的技術發展，其實還是有很多選型的空間的，這些中間件來自于各個不同的公司，不同的代碼風格，甚至不同的jar包的版本號，這給公司的技術融合帶來了很大的困難。比如，jdk7升級到jdk8的話，你會發現，很多中間件并不支持，這時候，你需要維護這些開源的中間件，把他們做一次升級，這中間的成本和風險，可想而知。

? ? ? ? 那我們就通過服務端的技術選型來了解下公司的一些公司的技術體系吧，等下我去畫個草圖

服務端架構體系圖

? ? ????上圖是服務端的一些架構體系圖，其實還可以畫的更細一些，但為了能從更高一點的角度去討論這兩套生態，我還是把粒度放的稍微大一些。

? ? ? ? 其實我面試過的候選人，在P6實力左右的人，大都無法能完整的把這套生態畫出來，可能他們懂，但思維體系缺少結構化、系統化；以后在面試后端leader或者資深的時候，也可以考慮讓大家畫一下后端的架構圖。關于前端和客戶端的架構體系，以后我會再畫一下。

? ? ? ? 家里賊熱，堅持不住了，后面我會按照這里面所有組件，我先來個拋磚引玉吧，我們最常用的緩存是redis，但實際上redis一樣經歷了很多的年的進化；從最開始的redis主從、通過keepalived實現的高可用集群、哨兵模式、一致性哈希緩存集群、redis中間件（Twemproxy、codis等）、到目前的redis3.x的cluster方案，每一種演變都有它的進化史；臥槽，怎么回事，這跟服務化生態好像沒關系啊......跑題了~~~反正就是拋磚引玉hiahiahia~~~~