api接口是復(fù)用還是拆分？這要看系統(tǒng)整體設(shè)計，如果沒有api接口所需要的功能不同就復(fù)用，要是不全部相同且使用頻率高，就表格合并出一個新的接口。怎么提高api接口的穩(wěn)定性？這個問題我就生克制化著自己的項

api接口是復(fù)用還是拆分？

這要看系統(tǒng)整體設(shè)計，如果沒有api接口所需要的功能不同就復(fù)用，要是不全部相同且使用頻率高，就表格合并出一個新的接口。

怎么提高api接口的穩(wěn)定性？

這個問題我就生克制化著自己的項目來說一說。

我們現(xiàn)在的項目是沒有前臺頁面的，只可以提供接口服務(wù)，甚至還我們項目都沒有交易類的服務(wù)，是單純的去查詢類服務(wù)。項目曾經(jīng)在的建設(shè)目標(biāo)應(yīng)該是就是為了只能緩解核心系統(tǒng)數(shù)據(jù)查詢的壓力，或是你們是可以把我們項目積乘幾個核心項目的緩存層(畢竟有多個核心系統(tǒng)，我們項目還是可以能提供不同系統(tǒng)的查詢，這一點(diǎn)也很不重要)。

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

我們項目常規(guī)了關(guān)系型數(shù)據(jù)庫做中間庫，數(shù)據(jù)經(jīng)由需要加工后落下時到MongoDB和Redis，組織的提供的服務(wù)，只會去查詢MongoDB和Redis；

數(shù)據(jù)加工很重要的是，關(guān)系型數(shù)據(jù)庫中不需要多表關(guān)聯(lián)的查詢，現(xiàn)在只可以查詢MongoDB的一個collection就可以了。（只不過去做數(shù)據(jù)加工，因此數(shù)據(jù)和生產(chǎn)庫比，有當(dāng)然的延遲，這個一定要看業(yè)務(wù)場景是否是不允許有服務(wù)器延遲）；

MongoDB采用副本集分片的部署，副本集可以保證數(shù)據(jù)庫的穩(wěn)定性，死干凈一臺，有其他幾臺這個可以使用；分片只要數(shù)據(jù)量速度變大后，可以垂直內(nèi)存量。（現(xiàn)在數(shù)據(jù)量大致在億級，個位數(shù)）；

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

不是很嚴(yán)的參數(shù)校驗，以免做無用之功的查詢；

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

除開自身架構(gòu)之外，還很是非自身的控制：

內(nèi)部系統(tǒng)在動態(tài)創(chuàng)建接口的時候，通常按照網(wǎng)絡(luò)權(quán)限的控制，除了不做任何的限制，除了鑒權(quán)；

如果不是是互聯(lián)網(wǎng)端的接入，我還是不需要依賴感網(wǎng)關(guān)；由網(wǎng)關(guān)做鑒權(quán)、人員限流、改名、被熔斷等；

組織對方系統(tǒng)功能的設(shè)計（這件事很神奇無比），是因為大多數(shù)時候也是公司內(nèi)部的系統(tǒng)，所以我在做需求繼續(xù)討論的時候，最好是想看幫一下忙對方系統(tǒng)的調(diào)用場景；很可能會根據(jù)情況下什么時候動態(tài)創(chuàng)建接口，就能極大降低接口的調(diào)用次數(shù)；

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

假如這個可以的話，最好是這個可以區(qū)分異步運(yùn)行動態(tài)創(chuàng)建的機(jī)制；

如果不是接口要依賴于同時系統(tǒng)的接口，也需要額外的做一些考慮（依賴的接口前往慢或是出現(xiàn)錯誤，自己的接口絕對會有問題）；比如說數(shù)據(jù)時效性要求不高的話，也可以考慮到把對方接口趕往的數(shù)據(jù)緩存下了（設(shè)置失效時間，可以保證過一段時間能把2011版的數(shù)據(jù)手動刷新回去），但如果數(shù)據(jù)時效性要求太高，是可以判斷在用熔斷；但是說實話，才剛看到過誰敢用觸發(fā)熔斷機(jī)制的....

希望我的回答，能幫助到你！我將堅持了分享Java開發(fā)、架構(gòu)設(shè)計、程序員職業(yè)發(fā)展等方面的見解，希望能能得到你的關(guān)注。