接口設計須要考慮哪些方面

接口設計須要考慮哪些方面

1.接口的命名。

2.請求參數。

3.支持的協議。

4.TPS、併發數、響應時長。

5.數據存儲。DB選型、緩存選型。

6.是否須要依賴於第三方。

7.接口是否拆分。

8.接口是否須要冪等。

9.防刷。

10.接口限流、降級。

11.負載均衡器支持。

12.如何部署。

13.是否須要服務治理。

14.是否存在單點。

15.接口是否資源包、預加載仍是內置。

16.是否須要本地緩存。

17.是否須要分佈式緩存、緩存穿透怎麼辦。

18.是否須要白名單。

當咱們設計接口，咱們或多或少都會有上面列舉的一些考慮，咱們只有想的更多才能讓讓咱們的接口更加完善，我我的以爲100%完美的接口是不存在，只有適合纔是最重要。

 

接口設計原則

原則一：必須符合Restful，統一返回格式，約定業務層錯誤編碼，每一個編碼能夠攜帶可選的錯誤信息。

原則二： 命名必須規範、優雅。

原則三：單一性。

單一性是指接口要作的事情應該是一個比較單一的事情，好比登錄接口，登錄完成應該只是返回登錄成功之後一些用戶信息便可，但不少人爲了減小接口交互，返回一大堆額外的數據。

好比有人設計一個用戶列表接口，接口他返回每一條數據都是包含用戶了一大堆跟另外無關的數據，結果一問，原來其餘無關的數據是他下一步想要獲取的，想達成數據的懶加載。

原則四：可擴展。

接口擴展性，是指設計接口的時候多想一想多種狀況，多考慮各個方面，其實我以爲單獨將擴展性放在這裏也是不妥的，感受說的跟單一性有點相反的意思，其實這個不是這個意思。

這邊的擴展性是指咱們的接口充分考慮客戶端，想一想他們是如何調用的，他要怎樣使用個人代碼，他會如何擴展個人代碼，不要把過多的工做寫在你的接口裏面，而應該把更多的主動權交給客戶程序員。

如獲取不一樣的列表數據接口，咱們不可能將每一個列表都寫成一個接口。 還有一點，我這裏特別想指出來的是不少開發人員爲了省事（姑且只能這麼理解），將接口設計當成只是 app 頁面展現。

這些人將一個頁面展現就用一個接口實現，而不考慮這些數據是否是屬於不一樣的模塊、是否是屬於不一樣的展現範疇、結果下次視覺一改，整個接口又得重寫，不能複用。

原則五：必須有文檔。

良好的接口設計，離不開清晰的接口文檔表述。文檔表述必定要足夠詳細

原則六：產品心。
原則七：第三方服務接口數據能緩存就緩存。

原則八：第三方服務須要作降級。

原則九：建議消除單點。

原則十：接口粒度要小。

原則十一：客戶端能處理的邏輯就不要給服務端處理，減小服務端壓力。

原則十二：資源預加載。

原則十三：不要過分設計。

原則十四：緩存儘可能不要穿透。

原則十五：接口能緩存就緩存。

原則十六：思辨大於執行
高性能：若是咱們發現這個接口tps和響應時間沒有達到咱們的要求怎麼辦。

A：數據存儲方面：咱們會想數據庫有沒有分庫、分表、有沒有作主從，有沒有讀寫分離、字段是否有加索引、是否存在慢 sql，數據庫引擎是否選用合適、是否是用了事務；

其次咱們會想到是否是引用了分佈式緩存、緩存 key 大小是否合適，失效時間是否設置合理，會不會大量緩存穿透、有沒有引入本地緩存。

B：業務方面：是否有大量的計算、可否異步處理。是否須要引入線程池或者 MQ 來異步處理任務。有沒有必要將接口進行垂直拆分和水平拆分、將接口粒度變小。

C：其餘方面：nginx 層面作緩存、加機器、用 ssd，資源放 cdn，多機房部署、資源文件預加載。
高可用：如何保證服務高可用，須要從幾個維度來實現：

A：消除單點，基於高可用第二位。

B：能作集羣的所有作集羣。譬如 Redis 集羣、mysql集羣、MongoDB副本集。

C：能作讀寫分離的都作讀寫分離。

D：異地多機房部署，接入 GSLB

E：必須有限流、降級機制。

F：監控。高可用的保證，基於第一位。