一年半以前，我在一家創業公司從事伺服器端開發工作，雖然當時公司已經拿到了6000w的A輪融資，並且App已經有超過百萬的日活，開發團隊已經有10幾個人。但是看一眼伺服器的程式碼，卻感覺和筆者本科時候做的“學生管理”系統沒什麼兩樣。所有的伺服器程式碼，都在一個JavaWeb工程裡，然後被打包成War，使用Tomcat部署。為了應對增長的活躍使用者，使用Haproxy做了負載均衡，同樣的war包會在5-10臺左右的高效能機器上部署，感覺應對當時的日活並沒有太大問題。

當時公司的業務分大概幾個模組：
1. 一個是廣告分發業務，使用者會定期收到推過來的廣告，當然有一些複雜的機制來決定使用者看到什麼廣告。
2. 積分系統，使用者通過瀏覽廣告，可以賺取積分。
3. 商場系統，使用者可以用積分換取商場裡的物品。

雖然業務聽起來不是很多，但是因為業務模式比較複雜，程式碼也是極為龐大，而所有的一切都在一個工程中。雖然程式碼也是按照Controller， Service，DAO這樣橫向拆分，也按照Package做了很好的分割。但是依然維護和繼續開發這一坨東西，讓我日漸有一種忍無可忍的感覺。

1. 從開發角度說，面對這麼一坨龐大的程式碼，維護成本和新人學習成本都是特別高的。
2. 程式碼保護性很差，如果公司來了一個實習生，我不想讓他看到所有程式碼，但是又想讓他做一些相關的功能，都幾乎不太可能。
3. 程式碼構建的時間越來越長，每一個小小的改動，都會觸發所有程式碼的構建，程式設計師如此貴的今天，如果讓老闆知道，肯定眼淚掉下來。
4. 釋出成本也很高，先不說龐大的war包重啟需要更長時間，每次一個小改動就要重新部署所有功能，也是非常頭疼的事情。因為有些核心功能，需要全天服務使用者，所以白天幾乎不可能重啟服務。而釋出一個無關緊要的功能，也要守候到凌晨，真是覺得這個世界充滿惡意。
5. 即使可以通過 LBS 增強伺服器響應，但是確完全不能根據不同的業務做擴容，每次增加機器都要考慮整個War的感受，額外提高的裝置成本。

經過大量調查和探索，我們走上了微服務架構這條路。

簡而言之，微服務架構就是按照業務，將服務拆分到不同的程式（程序），單獨部署，釋出。
可以看圖，曾經的架構-單塊架構，可以這樣理解：

所有的程式都是在一個war包中，是一個單獨的程序。
而微服務則可以表現為：

其中每個Service可以理解成針對不同的業務做的拆分，每個 Service 單獨部署，執行為獨立的程式。

在我們當時的系統中，就把整個系統拆分成，廣告服務，商城服務，積分服務，賬號服務。 而和App做互動的部分－對應圖中的WebUI，這個工程是一個 Java Web 工程，打包成 war 用來處理 App 請求。
實際中，我們的部署要遠遠比圖中所畫複雜，部署服務的機器超過6臺，每臺伺服器執行2-3個服務，而這些服務通過註冊中心註冊自己的存在，服務消費者（consumer, 圖中的web ui）可以發現並呼叫這些服務。當某些服務，訪問日漸變多（例如商城最近生意越來越好），我們可以直接增加機器，多部署一些商城服務，就可以直接提高系統的處理能力。

那標題裡的Dubbo到底在哪，根據上面筆者的描述，你會發現，部署成微服務需要額外的通訊手段，連線服務提供者，和服務消費者。在單塊架構中，服務的呼叫是通過程式呼叫。而在微服務架構中，呼叫是通過Http請求的方式來執行程式呼叫。那麼問題來了，對於服務消費者，如何發現服務的存在，如何呼叫服務，呼叫服務的協議如何規定，沒有得到返回如何重試。 這就是Dubbo所解決的問題，也是她可以作為框架的原因。

當這套方案Work以後，我們覺得很興奮，架構的升級後，帶來的效果還是立竿見影的。當然也在實踐中遇到額外問題，例如mybatis本地快取在不同服務的不一致問題，處理資料一致性需要的額外代價等問題，後面我會一一探討採用微服務遇到的問題和我們的解決方案。

長篇大論的介紹微服務的優勢，並不是本系列文章的目的，因為這樣的文章很多。筆者更希望提供一些可實施的乾貨，無論從理論基礎，還是從實踐部署中，遠離群眾的空談，我覺得不適合我寫系列文章的目的。在這系列的文章裡，我會呈現下面的內容：

1. 首先會給出一份真實的程式碼，搭建出一份基於本地呼叫的Dubbo微服務框架。
2. 使用Zookeeper，使程式支援註冊中心，支援熱拓展。搭建Dubbo monitor，讓你更直觀的理解所有服務，消費者的關係。
你會發現用了這套方案，你可以瞬間提高你的伺服器對併發對處理能力。
3. 從整體架構上，理解Dobbo。
4. 閱讀程式碼，研究Dubbo 服務提供者（Provider）的實現原理
5. 閱讀程式碼，研究Dubbo 服務消費者（Consumer）的實現原理

當然，這是規劃的最核心內容，也可能呈現更多內容！
傳送門：http://sunrising.me/?p=111