Dubbo由于是二進(jìn)制的傳輸，占用帶寬會(huì)更少。Spring Cloud 是 HTTP 協(xié)議傳輸，帶寬占用會(huì)比較多，同時(shí)使用 HTTP 協(xié)議一般會(huì)使用 JSON 報(bào)文，消耗會(huì)更大。 Dubbo 的開發(fā)難度較大，原因是 Dubbo 的 jar 包依賴問題很多大型工程無法解決；Spring Cloud 的接口協(xié)議約定比較自由且松散，需要有強(qiáng)有力的行政措施來限制接口無序升級(jí)。 Dubbo 的注冊中心可以選擇 ZK、Redis 等多種；Spring Cloud 的注冊中心只能用 Eureka 或者自研。 但如果我選，我會(huì)用 Spring Cloud。 從公司整體規(guī)劃考慮 我不會(huì)選擇很久沒人維護(hù)的 Dubbo，重啟之后也未必是原班人馬。 從程序員招聘難度考慮 招 Spring Cloud 的程序員會(huì)更好招，因?yàn)楦赂拧?/span> 從系統(tǒng)結(jié)構(gòu)簡易程度考慮
從性能考慮
從開發(fā)難易度考慮 Dubbo 的神坑是 jar 包依賴，開發(fā)階段難度極大。我曾經(jīng)帶一個(gè)三十人的團(tuán)隊(duì)，因?yàn)?jar 包升級(jí)問題，把每個(gè)人的電腦都操作過。尤其每個(gè)人電腦的庫路徑、命令、快捷鍵、鍵盤，鼠標(biāo)快慢都不一樣，那會(huì)兒我默默的（此處省略200字）。Spring Cloud比較自由，但帶來的問題是無法“強(qiáng)力約束接口規(guī)范”，建議用行政方式解決，且我們團(tuán)隊(duì)的強(qiáng)力行政約束做的還是比較好的，在接口管控層面比較強(qiáng)效，一個(gè)沒有行政組織能力的IT團(tuán)隊(duì)真的是個(gè)廢渣，用什么框架都不好使。 從后續(xù)改進(jìn)考慮
從配套措施考慮 Spring Cloud 一直宣稱自己是“一套全方面的解決方案”…… 我起初信了，后來發(fā)現(xiàn)上當(dāng)了。實(shí)話說：有，但是不是很健全，100分打50的樣子，很多你還需要改造。而 Dubbo 相反，一直宣稱自己是“一套全方面的服務(wù)化方案”…… 純服務(wù)化沒什么用，任何系統(tǒng)都是相輔相成配套的。一個(gè)完整的系統(tǒng)，要有前臺(tái)、中臺(tái)、后臺(tái)、前臺(tái)包括前端和交互，中臺(tái)包括交易、任務(wù)、數(shù)據(jù)，后臺(tái)包括財(cái)務(wù)、賬戶、管理……單純的服務(wù)化解決不了“任何問題”，唯有體系才能解決。在這個(gè)層面，Spring Cloud是個(gè)往“體系”方向發(fā)展的方案，而 Dubbo 僅是個(gè)工具而已，兩者相比，就好比始祖鳥與草履蟲的區(qū)別。 從技術(shù)實(shí)力層面考慮 對比雙方的源碼，不得不說 Dubbo 作者的技術(shù)能力要高于Spring Cloud，而 Spring Boot 的作者技術(shù)能力要高于 Dubbo，即： 我喜歡 Spring Boot 這種大道至簡的風(fēng)格，Keep it simple and stupid。而 Dubbo 好嘛...... 你先看看 dubboSPI，再看看 Protocol$Adpative 里面那一群繞來繞去的玩意兒，你會(huì)迅速判斷出：這群人在炫技。盡管 Dubbo 從上之下分為十層四五十個(gè)組件，第一感官上是哇塞好全面好偉大的樣子，但深入之后你會(huì)覺得，這技術(shù)是很炫，設(shè)計(jì)的確實(shí)很全面，但是用不到。例如：請各位大神給我解釋一下，在 Zookeeper 地址中，使用逗號(hào)分隔和分號(hào)分隔地址的區(qū)別……用途不大，但是代碼里為了這個(gè)就走向了“完全不同”的一條分支。用俗語評價(jià)，就是“臃腫且無用代碼過多，在文檔里還非得為了這個(gè)說出123456來”。說完 Dubbo 再說 Spring Cloud……它沒有技術(shù)含量，完全沒有，就是一堆簡單組件拼裝在一起，如 configserver、eurekaserver、robin、feignClient、htstrix等，每個(gè)都特別簡單，沒什么技術(shù)含量，但我喜歡這種的，就喜歡這種大道至簡的簡單。 最后說 Spring Boot，我要用“純粹”兩個(gè)字來評價(jià)這個(gè)框架。真的很純粹，并且從其代碼架構(gòu)的總體思路一致性，目標(biāo)的純粹性，具體模塊的干凈利落，確實(shí)是個(gè)好框架，值得大家一讀。 從系統(tǒng)應(yīng)用層面考慮 在技術(shù)實(shí)力滿分一百能打85分的鄙人的眼中，Dubbo 和 Spring Cloud，不就是兩個(gè)框架么？我們是要拯救世界的人，這倆塊鵝卵石一塊圓的一塊方的，能墊腳就行，沒有區(qū)別。 簡而言之，Dubbo 確實(shí)類似于 Spring Cloud 的一個(gè)子集，Dubbo 功能和文檔完善，在國內(nèi)有很多的成熟用戶，然而鑒于 Dubbo 的社區(qū)現(xiàn)狀（曾經(jīng)長期停止維護(hù)，2017年7月31日團(tuán)隊(duì)又宣布重點(diǎn)維護(hù)），使用起來還是有一定的門檻。 Dubbo 具有調(diào)度、發(fā)現(xiàn)、監(jiān)控、治理等功能，支持相當(dāng)豐富的服務(wù)治理能力。Dubbo架構(gòu)下，注冊中心對等集群，并會(huì)緩存服務(wù)列表已被數(shù)據(jù)庫失效時(shí)繼續(xù)提供發(fā)現(xiàn)功能，本身的服務(wù)發(fā)現(xiàn)結(jié)構(gòu)有很強(qiáng)的可用性與健壯性，足夠支持高訪問量的網(wǎng)站。 雖然 Dubbo 支持短連接大數(shù)據(jù)量的服務(wù)提供模式，但絕大多數(shù)情況下都是使用長連接小數(shù)據(jù)量的模式提供服務(wù)使用的。所以，對于類似于電商等同步調(diào)用場景多并且能支撐搭建 Dubbo 這套比較復(fù)雜環(huán)境的成本的產(chǎn)品而言，Dubbo 確實(shí)是一個(gè)可以考慮的選擇。但如果產(chǎn)品業(yè)務(wù)中由于后臺(tái)業(yè)務(wù)邏輯復(fù)雜、時(shí)間長而導(dǎo)致異步邏輯比較多的話，可能 Dubbo 并不合適。同時(shí)，對于人手不足的初創(chuàng)產(chǎn)品而言，這么重的架構(gòu)維護(hù)起來也不是很方便。 Spring Cloud 由眾多子項(xiàng)目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統(tǒng)及微服務(wù)常用的工具，如配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、一次性 token、全局鎖、選主、分布式會(huì)話和集群狀態(tài)等，滿足了構(gòu)建微服務(wù)所需的所有解決方案。比如使用 Spring Cloud Config 可以實(shí)現(xiàn)統(tǒng)一配置中心，對配置進(jìn)行統(tǒng)一管理；使用Spring Cloud Netflix 可以實(shí)現(xiàn) Netflix 組件的功能—服務(wù)發(fā)現(xiàn)（Eureka）、智能路由（Zuul）、客戶端負(fù)載均衡（Ribbon）。 但它并沒有重復(fù)造輪子，而是選用目前各家公司開發(fā)的比較成熟的、經(jīng)得住實(shí)踐考驗(yàn)的服務(wù)框架（我們需要特別感謝 Netflix ，這家很早就成功實(shí)踐微服務(wù)的公司，幾年前把自家?guī)缀跽麄€(gè)微服務(wù)框架棧貢獻(xiàn)給了社區(qū)，Spring Cloud 主要是對 Netflix 開源組件的進(jìn)一步封裝），通過 Spring Boot 進(jìn)行封裝集成并簡化其使用方式。基于 Spring Boot，意味著其使用方式如 Spring Boot 簡單易用；能夠與Spring Framework、Spring Boot、Spring Data 等其它 Spring 項(xiàng)目完美融合，意味著能從 Spring 獲得巨大的便利，意味著能減少已有項(xiàng)目的遷移成本。 其實(shí)，從社區(qū)活躍度和功能完整度，再對照業(yè)務(wù)需求和團(tuán)隊(duì)狀況，基本可以確定如何選型。這里分享網(wǎng)易考拉海購實(shí)踐以及團(tuán)隊(duì)選型的心聲： 鑒于服務(wù)發(fā)現(xiàn)對服務(wù)化架構(gòu)的重要性，再補(bǔ)充一點(diǎn)：Dubbo 實(shí)踐通常以 ZooKeeper 為注冊中心（Dubbo 原生支持的 Redis 方案需要服務(wù)器時(shí)間同步，且性能消耗過大）。針對分布式領(lǐng)域著名的CAP理論（C 數(shù)據(jù)一致性，A 服務(wù)可用性，P 服務(wù)對網(wǎng)絡(luò)分區(qū)故障的容錯(cuò)性），Zookeeper 保證的是 CP ，但對于服務(wù)發(fā)現(xiàn)而言，可用性比數(shù)據(jù)一致性更加重要 ，而 Eureka 設(shè)計(jì)則遵循 AP 原則 。 為什么選擇使用 Spring Cloud 而放棄了 Dubbo 可能大家會(huì)問，為什么選擇了使用 Dubbo 之后，而又選擇全面使用 Spring Cloud呢？其中有幾個(gè)原因： 1）從兩個(gè)公司的背景來談：Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司；Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品。阿里巴巴是一個(gè)商業(yè)公司，雖然也開源了很多的頂級(jí)的項(xiàng)目，但從整體戰(zhàn)略上來講，仍然是服務(wù)于自身的業(yè)務(wù)為主。Spring 專注于企業(yè)級(jí)開源框架的研發(fā)，不論是在中國還是在世界上使用都非常廣泛，開發(fā)出通用、開源、穩(wěn)健的開源框架就是他們的主業(yè)。 2）從社區(qū)活躍度這個(gè)角度來對比，Dubbo 雖然也是一個(gè)非常優(yōu)秀的服務(wù)治理框架，并且在服務(wù)治理、灰度發(fā)布、流量分發(fā)這方面做的比 Spring Cloud 還好，除過當(dāng)當(dāng)網(wǎng)在基礎(chǔ)上增加了 REST 支持外，已有兩年多的時(shí)間幾乎都沒有任何更新了。在使用過程中出現(xiàn)問題，提交到 GitHub 的 Issue 也少有回復(fù)。 相反 Spring Cloud 自從發(fā)展到現(xiàn)在，仍然在不斷的高速發(fā)展，從 GitHub 上提交代碼的頻度和發(fā)布版本的時(shí)間間隔就可以看出，現(xiàn)在 Spring Cloud 即將發(fā)布2.0版本，到了后期會(huì)更加完善和穩(wěn)定。 3) 從整個(gè)大的平臺(tái)架構(gòu)來講，Dubbo 框架只是專注于服務(wù)之間的治理，如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無形中使用 Dubbo 的難度就會(huì)增加。Spring Cloud 幾乎考慮了服務(wù)治理的方方面面，更有 Spring Boot 這個(gè)大將的支持，開發(fā)起來非常的便利和簡單。 4）從技術(shù)發(fā)展的角度來講，Dubbo 剛出來的那會(huì)技術(shù)理念還是非常先進(jìn)，解決了各大互聯(lián)網(wǎng)公司服務(wù)治理的問題，中國的各中小公司也從中受益不少。經(jīng)過了這么多年的發(fā)展，互聯(lián)網(wǎng)行業(yè)也是涌現(xiàn)了更多先進(jìn)的技術(shù)和理念，Dubbo 一直停滯不前，自然有些掉隊(duì)，有時(shí)候我個(gè)人也會(huì)感到有點(diǎn)可惜，如果 Dubbo 一直沿著當(dāng)初的那個(gè)路線發(fā)展，并且延伸到周邊，今天可能又是另一番景象了。 Spring 推出 Spring Boot/Cloud 也是因?yàn)樽陨淼暮芏嘣?。Spring 最初推崇的輕量級(jí)框架，隨著不斷的發(fā)展也越來越龐大，隨著集成項(xiàng)目越來越多，配置文件也越來越混亂，慢慢的背離最初的理念。隨著這么多年的發(fā)展，微服務(wù)、分布式鏈路跟蹤等更多新的技術(shù)理念的出現(xiàn)，Spring 急需一款框架來改善以前的開發(fā)模式，因此才會(huì)出現(xiàn) Spring Boot/Cloud 項(xiàng)目，我們現(xiàn)在訪問 Spring 官網(wǎng)，會(huì)發(fā)現(xiàn) Spring Boot 和 Spring Cloud 已經(jīng)放到首頁最重點(diǎn)突出的三個(gè)項(xiàng)目中的前兩個(gè)，可見 Spring 對這兩個(gè)框架的重視程度。 總結(jié)一下，Dubbo 曾經(jīng)確實(shí)很牛逼，但是 Spring Cloud 是站在近些年技術(shù)發(fā)展之上進(jìn)行開發(fā)，因此更具技術(shù)代表性。Spring Cloud 是整機(jī)，Dubbo 需要自己組裝；整機(jī)的性能有保證，組裝的機(jī)子更自由。 |
|
|
