这个微服务是我负责的某大型app一个重要的微服务，并发量峰值是5000/秒，微服务的信息需要调用外部业务服务器获取信息，且要调用四个外部业务器的接口四次才能返回完整的信息。
第一个版本：
由于业务服务器不是我们负责的，对方的研发人员基于一些原因，不愿意提供一个完整信息的接口给我们，因此需要通过四次远程调用接口才能获取到完整信息，可靠性和性能大大打折。
为了提供可靠性和性能，增加了一层缓存器，缓存时间为30秒，先从30秒缓存服务器查询，如果没有命中缓存，再去外部业务服务器查询。缓存服务器是公司自研的，实现了在不同机房之间的缓存数据同步。
第二个版本：
由于缓存的数据生效时长是30秒，当缓存数据失效，查询外部业务服务器也失败或者超时的情况下，这个微服务就挂掉了，研发人员也得背锅了。因此再加多一层永久缓存服务器。每次从外部业务部器查询到数据后，同时把数据保存到30秒缓存服务器和永久缓存服务器，两个缓存服务器的生效时长不一样，一个是30秒，一个是永久。
当失败超过50次时，就会使用永久缓存服务器代替30秒缓存服务器，永久缓存服务器的数据是一直不过期，如果长时间使用，会导致查询到的数据不是最新的。因此在后台程序定时去清空失败计数器，当失败计数器为0时，又使用回30秒缓存服务器。
上面已经保证了后端的程序高可用性，根据监控数据可靠性达到99.9994%，但是还存在一层容易出问题的地方，就是在手机app与业务服务器之间，可能由于网络原因导致失败或者超时。
该服务是查询界面的模板ID，业务上有几种模板，其中有一种是默认模板。
当app调用业务器超时或者失败的情况，客户端将当做默认模板处理，保证用户可以使用页面的精简功能点。
