一 為什么需要dubbo
很多時候，其實我們使用這個技術的時候，可能都是因為項目的需要，所以就用了，但是，至于為什么我們需要使用到這個技術，可能自身不是很了解。
在互聯網的發(fā)展過程中，在以前，我們只需要一個服務器，將程序全部打包好就可以，但是，隨著流量的增大，常規(guī)的垂直應用架構已無法應對，所以架構就發(fā)生了演變。
1，單一應用架構
2，應用和數據庫單獨部署
3，應用和數據庫集群部署
4，數據庫壓力變大，讀寫分離
5，使用緩存及時加快分離；
6，數據庫分庫分表
7，應用分為不同的類型拆分
發(fā)展到這個階段的時候，我們發(fā)現，應用與應用之間的關系已經十分的復雜了，就會出現以下的問題（以下摘錄于官網）
1，當服務越來越多時，服務URL配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大
2，當進一步發(fā)展，服務間依賴關系變得錯綜復雜，甚至分不清那個應用要在那個應用之前啟動，架構師也不能完整的描述應用的架構關系.
3,接著，服務的調用越來越大，服務的容量問題就暴露出來了，這個服務需要多少機器支撐，什么時候該加載機器？
為了解決這由于架構的演變所產生的問題，于是dubbo產生了。當然，解決這個問題的技術不止dubbo.
從上面Dubbo的服務治理圖我們可以看到，Dubbo很好的解決了上面所出現的一些問題。
所以，當你的系統(tǒng)架構發(fā)展到這種階段的時候，就需要考慮使用Dubbo了。
二 Dubbo技術架構
我們已經很清楚的知道為什么在我們的系統(tǒng)里需要dubbo這個技術了。
首先，上一張圖。
看到圖以后，可能你對上面的幾個概念還是一臉懵逼，無從下手，下面，帶你看看這幾個角色到底是什么意思？
節(jié)點角色說明：
看了這幾個概念以后似乎發(fā)現，其實Dubbo的架構也是很簡單的（其實現細節(jié)是復雜的），為什么這么說呢，有沒有發(fā)現，其實很像生產者-消費者模型。只是在這種模型上，加上了注冊中心和監(jiān)控中心，用于管理提供方便的url以及管理整個過程。
那么整個發(fā)布-訂閱的過程就非常簡單了。
啟動容器，加載，運行服務提供者，
服務提供者在啟動時，在注冊中心發(fā)布注冊自己提供的服務。
服務消費者在啟動時，在注冊中心訂閱自己所需要的服務。
