1、首先考慮分散式，業務功能服務化

        使用阿里的dubbo框架，使用zookeeper作為註冊中心；或者spring cloud等；系統靈活部署，在真正消耗資源的服務上，考慮增加例項。

2、打薄閘道器層

        閘道器層，只做引數校驗，和簡單邏輯判斷。

3、非主業務流程非同步化，建議使用mq非同步

        避免使用程序內非同步化，因為雖然減少了單個請求的等待時間，但是非同步執行緒要等待執行完業務，如此，服務本身接受處理請求的可用執行緒會減少。

       程序內非同步化方法：

       1、手寫執行緒並啟動，不推薦，不可控

       2、spring @Asyn 配合Future作為返回值

       3、google的eventBus基於釋出訂閱的執行緒匯流排

       ........

4、介面請求頻率增加限制

5、梳理業務流程，精簡實現流程

        實際上，業務邏輯處理，不不涉及大資料計算的情況下，基本上可以忽略耗時，精簡實現邏輯，主要目的是增強程式碼的可讀性。

6、資料庫索引

        即使庫表資料量，僅在萬級別的，必要的索引還是要加。如果此種情況較多，加之請求量較大，就會把資料庫效率拉下一個級別，高頻的查詢，嚴重消耗CPU，結果就是系統整體效率下降，CPU也居高不下，CPU報警簡訊接二連三。

        以下兩幅圖，是在下午3點多，給眾多表欄位追加必要欄位後，資料庫CPU已經趨於穩定。

文章先列出大框，後續完善....