我們在開發過程中，當然是希望自己項目接口的響應時間越短越好，至少我看着自己開發出來的代碼，都是毫秒級的響應，會有一種自豪感；那麼我們項目做了哪些優化，和大家分享分享。
優化代碼
先從小處着手，代碼寫的好壞，直接影響到接口的響應速度；當然這裏也不可能展開詳談每一行代碼怎麼寫，主要還是說一下措施：
-
代碼規範：我經常會以自己的標準去衡量其他開發人員代碼的好壞，雖然我也不是什麼大牛，但畢竟做了十多年的開發，所以很多時候組內年輕人的代碼，在我眼裏都是不合格的，爲了短時間內提升他們的代碼水平，只能制定詳細的代碼規範讓他們去遵守；
-
項目級的處理方案：有些公共的功能，並不需要每個開發去寫代碼，比如異常處理，直接往上拋，會有統一的代碼捕捉異常進行處理的。
-
集體Code Review還是有必要做的，一方面起到一個威懾的作用（大部分人都好面子，如果自己寫的代碼太爛被大家看到，也會不好意思，所以寫代碼的時候會小心一些），另外確實可以讓開發人員取長補短。
緩存
緩存很重要，所以單獨拿出來說。
-
出參入參直接緩存：某些場景下，是可以直接把入參作爲key，出參作爲value，直接緩存起來的，比如放到Redis中；我們有個項目是做費率計算的，需要根據入參查詢費率表，並有大量的計算操作，這種場景有兩個特點：一是費率信息不會改變，二是計算複雜費時，這個場景就非常適用於出參入參直接緩存（出參=計算結果）。
-
字典類型的數據，可以靜態化後放入內存或第三方緩存中，並定時刷新緩存或做緩存失效的設置。
-
提前做數據的整合和加工：如果一個接口返回的數據需要幾張表關聯後才能提供，如果可以的話，儘量提前把這個關聯做好；真正接口查詢的時候，只查詢關聯後的結果就可以了。
-
總之，能查詢緩存的話，儘量不要直接查詢數據庫。
接口拆分
設計和代碼一樣重要，甚至在我看來，設計比敲代碼更重要；所以如何設計一個接口，是非常重要的（通常要全盤考慮）：
-
我見過這樣的接口，號稱萬能接口，只對外提供一個接口，根據傳入參數的不同，後面的業務邏輯也不相同，我是非常反感這樣的做法。
-
垂直拆分：把一個龐大的接口，拆分成N個獨立的小接口，每個接口可以獨立部署、維護、迭代；但是接口的【大小】，是很考驗開發人員（架構）的。
-
水平拆分：一方面把接口部署多套，前面掛負載均衡，這是水平拆分的一種；另外一種水平拆分，是將接口中的業務邏輯拆分後並行處理，也是可以減少接口的響應時間的。
