小明的公司向電子商務領域進軍，開發了一個電商系統，功能沒什麼新奇的，無非就是用戶管理、商品管理、訂單管理、商品詳情頁、庫存管理、支付管理等等。
系統剛開發的時候，所有的功能都放在一起，部署在一個機器上，這種應用被稱爲單體應用（monolithic application） ， 由於公司也沒什麼名氣，流量也不大，單體應用可以輕鬆應對。
隨着公司加大宣傳力度， 流量越來越大， 這種單體應用的弊端越來越明顯。
比如上週搞了一個宣傳活動，註冊用戶送優惠券，那個用戶管理的模塊訪問量暴漲， 小明雖然添加了幾臺虛擬服務器來做負載均衡應急， 但是這些新的服務器除了用戶管理模塊外，不得不連帶其他模塊一起部署（單體應用嘛）， 真是一種巨大的浪費。
小明不由地想： 要是能把用戶管理單獨拎出來就好了， 這樣的話一個機器上就不部署別的應用了，專門部署用戶管理，一個機器上可以部署好幾個！ 多節省機器啊。
此外，隨着邏輯的增加，應用變得越來越大，快長成一個接近200M的“大胖子”了， 各個模塊之間也建立了千絲萬縷的聯繫，慢慢地業務邏輯絞成了一團，原先定義良好的接口也變得混亂不堪，每次代碼修改和系統上線都是一次重大挑戰。
小明向領導建議： 把各個模塊拆分成小應用吧， 讓他們可以獨立開發，靈活的部署。
如果哪個應用流量比較大，那就多部署幾個，哪個應用用得少， 就少部署幾個。
每個小應用可以獨立開發、部署，非常靈活。
當然，應用之間還少不了交互，每個應用都得對外提供接口讓別人訪問， 例如想獲得一個用戶的信息就得訪問這個URL : http://192.168.0.10/user/<userID>
這樣的每個接口可以稱爲服務(Service)。
可是問題來了，對於每個應用來說，如果部署了多份，每個服務也會有多個實例， 有多個URL， 到底要調用哪一個呢？
http://192.168.0.10/user/<userID>
http://192.168.0.12/user/<userID>
http://192.168.0.13/user/<userID>
更煩人的是， 剛剛調用了192.168.0.13這個機器上的服務，過了一會兒， 由於流量小，不需要那麼多機器， 這個機器上的服務實例下線了，就無法進行第二次調用了。
看來一個應用不能和特定機器上的服務綁死啊！
小明想了一個辦法： 想要調用服務之前，先在一個叫做註冊中心的地方根據名稱查找一個服務，比如想查看用戶信息了，可以這麼幹：
支付管理：給哥們來個getUserInfo的服務！
註冊中心（忙活了半天）： 用這個吧 http://192.168.0.12/user/<userID>， 他的負載比較小
......支付管理開心地使用.....
支付管理：再給哥們來個getUserInfo的服務
註冊中心： 用這個吧 http://192.168.0.13/user/<userID>， 剛纔那個半天都不給我聯繫了，估計是下線了。
但是註冊中心怎麼知道有哪些服務呢？
小明早已想到這一層，他讓各個服務主動前來報到，註冊。
註冊了還不算完， 各個服務必須定期前來簽到（行業黑話叫做心跳），讓註冊中心知道服務還活着。
這種辦法其實就叫做服務的註冊和發現。
小明充分發揮了抽象的能力，他把調用方稱爲服務的消費者（Consumer）, 用戶管理、訂單管理、商品管理這些應用稱爲服務提供者(Provider)， 得到了下面這個圖：
小明很得意：“看看我這個抽象多漂亮！”
他馬上把這個寶圖“獻”給了領導， 領導看了一眼說： 這個圖看着好眼熟啊， 奧，對了，我在Dubbo那裏見過， 還有，當年我做SOA的時候也是用這種思路做服務的註冊和查找， 看來我們現在遇到的問題和當年很類似嘛！
小明聽了以後有點失望，失望之餘又大爲感慨： 看來我又造了一次輪子，技術在變， 但是基本的思想一直沒變啊！