小白科普：服务那点事儿

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

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

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

（完） 

你看到的只是冰山一角， 更多精彩文章，请移步《码农翻身2016文章精华》或者《码农翻身2017上半年文章精华》

有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan  QQ: 3340792577

优秀人才不缺工作机会，只缺适合自己的好机会。但是他们往往没有精力从海量机会中找到最适合的那个。

100offer 会对平台上的人才和企业进行严格筛选，让「最好的人才」和「最好的公司」相遇。

扫描下方二维码，注册 100offer，谈谈你对下一份工作的期待。一周内，收到 5-10 个满足你要求的好机会！