現在要做一個一個電商系統，功能無非就是用戶管理、商品管理、訂單管理、商品詳情頁、庫存管理、支付管理等等。
系統剛開發的時候，所有的功能都放在一起，部署在一臺機器上，這種應用稱為**單體應用(monolithic application)**
隨著流量越來越大，這種單體應用的弊端越來越明顯了。為了應對大流量，可以使用多臺虛擬服務器來負載均衡。但是這種服務器除了用戶管理模塊外，還需要連帶其他的模塊來一起部署。
很自然就可以想到，如果把用戶管理單獨拎出來，使用一臺服務器專門部署用戶管理，一臺機器上可以部署若干。
另外，隨著邏輯的增加，應用越來越大，各個模塊之間的聯系也是千絲萬縷，慢慢得業務邏輯的絞成了一塊，每次代碼修改和上線都很痛苦。
那么能否把各個模塊都拆分成小應用，獨立開發，靈活部署呢？哪個應用流量大，就可以多部署幾個
每個應用都得對外提供接口，以便別人來訪問，比如要獲得一個用戶信息就可以訪問：http://192.168.0.10/user/>
每個接口就可以稱為**服務**
當然問題也來了，對于一個應用來說，如果部署了多份，每個服務也會有多個實例，有多個URL。到底調用哪一個呢？
http://192.168.0.10/user/<userID>
http://192.168.0.12/user/<userID>
http://192.168.0.13/user/<userID>
甚至說，由于流量小了，不需要那么多機器了，這個機器的服務實例下線后，就無法進行第二次調用了。
所以說，一個應用不能和特定的機器上的服務綁死。
## 注冊中心
那么可以在調用服務之前，先在一個**注冊中心**的地方根據名稱查找一個服務，比如想看用戶信息，可以調用getUserInfo，然后注冊中心返回 http://192.168.0.12/user/>， 他的負載比較小
那么注冊中心入何知道有哪些服務呢？
可以讓各個服務來主動報道，**注冊**
而且還必須讓服務定期來簽到（心跳），這就是服務的注冊和發現。
我們可以把調用方稱為服務的消費者，用戶管理、訂單管理、商品管理稱為服務的提供者。
