今天同一个大牛聊天，聊到微服务的发布这个话题。就以我司微服务架构为例，我们是使用spring cloud来构建的，各微服务之间注册于发现是通过consul组件来完成，各微服务通过心跳同consul保持联系。那么问题来了，我们发布的过程中，发布的间隙，总会造成当前发布处在发布过程中而造成服务不可用或者调用的超时，这个问题如何解决。
想想现阶段，确实会存在此类的问题，但是由于业务量较少，这种问题造成的影响其实还不明显，但是对于体量大一些比如说阿里，腾讯，滴滴这种，出现此类问题影响的可能会是成千上万的用户，那么这个问题就变成了必须要解决的问题。
对于大数据量的项目发布，一般情况下回逐台发布，因为如果同时发布，那么此时你的这个服务整体都是不可用的，所以肯定不行。即使这样也是远远不够的，因为常见的微服务的并非真正进行远程调用的时候才会拉取配置中心的数据，而是定时同步，比如说设置的时间为30s。比如说A服务调用B服务，B服务有两个事例分别是b1与b2，A服务刚从consul上同步了B的服务的信息，此时b1挂掉了，那么对于A来说是无感知的（未到下次同步的时间），那么此时调用的时候就会有问题（这种情况可能出现在发布，也有可能出现在日常生活中，他就是突然DOWN掉了）。
情景描述完了，再说一下解决。两种方式，第一种，重写调用的策略，当发现b1调用有问题的时候，尝试使用b2来调用。这种方式多了一次调用，好在撑过下次同步的时间就好了（更新数据了）。第二种方式是大牛提供的，比较精妙一点，叫做“服务假死”。比如说我想要重启b1,那么b1发送一个死亡的消息给到consul,实际上没有死，那么A服务调用到b1时还是可以提供服务（因为是假死）。等到下次同步的时间拉取B服务的列表就只用b2没有b1了，因为consul认为b1死了。也就是说当b1发出假死信号后，一个查询周期之内，服务正常提供，一个周期之外，因为没有这个节点的信息了，所以当然可以重启了，对系统来说也是没有影响的。
这个思考到了这里就接近了尾声，解决这个问题的思路还有很多，如果有更好的，不妨给出你的，咱们一起讨论。
作者：数齐
链接：https://www.jianshu.com/p/288510dafe33
共同学习，写下你的评论
评论加载中...
作者其他优质文章
