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