下面就用我有限的知識和經驗，講一講高并發下的系統處理方案。
1、大部分的系統應用，在建設初期都是單機應用，也就是一個應用服務器加一個數據庫。
2、當訪問量增多、并發量增加的時候，很多時候應用服務器會先扛不住，通常我們解決這個問題的方法是：把應用服務器做集群部署，在前面搭建負載均衡，例如硬件負載F5、軟件負載Nginx。
3、應用服務器的壓力暫時解決，但是數據庫畢竟還是單臺，這時候我們可以在整體的架構中增加緩存，已減少數據庫的壓力，最常見的是引入Redis，做集群化的部署。
4、業務繼續發展，并發量持續增多，單庫已經到了極限；這時候可以考慮分庫，常見的做法是對分庫字段進行hash()%N，按照結果將數據路由到某一個分庫(分表)上。
5、系統繼續發展，雖然應用是集群化部署，但是畢竟是單個應用，并且隨著項目功能的增加，應用包也會越來越大，代碼改動起來非常痛苦；這時候需要把應用拆分成多個應用，庫也各自獨立出來（說的很簡單，過程非常之痛苦，所以很多公司在初期，就是按照這個架構搭建）：
應用拆分成多個應用；
應用之間的服務發現和調用，都需要服務注冊中心和網關的幫助；
6、雖然應用和庫都拆開了，但是應用和應用質檢的耦合度依然非常高，所以通常會引入消息隊列，例如各種MQ、Kafka，把一些實時性要求不是那么高的服務解耦，比如交易完成時候給客戶發一條短信，那么可以把待發送的短信放到消息隊列中，短信平臺從消息隊列中獲得消息發送短信。
7、這時候應用的體量已經比較大了，部署、運維、查錯的難度加大，這時候需要引入很多組件，來幫助整個系統的穩定運行：
認證中心：安全性的問題要注意，一個接口不是隨隨便便都能訪問的；
限流：當并發量突增的時候，系統肯定會扛不住，這時候限制一部分流量的進入；
監控中心：包括日志監控、服務鏈路監控、流量監控等等；
告警平臺：系統發生異常時，需要及時通知運維人員；
圖畫的有些倉促，難免有不嚴謹的地方，大家可以留言指正（如果留言中有態度不好的，我就自動忽略了）。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。