可靠性99.999%互联网微服务的架构设计

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/phil_code/article/details/52056564

 

这个微服务是我负责的某大型app一个重要的微服务,并发量峰值是5000/秒,微服务的信息需要调用外部业务服务器获取信息,且要调用四个外部业务器的接口四次才能返回完整的信息。

 

第一个版本:


由于业务服务器不是我们负责的,对方的研发人员基于一些原因,不愿意提供一个完整信息的接口给我们,因此需要通过四次远程调用接口才能获取到完整信息,可靠性和性能大大打折。

 

为了提供可靠性和性能,增加了一层缓存器,缓存时间为30秒,先从30秒缓存服务器查询,如果没有命中缓存,再去外部业务服务器查询。缓存服务器是公司自研的,实现了在不同机房之间的缓存数据同步。

第二个版本:

 

 

由于缓存的数据生效时长是30秒,当缓存数据失效,查询外部业务服务器也失败或者超时的情况下,这个微服务就挂掉了,研发人员也得背锅了。因此再加多一层永久缓存服务器。每次从外部业务部器查询到数据后,同时把数据保存到30秒缓存服务器和永久缓存服务器,两个缓存服务器的生效时长不一样,一个是30秒,一个是永久。

 

当失败超过50次时,就会使用永久缓存服务器代替30秒缓存服务器,永久缓存服务器的数据是一直不过期,如果长时间使用,会导致查询到的数据不是最新的。因此在后台程序定时去清空失败计数器,当失败计数器为0时,又使用回30秒缓存服务器。


 

上面已经保证了后端的程序高可用性,根据监控数据可靠性达到99.9994%,但是还存在一层容易出问题的地方,就是在手机app与业务服务器之间,可能由于网络原因导致失败或者超时。

该服务是查询界面的模板ID,业务上有几种模板,其中有一种是默认模板。

当app调用业务器超时或者失败的情况,客户端将当做默认模板处理,保证用户可以使用页面的精简功能点。

阅读更多
换一批

没有更多推荐了,返回首页