1. springboot內置tomcat容器的參數配置
server: port: 12021 # server端的socket超時間(毫秒)，使用值-1表示沒有(即無限)超時，默認值為60000(即60秒) # Tomcat附帶的標准server.xml將此值設置為20000(即20秒)，除非disableUploadTimeout設置為false，否則在讀取請求正文(如果有)時也會使用此超時 connection-timeout: 80000 tomcat: # URL統一編碼 uri-encoding: UTF-8 # 處理的最大並發請求數，默認值200 max-threads: 1000 # 在給定時間接受和處理的最大連接數，默認值10000 max-connections: 20000 # 初始化時創建的最小線程數，始終保持運行，默認值10 min-spare-threads: 20 # 監聽端口隊列最大數，滿了之后客戶請求會被拒絕(不能小於maxSpareThreads)，默認為100 acceptCount: 700 # 取消post參數大小限制，默認為2097152(2M) max-http-post-size: -1 # 請求和響應HTTP標頭的最大大小，以字節為單位指定，如果未指定，則此屬性設置為8192(8 KB) max-http-header-size: 8192(8 KB)
開發中遇到問題，需查詢tomcat官方文檔: http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#HTTP/1.1_and_HTTP/1.0_Support
2. spring cloud hystrix的參數hystrix.command.default和hystrix.threadpool.default中的default為默認CommandKey(默認值：當前執行方法名)
Execution相關的屬性的配置： 隔離策略，有THREAD和SEMAPHORE THREAD - 它在單獨的線程上執行，並發請求受線程池中的線程數量的限制 SEMAPHORE - 它在調用線程上執行，並發請求受到信號量計數的限制 hystrix.command.default.execution.isolation.strategy 隔離策略，默認是Thread, 可選Thread｜Semaphore 在THREAD模式下，達到超時時間，可以中斷 在SEMAPHORE模式下，會等待執行完成后，再去判斷是否超時 設置標准：有retry，99meantime+avg meantime；沒有retry，99.5meantime hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令執行超時時間，默認1000ms hystrix.command.default.execution.timeout.enabled 執行是否啟用超時，默認啟用true hystrix.command.default.execution.isolation.thread.interruptOnTimeout 發生超時是是否中斷，默認true(THREAD模式有效) execution.isolation.thread.interruptOnCancel 當發生取消時，執行是否應該中斷，默認值為false(THREAD模式有效) hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大並發請求數，默認10，
## 該參數當使用ExecutionIsolationStrategy.SEMAPHORE策略時才有效。如果達到最大並發請求數，請求會被拒絕。
## 理論上選擇semaphore size的原則和選擇thread size一致，但選用semaphore時每次執行的單元要比較小且執行速度快(ms級別)，否則的話應該用thread，semaphore應該占整個容器(tomcat)的線程池的一小部分
## 只有在高並發(單個實例每秒達到幾百個調用)的調用時，才需要修改HystrixCommands 的隔離策略為semaphore
Fallback相關的屬性:(應用於Hystrix的THREAD和SEMAPHORE策略) hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果並發數達到該設置值，請求會被拒絕和拋出異常並且fallback不會被調用，默認10 hystrix.command.default.fallback.enabled 當執行失敗或者請求被拒絕，是否會嘗試調用hystrixCommand.getFallback()，默認true Collapser Properties相關參數: hystrix.collapser.default.maxRequestsInBatch 單次批處理的最大請求數，達到該數量觸發批處理，默認Integer.MAX_VALUE hystrix.collapser.default.timerDelayInMilliseconds 觸發批處理的延遲，也可以為創建批處理的時間＋該值，默認10 hystrix.collapser.default.requestCache.enabled 是否對HystrixCollapser.execute() and HystrixCollapser.queue()的cache，默認true ThreadPool相關參數: 線程數默認值10適用於大部分情況(有時可以設置得更小)，如果需要設置得更大，那有個基本得公式可以follow： requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room 每秒最大支撐的請求數 (99%平均響應時間 + 緩存值) 比如：每秒能處理1000個請求，99%的請求響應時間是60ms，那么公式是：1000 * （0.060+0.012） 基本得原則時保持線程池盡可能小，主要是為了釋放壓力，防止資源被阻塞。當一切都是正常的時候，線程池一般僅會有1到2個線程激活來提供服務。 hystrix.threadpool.default.coreSize 並發執行的最大線程數，默認10 hystrix.threadpool.default.maxQueueSize BlockingQueue的最大隊列數，當設為－1，會使用SynchronousQueue，值為正時使用LinkedBlcokingQueue。該設置只會在初始化時有效，之后不能修改threadpool的queue size，除非reinitialising thread executor。默認－1。 hystrix.threadpool.default.queueSizeRejectionThreshold 即使maxQueueSize沒有達到，達到queueSizeRejectionThreshold該值后，請求也會被拒絕。因為maxQueueSize不能被動態修改，這個參數將允許我們動態設置該值。if maxQueueSize == -1，該字段將不起作用 hystrix.threadpool.default.keepAliveTimeMinutes 如果corePoolSize和maxPoolSize設成一樣(默認實現)該設置無效。如果通過plugin（https://github.com/Netflix/Hystrix/wiki/Plugins）使用自定義實現，該設置才有用，默認1. hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds 線程池統計指標的時間，默認10000 hystrix.threadpool.default.metrics.rollingStats.numBuckets 將rolling window划分為n個buckets，默認10
實際使用中，發現使用默認配置，經常報semaphore異常，服務請求被拒絕。用壓測工具jmeter場景復現：
1. 通過gateway訪問服務，開100個線程請求，成功率52%；開200個線程請求，成功率39%；開500個線程請求，成功率30%；
2. 不通過網關，直接訪問服務，開100個線程請求，成功率100%；開200個線程請求，成功率100%；開500個線程請求，成功率49%；
現象解釋：
1. springboot默認的tomcat線程池為200，通過直連服務，並發訪問的線程在200以下時，請求順利處理，達到500時，超過了線程數，線程不夠用，會導致部分請求失敗，可通過超時時間和線程池配置優化；
2. gateway網關，配合hystrix訪問，因為默認的semaphore是10，並發到100時，信號量處理不過來，就會有大量的fallback，並發到200時，同時會導致失效的fallback的內置隊列(默認100個)空間不足，拋出異常，並發加到500，異常增多，失敗率加大；
根據hystrix配置參數的作用，優化hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests=200，壓測gateway發現，並發500，成功率為100%，遠優於直接請求。(由於直連接口並發調用指標小於500，綜合考慮服務器的承載后，沒有測試上限)
結果表明gateway，hystrix的內部調用對並發有較好的優化，聯合tomcat線程池和hystrix的semaphore.maxConcurrentRequests，能夠極大的提高單機並發性能。