這個微服務是我負責的某大型app一個重要的微服務，并發量峰值是5000/秒，微服務的信息需要調用外部業務服務器獲取信息，且要調用四個外部業務器的接口四次才能返回完整的信息。

第一個版本：

由于業務服務器不是我們負責的，對方的研發人員基于一些原因，不愿意提供一個完整信息的接口給我們，因此需要通過四次遠程調用接口才能獲取到完整信息，可靠性和性能大大打折。

為了提供可靠性和性能，增加了一層緩存器，緩存時間為30秒，先從30秒緩存服務器查詢，如果沒有命中緩存，再去外部業務服務器查詢。緩存服務器是公司自研的，實現了在不同機房之間的緩存數據同步。

第二個版本：

由于緩存的數據生效時長是30秒，當緩存數據失效，查詢外部業務服務器也失敗或者超時的情況下，這個微服務就掛掉了，研發人員也得背鍋了。因此再加多一層永久緩存服務器。每次從外部業務部器查詢到數據后，同時把數據保存到30秒緩存服務器和永久緩存服務器，兩個緩存服務器的生效時長不一樣，一個是30秒，一個是永久。

當失敗超過50次時，就會使用永久緩存服務器代替30秒緩存服務器，永久緩存服務器的數據是一直不過期，如果長時間使用，會導致查詢到的數據不是最新的。因此在后臺程序定時去清空失敗計數器，當失敗計數器為0時，又使用回30秒緩存服務器。

上面已經保證了后端的程序高可用性，根據監控數據可靠性達到99.9994%，但是還存在一層容易出問題的地方，就是在手機app與業務服務器之間，可能由于網絡原因導致失敗或者超時。

該服務是查詢界面的模板ID，業務上有幾種模板，其中有一種是默認模板。

當app調用業務器超時或者失敗的情況，客戶端將當做默認模板處理，保證用戶可以使用頁面的精簡功能點。