怎麼提高api接口的穩定性？

2019-12-25 02:44:35 佚名

這個問題我就結合著自己的項目來說一說。

我們現在的項目是沒有前臺頁面的，只對外提供接口服務，甚至我們項目都沒有交易類的服務，都是單純的查詢類服務。項目最初的建設目標就是為了緩解核心系統數據查詢的壓力，或者你們可以把我們項目看成幾個核心項目的緩存層(因為有多個核心繫統，我們項目還可以提供跨系統的查詢，這一點也很重要)。

打鐵還需自身硬，要提高接口的穩定性和響應速度，首先代碼要寫好：

我們項目採用了關係型數據庫做中間庫，數據經過加工後落地到MongoDB和Redis，對外的提供的服務，只會查詢MongoDB和Redis；
數據加工很重要，關係型數據庫中需要多表關聯的查詢，現在只查詢MongoDB的一個collection就可以了。（因為要做數據加工，所以數據和生產庫比，有一定的延遲，這個一定要看業務場景是否允許有延遲）；
MongoDB採用副本集+分片的方式部署，副本集保證數據庫的穩定性，掛掉一臺，還有其他幾臺可以使用；分片保證數據量增大後，可以平行擴容。（現在數據量大概在億級，個位數）；
服務部署還採用比較傳統的方式，N臺服務器前面掛負載均衡；上各種監控，隨時關注接口調用和資源使用情況；
嚴格的參數校驗，避免做無用的查詢；
大原則就是：【能查緩存就不要查數據庫，能不查的話就更好】

除了自身架構之外，還有些非自身的控制：

內部系統在調用接口的時候，主要通過網絡權限的控制，除此之外不做任何的限制，包括鑑權；
如果是互聯網端的接入，還是需要依賴網關；由網關做鑑權、限流、降級、熔斷等；
參與對方系統功能的設計（這一點很神奇），因為大多數時候都是公司內部的系統，所以在做需求討論的時候，最好能看一下對方系統的調用場景；很有可能調整一下什麼時候調用接口，就能大大減少接口的調用次數；
建議調用方設置合理的超時時間，並有合理的重試機制；
如果可以的話，最好可以採用異步調用的機制；
如果接口要依賴於另外系統的接口，也需要額外的做一些考慮（依賴的接口返回慢或者報錯，自己的接口肯定會有問題）；比如數據時效性要求不高的話，可以考慮把對方接口返回的數據緩存下來（設置失效時間，保證一段時間後能把最新的數據刷新回來），但如果數據時效性要求非常高，可以考慮使用熔斷；不過說實話，還沒見過誰敢用熔斷的....

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

在日常的開發工作中，API隨處可見，現在市面上也有專門的數據類公司提供各種各樣的API服務。API的穩定性直接關係到應用的穩定，那該如何提高API接口的穩定性呢？下面我來逐步和大家講解一下以供參考。

API是應用程序編程接口的簡稱，其實可以理解為是某種服務的一種封裝形式，通過API就可以獲得某種服務而不需要了解其內部實現原理，基本上每款軟件應用都有自己的API，供內部或外部調用。

API本身也是屬於應用軟件（開發人員通過編程語言開發的），它的表現形式有很多種，主要的有：

API性能會受到很多因素影響的，比如說：

1、API的高可用方案

什麼是高可用呢？高可用是指通過一些技術手段，避免服務出現異常、或減少異常導致的服務不可用時間。

API部署時也需要考慮高可用，我們推薦的方案是：

2、API的性能優化

API其實也是一種應用，同樣是由開發人員開發的，因為API充當的是服務的核心，所以API的性能尤為重要，我們在開發API時需要注意以下幾點：

3、API訪問速度優化

如果API是公司內部使用，建議以內網IP形式訪問API服務；如果API也對外提供服務，可考慮將服務器部署在BGP機房，如果機房不在BGP機房建議在API層上方走CDN加速。

以上就是我的觀點，對於這個問題大家是怎麼看待的呢？歡迎在下方評論區交流 ~ 我是科技領域創作者，十年互聯網從業經驗，歡迎關注我瞭解更多科技知識！

看你的接口涉及哪些方面，比如數據庫，緩存，或者依賴第三方接口，先從自身代碼優化起，然後一步步優化下去，怎麼減少變數，比如數據庫掛了接口能不能正常，緩存掛了接口邏輯怎麼處理，第三方接口老超時不穩定代碼應該怎麼走。

分享到: