科普贴——什么是“服务”

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

        系统刚开发的时候，所有的功能都放在一起，部署在一个机器上，这种应用被称为单体应用（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这个机器上的服务，过了一会儿， 由于流量小，不需要那么多机器， 这个机器上的服务实例下线了，就无法进行第二次调用了。#d52:

        看来一个应用不能和特定机器上的服务绑死啊！

👨‍🎨‍💍🖲😷👍

        小明想了一个办法： 想要调用服务之前，先在一个叫做注册中心的地方根据名称查找一个服务，比如想查看用户信息了，可以这么干：

        支付管理：给哥们来个getUserInfo的服务！

👊🍖📳🦕‍        注册中心（忙活了半天）： 用这个吧 http://192.168.0.12/user/<userID>， 他的负载比较小。

        ......支付管理开心地使用.....

        支付管理：再给哥们来个getUserInfo的服务。🧑‍🌾‏👔🔍😆✋

        注册中心： 用这个吧 http://192.168.0.13/user/<userID>， 刚才那个半天都不给我联系了，估计是下线了。


        但是注册中心怎么知道有哪些服务呢？  
✊🛩🍽🈷🦖‏
        小明早已想到这一层，他让各个服务主动前来报到，注册。

        注册了还不算完， 各个服务必须定期前来签到（行业黑话叫做心跳），让注册中心知道服务还活着。

👩‍🎒🩺☠👃

        这种办法其实就叫做服务的注册和发现。

        小明充分发挥了抽象的能力，他把调用方称为服务的消费者（Consumer）, 用户管理、订单管理、商品管理这些应用称为服务提供者(Provider)， 得到了下面这个图：

🧑‍💻‌👒📞😷🤞

        小明很得意：“看看我这个抽象多漂亮！”

        他马上把这个宝图“献”给了领导， 领导看了一眼说： 这个图看着好眼熟啊， 奥，对了，我在Dubbo那里见过， 还有，当年我做SOA的时候也是用这种思路做服务的注册和查找， 看来我们现在遇到的问题和当年很类似嘛！
👨‍🎨‎🧦🎷🥰🤝
        小明听了以后有点失望，失望之余又大为感慨： 看来我又造了一次轮子，技术在变， 但是基本的思想一直没变啊！