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

api接口是復用還是拆分？

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

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

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

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

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

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

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

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

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

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

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

除開自身架構之外，還很是非自身的控制：

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

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

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

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

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

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

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