最近寫了一個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主要測試什麼？
- 測試MiddleServer端兩個介面的吞吐量，MiddleServer端需要請求143000次Server端的介面。同時它需要響應Client端1000次請求。
- 測試MiddleServer端介面的平均耗時。
三. 想得出什麼結論？
- MiddleServer端所面對的場景，使用非同步實現肯定是優於使用多執行緒實現的。
- MiddleServer端的GetValues介面，需要請求286次Server端的介面，如果使用順序執行的非同步，那麼耗時會很長，所以需要並行執行非同步。
- MiddleServer端的GetValues介面，為什麼不只請求1次Server端的介面呢？一是因為業務邏輯可能很複雜，二是因為資料量較大無法一次性獲取。
- MiddleServer端的GetValues介面，為什麼寫了兩層Parallel.ForEachAsync，一層不可以嗎？如果第一層迴圈資料量很少，第二層迴圈存在資料傾斜，那麼寫兩層Parallel.ForEachAsync可能會好一點。
- 雖然Client端測試了併發請求GetValues介面，但這樣的介面，並不是為了高併發，需要做限流。但測試一下是必要的。
- 可能真的不建議寫兩層Parallel.ForEachAsync，因為會導致並行度較大。但是，我可以不寫，你不能不支援。
- 由於精力和水平有限，希望看看別人用java和go語言怎麼寫的。
- 我覺得這裡面可能是有坑的，想看看別人寫的，會不會掉坑裡。
四．最後
希望有興趣的可以用java和go語言寫一下這個demo。可以對比一下：
- 效能，這裡並不專業，只是粗略對比，以及看一下大家對非同步的理解，以及會不會掉坑裡。
- 程式碼是否容易編寫，容易閱讀，容易維護。