這個(gè)問題我就結(jié)合著自己的項(xiàng)目來說一說。

我們現(xiàn)在的項(xiàng)目是沒有前臺(tái)頁面的，只對(duì)外提供接口服務(wù)，甚至我們項(xiàng)目都沒有交易類的服務(wù)，都是單純的查詢類服務(wù)。項(xiàng)目最初的建設(shè)目標(biāo)就是為了緩解核心系統(tǒng)數(shù)據(jù)查詢的壓力，或者你們可以把我們項(xiàng)目看成幾個(gè)核心項(xiàng)目的緩存層(因?yàn)橛卸鄠€(gè)核心系統(tǒng)，我們項(xiàng)目還可以提供跨系統(tǒng)的查詢，這一點(diǎn)也很重要)。

打鐵還需自身硬，要提高接口的穩(wěn)定性和響應(yīng)速度，首先代碼要寫好：

• 我們項(xiàng)目采用了關(guān)系型數(shù)據(jù)庫做中間庫，數(shù)據(jù)經(jīng)過加工后落地到MongoDB和Redis，對(duì)外的提供的服務(wù)，只會(huì)查詢MongoDB和Redis；
  

• 數(shù)據(jù)加工很重要，關(guān)系型數(shù)據(jù)庫中需要多表關(guān)聯(lián)的查詢，現(xiàn)在只查詢MongoDB的一個(gè)collection就可以了。（因?yàn)橐鰯?shù)據(jù)加工，所以數(shù)據(jù)和生產(chǎn)庫比，有一定的延遲，這個(gè)一定要看業(yè)務(wù)場景是否允許有延遲）；
  

• MongoDB采用副本集+分片的方式部署，副本集保證數(shù)據(jù)庫的穩(wěn)定性，掛掉一臺(tái)，還有其他幾臺(tái)可以使用；分片保證數(shù)據(jù)量增大后，可以平行擴(kuò)容。（現(xiàn)在數(shù)據(jù)量大概在億級(jí)，個(gè)位數(shù)）；
  

• 服務(wù)部署還采用比較傳統(tǒng)的方式，N臺(tái)服務(wù)器前面掛負(fù)載均衡；上各種監(jiān)控，隨時(shí)關(guān)注接口調(diào)用和資源使用情況；
  

• 嚴(yán)格的參數(shù)校驗(yàn)，避免做無用的查詢；
  

• 大原則就是：【能查緩存就不要查數(shù)據(jù)庫，能不查的話就更好】
  

除了自身架構(gòu)之外，還有些非自身的控制：

• 內(nèi)部系統(tǒng)在調(diào)用接口的時(shí)候，主要通過網(wǎng)絡(luò)權(quán)限的控制，除此之外不做任何的限制，包括鑒權(quán)；
  

• 如果是互聯(lián)網(wǎng)端的接入，還是需要依賴網(wǎng)關(guān)；由網(wǎng)關(guān)做鑒權(quán)、限流、降級(jí)、熔斷等；
  

• 參與對(duì)方系統(tǒng)功能的設(shè)計(jì)（這一點(diǎn)很神奇），因?yàn)榇蠖鄶?shù)時(shí)候都是公司內(nèi)部的系統(tǒng)，所以在做需求討論的時(shí)候，最好能看一下對(duì)方系統(tǒng)的調(diào)用場景；很有可能調(diào)整一下什么時(shí)候調(diào)用接口，就能大大減少接口的調(diào)用次數(shù)；
  

• 建議調(diào)用方設(shè)置合理的超時(shí)時(shí)間，并有合理的重試機(jī)制；
  

• 如果可以的話，最好可以采用異步調(diào)用的機(jī)制；
  

• 如果接口要依賴于另外系統(tǒng)的接口，也需要額外的做一些考慮（依賴的接口返回慢或者報(bào)錯(cuò)，自己的接口肯定會(huì)有問題）；比如數(shù)據(jù)時(shí)效性要求不高的話，可以考慮把對(duì)方接口返回的數(shù)據(jù)緩存下來（設(shè)置失效時(shí)間，保證一段時(shí)間后能把最新的數(shù)據(jù)刷新回來），但如果數(shù)據(jù)時(shí)效性要求非常高，可以考慮使用熔斷；不過說實(shí)話，還沒見過誰敢用熔斷的....