沒有什麼效能問題是加機器不能解決的，如果有，那就是機器加的不夠~
如何設計好高併發介面？先看一張基本網路拓撲圖：
以上面的網路拓撲圖為準，如何設計好一個介面，能保證在高併發請求下的健壯性，我覺得會有以下幾方面的考慮：
介面的職責單一：一個介面只做一件事，設計的介面儘可能簡單，如果業務複雜了，就拆介面，只要滿足業務，並且保證一定的合理性即可，能讓前端做的事情就不要讓後端去做，不要和我說前端同學不同意，在效能面前，一切都得讓路；
儘可能減少介面的網路連線：每一次網路連線都是一次不小的開銷，想想TCP的三次握手和四次揮手過程，還有網路資料傳輸的資料量大小，以及資料的序列化和反序列化；
快取必加：資料庫是每一個連線都很珍貴，在你的服務和資料庫中間加一層快取吧，良好的運用快取可以將99%的流量阻擋在快取層，把redis用好，你會發現再也不怕測試同學壓測你的介面了。同樣請求redis也是有網路連線開銷的，那麼在服務和快取中介軟體中間再加一層JVM快取，第三方的開源工具包也很多，比如Google Guava,JVM快取一加，天下無敵；
大批次寫資料先入佇列：大批次的寫庫請求不要一股腦的塞給資料庫，鎖表、鎖行、寫索引，資料庫的安全執行是第一要務，千萬不能掛，千萬不能掛，千萬不能掛。可以把資料寫到MQ中，然後消費端再慢慢消費。
持續的最佳化程式碼：整合APM效能工具如pinpoint進行鏈路跟蹤，然後自己去壓測，可以先壓測20個併發跑10分鐘，把機器跑熱，觸發JVM的JIT機制，然後繼續加併發，看CPU、看記憶體、看連線數、看磁碟流量、看pinpoint看看哪一個環節慢了點，再各個擊破，不斷最佳化程式碼；
以上，是我個人認為需要考量的一些因素，在介面設計之初就應該考慮好這些，根據這些因素去做資料模型設計以及相關場景設計，便能在後期壓測、最佳化時候能夠更好的達到高併發的效能要求。
沒有什麼效能問題是加機器不能解決的，如果有，那就是機器加的不夠~
如何設計好高併發介面？先看一張基本網路拓撲圖：
以上面的網路拓撲圖為準，如何設計好一個介面，能保證在高併發請求下的健壯性，我覺得會有以下幾方面的考慮：
介面的職責單一：一個介面只做一件事，設計的介面儘可能簡單，如果業務複雜了，就拆介面，只要滿足業務，並且保證一定的合理性即可，能讓前端做的事情就不要讓後端去做，不要和我說前端同學不同意，在效能面前，一切都得讓路；
儘可能減少介面的網路連線：每一次網路連線都是一次不小的開銷，想想TCP的三次握手和四次揮手過程，還有網路資料傳輸的資料量大小，以及資料的序列化和反序列化；
快取必加：資料庫是每一個連線都很珍貴，在你的服務和資料庫中間加一層快取吧，良好的運用快取可以將99%的流量阻擋在快取層，把redis用好，你會發現再也不怕測試同學壓測你的介面了。同樣請求redis也是有網路連線開銷的，那麼在服務和快取中介軟體中間再加一層JVM快取，第三方的開源工具包也很多，比如Google Guava,JVM快取一加，天下無敵；
大批次寫資料先入佇列：大批次的寫庫請求不要一股腦的塞給資料庫，鎖表、鎖行、寫索引，資料庫的安全執行是第一要務，千萬不能掛，千萬不能掛，千萬不能掛。可以把資料寫到MQ中，然後消費端再慢慢消費。
持續的最佳化程式碼：整合APM效能工具如pinpoint進行鏈路跟蹤，然後自己去壓測，可以先壓測20個併發跑10分鐘，把機器跑熱，觸發JVM的JIT機制，然後繼續加併發，看CPU、看記憶體、看連線數、看磁碟流量、看pinpoint看看哪一個環節慢了點，再各個擊破，不斷最佳化程式碼；
以上，是我個人認為需要考量的一些因素，在介面設計之初就應該考慮好這些，根據這些因素去做資料模型設計以及相關場景設計，便能在後期壓測、最佳化時候能夠更好的達到高併發的效能要求。