最近寫了一個demo：demo的github地址

一. 簡單介紹

1. Server端

它是一個WebApi服務，把它當成一個黑盒就行了。

2. MiddleServer端

是重點，它是一個WebApi服務，包含一個GetValues介面和一個Query2介面。
Query2介面是一個簡單的介面。
GetValues介面通過請求Server端的GetCounts介面和GetValues介面獲取數據。

3. Client端

請求500次MiddleServer端的GetValues介面和請求500次Query2介面。
並行度200。

二. 這個demo主要測試什麼？

1. 測試MiddleServer端兩個介面的吞吐量，MiddleServer端需要請求143000次Server端的介面。同時它需要響應Client端1000次請求。
2. 測試MiddleServer端介面的平均耗時。

三. 想得出什麼結論？

1. MiddleServer端所面對的場景，使用非同步實現肯定是優於使用多線程實現的。
2. MiddleServer端的GetValues介面，需要請求286次Server端的介面，如果使用順序執行的非同步，那麼耗時會很長，所以需要並行執行非同步。
3. MiddleServer端的GetValues介面，為什麼不只請求1次Server端的介面呢？一是因為業務邏輯可能很複雜，二是因為數據量較大無法一次性獲取。
4. MiddleServer端的GetValues介面，為什麼寫了兩層Parallel.ForEachAsync，一層不可以嗎？如果第一層迴圈數據量很少，第二層迴圈存在數據傾斜，那麼寫兩層Parallel.ForEachAsync可能會好一點。
5. 雖然Client端測試了併發請求GetValues介面，但這樣的介面，並不是為了高併發，需要做限流。但測試一下是必要的。
6. 可能真的不建議寫兩層Parallel.ForEachAsync，因為會導致並行度較大。但是，我可以不寫，你不能不支持。
7. 由於精力和水平有限，希望看看別人用java和go語言怎麼寫的。
8. 我覺得這裡面可能是有坑的，想看看別人寫的，會不會掉坑裡。

四．最後

希望有興趣的可以用java和go語言寫一下這個demo。可以對比一下：

1. 性能，這裡並不專業，只是粗略對比，以及看一下大家對非同步的理解，以及會不會掉坑裡。
2. 代碼是否容易編寫，容易閱讀，容易維護。