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

系统刚开发的时候，所有的功能都放在一起，部署在一个机器上，这种应用被称为单体应用(monolithic application) ， 由于公司也没什么名气，流量也不大，单体应用可以轻松应对。

随着公司加大宣传力度， 流量越来越大， 这种单体应用的弊端越来越明显。

比如上周搞了一个宣传活动，注册用户送优惠券，那个用户管理的模块访问量暴涨， 小明虽然添加了几台虚拟服务器来做负载均衡应急， 但是这些新的服务器除了用户管理模块外，不得不连带其他模块一起部署(单体应用嘛)， 真是一种巨大的浪费。

小明不由地想： 要是能把用户管理单独拎出来就好了， 这样的话一个机器上就不部署别的应用了，专门部署用户管理，一个机器上可以部署好几个! 多节省机器啊。

此外，随着逻辑的增加，应用变得越来越大，快长成一个接近200M的“大胖子”了， 各个模块之间也建立了千丝万缕的联系，慢慢地业务逻辑绞成了一团，原先定义良好的接口也变得混乱不堪，每次代码修改和系统上线都是一次重大挑战。

小明向领导建议： 把各个模块拆分成小应用吧， 让他们可以独立开发，灵活的部署。

如果哪个应用流量比较大，那就多部署几个，哪个应用用得少， 就少部署几个。

每个小应用可以独立开发、部署，非常灵活。

当然，应用之间还少不了交互，每个应用都得对外提供接口让别人访问， 例如想获得一个用户的信息就得访问这个URL : http://192.168.0.10/user/

这样的每个接口可以称为服务(Service)。

可是问题来了，对于每个应用来说，如果部署了多份，每个服务也会有多个实例， 有多个URL， 到底要调用哪一个呢?

http://192.168.0.10/user/

http://192.168.0.12/user/

http://192.168.0.13/user/

更烦人的是， 刚刚调用了192.168.0.13这个机器上的服务，过了一会儿， 由于流量小，不需要那么多机器， 这个机器上的服务实例下线了，就无法进行第二次调用了。

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

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

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

注册中心(忙活了半天)： 用这个吧 http://192.168.0.12/user/， 他的负载比较小

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

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

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

但是注册中心怎么知道有哪些服务呢?

小明早已想到这一层，他让各个服务主动前来报到，注册。

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

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

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

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

他马上把这个宝图“献”给了领导， 领导看了一眼说： 这个图看着好眼熟啊， 奥，对了，我在Dubbo那里见过， 还有，当年我做SOA的时候也是用这种思路做服务的注册和查找， 看来我们现在遇到的问题和当年很类似嘛!

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

感谢大家阅读由java职场分享的“电商系统开发服务那点事”希望对大家有所帮助，更多精彩内容请关注Java培训官网

免责声明：本文由小编转载自网络，旨在分享提供阅读，版权归原作者所有，如有侵权请联系我们进行删除