web服務非同步化：
包括兩部分，資料傳輸層非同步化（大家已經熟知的nio），http業務請求非同步化（continuations，servlet3.0）。服務非同步處理我將會有乙個詳細的說明文件（服務非同步化的概念，服務非同步化的幾種標準實現，服務非同步化容器的特點），後續給出。
web服務非同步化
測試原因：
top應用特殊性：
1.自身服務能力由後端的服務能力決定。（對同步web請求的**）
2.後端服務部署等同性，但要求服務互不影響。
第一點導致top無法預估自身服務能力（不同後端服務處理速度下的top有不一樣的支援能力），同時也無法應對在後端服務異常的情況下，整體的服務質量。
第二點導致top只有在物理上分隔不同服務提供者所對應的top集群（資源浪費，同時無法動態調整資源來滿足服務變化情況）。
因此需要對top實施web服務非同步處理的測試。這裡簡單的說一下服務非同步化的使用場景需要滿足的幾個特點：
1. 處理耗時大多消耗在於對後端或者外部服務資源的請求上。
2. 後端或者外部資源在更多的流量下不會成為瓶頸。
拿top來解釋一下：top自身處理主要包括路由，安全，流控等，但是最耗時的是在請求後端各個**團隊的服務。其次當前後端服務能力尚未達到真實的處理高峰，因此很多請求被堵在top平台，特別是當某些服務異常的時候，另一些服務就會被拖累無法得到充分利用。（當然我們有流控，發現後端服務能力已經成為瓶頸的時候可以對單獨服務作限制）。
長話短說，上測試結果……
環境說明：
linux2.6.9-55.elsmp
4 core
4 g memory
jdk 1.6.0_07
測試工具：loadrunner 9.5
測試涉及到了四種容器部署：後面都會用縮寫在測試結果上註明
1. apache + modjk + jboss(後面縮寫為jboss)：
此模式apache配置如下：
serverlimit 80
threadlimit 128
startservers 10
maxclients 10240
minsparethreads 64
maxsparethreads 800
threadsperchild 128
maxrequestsperchild 10000
jboss的web容器配置如下：
jboss的web部分以apr模式啟動。
2. tomcat6（apr）
關鍵配置如下：
maxthreads="500" minsparethreads="40"/>
executor="topthreadpool" connectiontimeout="20000" acceptcount="1000"
redirectport="8444" />
3. tomcat7 rc 4（apr）
關鍵配置如下：
maxthreads="500" minsparethreads="4"/>
connectiontimeout="20000" acceptcount="1000"
redirectport="6443" />
4. jetty7
關鍵配置如下：
10 500
300000
2false
8443
20000
5000
附註：asyn表示非同步模式，syn表示同步。asyn中還分成resume和complete兩種方式，後續在介紹技術背景的時候詳細描述。
對於服務端的load不是每乙個測試都做了記錄，選取了最全面的1500併發使用者做了測試。
最大服務請求處理數是通過應用自身實現，具體**可以參考後面的**附件。
測試結果如下：
場景1：500 併發使用者場景下，後端服務一次請求消耗3秒鐘
可以看到，在tps和response time上兩者基本上沒有太大差別，tps就等於500/3=167左右（3秒乙個請求，因此用這種簡單算式可以算出），響應時間也較為正常。當時我發現在每秒吞吐量上有些差別，後來單個測試case跑了一下，發現是返回的http header比較大，應該是在做非同步化時重入等作的一些標識（後面其他容器的非同步化也是一樣）。
最大處理請求數都在服務端後台看到是500，等同於最大的併發使用者數。
場景2：1000 併發使用者場景下，後端服務一次請求消耗3秒鐘
場景2就在資源不足的情況下，比較非同步服務請求與同步請求處理能力。（例如由於後端某些服務比較慢，導致前段的伺服器能夠承載的請求數目超過了執行緒數）
這個場景的結果可以看到tps在非同步模式下與併發使用者數呈現同步增長，就好比配置了1000個執行緒作為執行緒池一樣，同樣在後端打出的最大請求數上也證明了這一點，因此前段執行緒池的服務能力在非同步的情況下充分復用（當然這裡使用的非同步服務處理使用的是nio而不是bio的connector）。同樣在吞吐量上依然是增加的，由於非同步附加的內容。
場景3：1500 併發使用者場景下，後端服務一次請求消耗3秒鐘
場景三比對了現有top的部署模式（apache + modjk + jboss）和jetty7的同步模式，兩種非同步模式，tomcat同步模式，tomcat的servlet3.0非同步模式的處理情況。根據測試可以得到的資訊如下：
1. 現有部署方式在後端服務處理耗時較大的情況下，處理能力不如jetty7和tomcat6，同時出錯率很高。
2. jetty7的同步處理測試結果和tomcat6的同步處理測試結果很類似，但是load方面jetty7更好。
3. 非同步處理方面jetty7的兩種方式基本上差別不大（後續還需要深入原始碼看看對於資料快取資源復用的狀況），tomcat7的非同步處理成功率有些問題（錯誤多半是在獲取response回寫的時候，response已經被提前釋放，看來tomcat7還是需要一些時間來考驗），load上來說tomcat結果比較好。
4. 非同步請求在提高處理能力的情況下，對於資源消耗也較大（執行緒切換較為頻繁），不過還是在承受範圍。
三個場景組合比較：
最後將三個場景合併起來做乙個簡單的比較，得到資訊如下：
1. 隨著併發使用者的增加，本身非同步處理也會有衰減，同時對於效能消耗（執行緒切換）也會不斷增長。
2. 非同步化在訊息頭上會增加一些資料，會增加回寫的頻寬消耗（不過量不大），乙個請求增加了100byte左右的訊息資料。
測試總結：
1. web請求非同步化在top很合適。
重複兩個條件：
a. 處理耗時大多消耗在於對後端或者外部服務資源的請求上。
b. 後端或者外部資源在更多的流量下不會成為瓶頸。
後續需要繼續跟進的：
1. 對於大資料量請求的容器間效能對比。（上傳或者大資料量的post請求）
2. 容器安全性。（是否容易被攻擊）
3. **遷移成本。
Java 請求非同步響應
背景 介面請求的時候如果是同步，那麼有時業務邏輯處理時間很長，請求就會超時！所以需要在介面請求過來時，就先響應，再去執行業務邏輯。或者不是乙個請求,乙個方法裡面兩個無關的業務邏輯需要非同步執行節省效率的也可以用這個方法,自己看著改,前提是執行緒裡面執行的方法沒有關係不會影響響應的結果 1.建立乙個c...
Zk內部服務請求攜帶web請求引數
在微服務框架，內部模組間的通訊走的是zookpeer註冊服務，在整合使用者認證資訊時遇到zk內部協議請求未攜帶認證token資訊導致web請求未認證授權。這裡解決方案是配置啟動類，在類上使用 configuration。把web請求的認證資訊token在呼叫zk服務前注入進去。把啟動類放入commo...
使用titbit開發Web後端服務 請求上下文
框架在接收的請求引數，只有乙個，被稱為請求上下文，就是乙個封裝了各種請求資料的物件。通過這樣的設計，把http 1.1 和 http 2協議的一些差異以及node.js版本演進帶來的一些不相容做了處理，出於設計和效能上的考慮，對於http2模組，封裝請求物件是stream，而不是http模組的inc...