這幾年來技術發展特別快，微服務一詞也是比較熱門，行內行外的都津津樂道。今天要記錄的主角Dubbo是其中的一員，但是它可不能完全代表微服務，Dubbo是基於面向服務的架構體系(SOA)，而微服務其實是SOA某種程度上的擴展。是一種架構風格，新的準則，有興趣的話可以查看martin fowler寫的有關論文
。扯遠了，進入正文。
爲什麼需要Dubbo呢?
這裏記錄一下這個技術是怎麼來的。
我們最早編寫一個應用時，往往都把所有的模塊都集中在一個應用程序上，並打成一個 (jar/war) 包部署到線上。(反正我是這樣)，這個方法有個明顯的好處，開發簡單，無需考慮太多後期維護的東西，使用現在市面上的SpringBoot可以快速開發出一個小型應用,這種架構也被成爲單一應用架構。但是缺點也是很明顯的，比如有一天要修改某一個需求，改完之後就要重新打包部署，比較麻煩，因爲需求這東西，改動挺頻繁的。而且當應用訪問流量大了之後，這樣子的架構就有點吃不消，因爲流量都往一臺機器上頂，誰抗的住啊.
於是慢慢出現了一種架構思想，垂直應用架構。這個架構說白了就是把編寫好的出現打包部署到多個服務器上，底層通過一些硬件負載均衡來決定它們的工作調配問題。這樣流量就從原來的都往一個服務器走，變成分散開往幾個服務器走，流量問題解決了。
隨着服務器越來越多，服務器之間的調用關係越來越複雜，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？它們之間的啓動順序也有講究，不同的服務器之間還不能亂了"輩份"…這就導致了內部負載均衡器壓力也陡增。沒關係，這個社會就是被需求所推動的嘛。於是出現了新的架構:面向服務的架構體系(SOA).將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心,同時增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率。
Dubbo就是基於該體系的實現框架，它在整個分佈式系統的架構中，按照分層的架構來架構，使得各個層級之間最大限度的鬆耦合。
Dubbo的結構
圖來自官網。
這裏各個名詞介紹一下。
首先有一個Container,它是服務運行容器，它啓動之後會加載各種Provider，服務提供者。這些Provider會把自己 註冊(register) 到註冊中心(Registry),而有了服務提供者，就會有服務消費者(Consumer),這些Consumer就會 訂閱(subscribe) 註冊中心的內容，當註冊中心有什麼服務可以提供時，就會去通知(notify) 服務消費者。服務消費者收到通知之後，就會去去找對應的服務提供者，而Monitor就是一個監控中心。它們的結構還有點像消息隊列。
整個過程也可以比喻爲一個相親過程，服務提供者比作男方，服務消費者比作女方，當男方想找女朋友時可以去婚介所(註冊中心)登記自己的信息,而女方也想找男朋友時，也去婚介所登記，婚介所會根據你的信息，給你推薦適合你的伴侶，給你他的聯繫地址。於是你就可以去尋找ta，有一場美麗的邂逅。而monitor就像是幕後的"boss",它負責監控這一過程。
這是整個Dubbo的架構，看着比較簡單，但其實裏面細節特別多，還需慢慢學習，而其中的註冊中心,Dubbo是採用Zookeeper來作爲註冊中心的。後續會慢慢記錄有關知識。