Question

小明的公司向电子商务领域进军，开发了一个电商系统，功能没什么新奇的，无非就是用户管理、商品管理、订单管理、商品详情页、库存管理、支付管理等等。

系统刚开发的时候，所有的功能都放在一起，部署在一个机器上，这种应用被称为 单体应用（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 的时候也是用这种思路做服务的注册和查找， 看来我们现在遇到的问题和当年很类似嘛！

小明听了以后有点失望，失望之余又大为感慨： 看来我又造了一次轮子，技术在变， 但是基本的思想一直没变啊！