編者注：《明朝那些事兒》主要講述了明朝近300年曆史，按照時間軸爲主線進行講解，本文也按照時間軸爲主線，講述下dubbo版的"明朝那些事" -- dubbo的發展歷程。
Apache Dubbo™ 是一款高性能Java RPC框架。說起dubbo，國內開發者幾乎都知道它的大名，既然現在的dubbo很流行，那麼讓我們回顧下過去的dubbo吧，一起看下dubbo的發展歷程：
2011年10月27日，阿里巴巴（B2B部門）開源自己的SOA服務化治理方案的核心框架Dubbo。
2012年10月23日發佈Dubbo2.5.3版本，至此之後，阿里基本停止了對Dubbo的主要升級；僅在13、14年進行過幾次更新維護版本然後就停止了所有的維護工作；同時Dubbo對Srping的支持也停留在了Spring 2.5.6版本上。在阿里停止維護和升級Dubbo期間，噹噹網開始維護自己的Dubbo分支版本Dubbox，支持了新版本的Spring，並對外開源了Dubbox。
2017年9月7日發佈Dubbo的2.5.4版本，距離上一個版本2.5.3發佈已經接近快5年時間了。在隨後的幾個月中，阿里Dubbo開發團隊以差不多每月一版本的速度開始快速升級迭代，修補了Dubbo老版本多年來存在的諸多bug，並對Spring等組件的支持進行了全面升級。（不知道是不是因爲KPI的壓力 ^_^）
2018年1月8日發佈Dubbo 2.6.0版本，新版本將之前噹噹網開源的Dubbo分支Dubbox進行了合併，實現了Dubbo版本的統一整合。
2018年1月8日，Dubbo創始人之一梁飛在Dubbo交流羣裏透露了Dubbo 3.0正在動工的消息。Dubbo 3.0內核與Dubbo2.0完全不同，但兼容Dubbo 2.0。Dubbo 3.0將以Streaming爲內核，不再是Dubbo時代的RPC，但是RPC會在Dubbo3.0中變成遠程Streaming對接的一種可選形態。Dubbo 3.0將支持可選Service Mesh，多加一層IPC，這主要是爲了兼容老系統，而內部則會優先嚐試內嵌模式。代理模式Ops可獨立升級框架，減少業務侵入，而內嵌模式可以帶業務測試、部署節點少、穩定性檢測方便。同時，可以將Dubbo3.0啓動爲獨立進程，由dubbo-mesh進行IPC，路由、負載均衡和熔斷機制將由獨立進程控制。
2018年2月15日，阿里將Dubbo開源貢獻給Apache，即incubator-dubbo。
2019 年 5 月 20 日，Apache 軟件基金會在馬薩諸塞州維克菲爾德宣佈，Apache Dubbo 升級爲頂級項目。
2019年12月29日，apache-dubbo-2.7.5 發佈，支持http2 grpc、服務自省能力，爲走向雲原生打下基礎。
從dubbo最初開源的火熱，到14-17年的基本停滯，再到17年下半年到現在的迅猛發展，可以從github上commits圖看出來明顯變化：
目前已有150+公司在使用，包括阿里巴巴集團、中國人壽、中國電信、噹噹網、滴滴出行、海爾、中國工商銀行、網易、去哪兒、有贊等。dubbo提供的主要能力是基於接口的遠程代理，容錯和負載均衡，以及自動服務註冊和發現等，功能包括：
基於透明接口的 RPC：提供基於高性能接口的 RPC，對用戶而言是透明的。
智能負載平衡：支持多種開箱即用的負載均衡策略，可感知下游服務狀態，從而降低整體延遲，提高系統吞吐量。
自動服務註冊和發現：支持多個服務註冊，可即時在線 / 離線檢測服務。
高可擴展性：微內核和插件設計確保了它可容易地通過第三方實現跨核心功能（如協議、傳輸和序列化等）。
運行時流量路由：可在運行時進行配置，使流量可根據不同的規則進行路由，這使得能夠輕鬆支持藍綠部署、數據中心感知路由等功能。
可視化服務治理：爲服務治理和維護提供豐富的工具，如查詢服務元數據、運行狀況和統計信息。
dubbo的開源
這裏不得不提一個人，梁飛，花名（虛極），2009 年加入阿里巴巴，負責中間件的開發，Dubbo 開源分佈式服務框架作者。
Dubbo 項目誕生於 2008 年。梁飛最早進入阿里的時候，Dubbo 項目還沒有 Dubbo 這個名字，那時的 Dubbo 還是一個阿里內部的系統。2010 年，Dubbo 項目進行了重構。2011 年的阿里，憋了一股勁兒要成爲一家技術人嚮往的企業。那個時候，開發者剛剛成爲國內各大廠商爭相奪取的寶貴資產,靠什麼吸引最頂尖的開發者？黑客文化、工程師文化、開源文化。
當時在淘寶、在阿里 B2B，都有團隊在推動開源。阿里 B2B 這邊決定先拿 Dubbo 項目開源出去。當時淘寶（2C）也有一個和dubbo類似的項目叫做HSF，也是一箇中間件服務框架，跟 Dubbo 做的事情高度重合。當時的情況是：整個淘系都在用 HSF，而阿里金融、集團、B2B 都在用 Dubbo。
在Dubbo和HSF的"競爭"中，從最初的開始讓 HSF 合併到 Dubbo 裏面，但是由於時間未達到預期實際上並沒有合併起來，後來就決定反向合併，把 Dubbo 合併到 HSF 裏面去。之後，Dubbo就在14年之後沒更新過了，同時Dubbo 團隊調整，去到了各個地方。
不過，牆內開花牆外香，阿里之外，還是吸引很多公司和開發者使用dubbo的，比如噹噹網開發的擴展版本Dubbox 後來就在持續發展。
關於dubbo和HSF的競爭中失敗，這裏不討論技術上實現哪個更好？（嚴格來講，二者實現思想不同，前者更加輕量級、擴展性強，後者稍微重量級、依賴較多）而是結合當時環境來分析，當時阿里處於系統大重構過程中，特別是淘寶的系統大重構，由於淘寶用的是HSF，已經與淘寶系統深度融合了，根植於淘系的基因了，因此後續換一個新的技術，成本較大收益不明顯。
dubbo的重生
既然dubbo都已經好長時間不維護更新了，那麼怎麼在17年會突然宣佈維護並且推動孵化Apache呢？難道是傳說中的KPI的原因？
實際上dubbo的轉機，在於阿里雲的流行。
2017 年的阿里雲，發現有一批客戶上雲之後，想要用 Dubbo。因爲他們 Dubbo 已經用的很熟了，不想因爲上雲而被迫改變自己的使用習慣。
於是，阿里雲就把 Dubbo 服務作爲自己的一個產品，賣給了這些客戶。但是，客戶們又提出了一個問題：
“你看你們 Dubbo 都不怎麼更新代碼了是吧？你們自己都不維護了，我們用你的框架就覺得特別不放心。”
這下好了，真正的客戶提出要求了，提升客戶對 Dubbo 的信心，成爲了一件在公司層面有價值的事情。因此阿里進一步升級Dubbo並把它捐贈給Apache。2018 年初，Dubbo 項目正式進入了 Apache 的孵化器。
dubbo的進化
dubbo的重生和進入Apache，已經說明dubbo旺盛的生命力了，但是如何讓這種生命力更強呢？
擁有更強的生命力，不僅是dubbo本身發展的需要，也是適應未來技術發展的需要。dubbo在Apache孵化階段，Dubbo正在從一個微服務領域的高性能 Java RPC 框架，演進到微服務框架 Dubbo Ecosystem，打造出一個完整的微服務生態。
爲什麼dubbo需要完成的微服務生態，這裏拿Spring Cloud做個對比：
Spring Cloud由衆多子項目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分佈式系統及微服務常用的工具，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分佈式會話和集羣狀態等，滿足了構建微服務所需的所有解決方案。比如使用Spring Cloud Config 可以實現統一配置中心，對配置進行統一管理；使用Spring Cloud Netflix 可以實現Netflix 組件的功能 - 服務發現（Eureka）、智能路由（Zuul）、客戶端負載均衡（Ribbon）。
關於服務治理的配置中心、服務發現、降級熔斷等等，dubbo同樣也是需要的，但是dubbo目前對這些的支持還不是很完善，需要開發人員自定義並引入對應組件，這種就提高了使用成本。因此構建一個dubbo版的微服務生態，也是Dubbo社區滿足開發者更高效的構建微服務體系期望的使命和擔當。關於Dubbo Ecosystem系統構建，阿里開源了Nacos、Sentinel、seata等項目。
雲原生越來越火熱，dubbo爲了更好地適配雲原生，在2.7.5版本新引入了一種基於實例（應用）粒度的服務發現機制，這是爲 Dubbo 適配雲原生基礎設施的一步重要探索。
除了上述的這些，Dubbo 3.0 的規劃也在全面進行中，如何讓應用級服務發現成爲未來下一代服務框架 Dubbo 3.0 的基礎服務模型，解決雲原生、規模化微服務集羣擴容與可伸縮性問題，也已經成爲Dubbo發展的重點。
最後，對於Dubbo的發展，我們應該抱有更大的信心，一方面是國內互聯網業務複雜度，發展迅猛，將帶來更多樣的應用場景，對於開源技術和項目的推動落地，提供了一個很好的試驗場；另一方面是國內公司對開源技術越來越重視，社區文化越來越濃重。
推薦閱讀
歡迎小夥伴關注【TopCoder】閱讀更多精彩好文。
