小白科普：服务那点事儿

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

 

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

 

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

https://mp.weixin.qq.com/s__biz=MzAxOTc0NzExNg==&mid=2665513878&idx=1&sn=77ed2822b409fb5c2e579874f12350af&chksm=80d67bd5b7a1f2c3c58cbeb409a1498b81caf53acd0f1153bc2e03c46ae8d5609c8b370fcf05&scene=21#wechat_redirect