现在要做一个一个电商系统，功能无非就是用户管理、商品管理、订单管理、商品详情页、库存管理、支付管理等等。 系统刚开发的时候，所有的功能都放在一起，部署在一台机器上，这种应用称为**单体应用(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/>， 他的负载比较小 那么注册中心入何知道有哪些服务呢？ 可以让各个服务来主动报道，**注册** 而且还必须让服务定期来签到（心跳），这就是服务的注册和发现。  我们可以把调用方称为服务的消费者，用户管理、订单管理、商品管理称为服务的提供者。