最近在工作上碰到一個性能問題，由于項目是基于SOA的架構，使得整個系統完全依賴于各種各樣的Service，其中用于處理業務邏輯的Business Services全部都用.NET Workflow 3.5實現（歷史原因，項目還沒升級到Workflow 4）。在眾多的Business Service中，其中有一個的主要功能是，通過調用不同的Data Service來獲取數據，然后根據業務邏輯來組織這些數據并返回給它的調用者。該Business Service的工作流（Workflow）主要包含三個活動組件（Activity），大致可以用下圖表示：

　　需要說明一下，在實際項目中，這個Workflow本身不僅僅只是簡單地包含上面三個Activity，通過性能測試的數據分析，瓶頸就在這三個Activity上，而每個Activity的執行時間又主要消耗在反復調用Data Service上。在此，為了簡化問題的描述，我把其它不相干的Activity剔除了，于是就得到了上圖的結構。

　　圖中的三個Activity都會分別去調用不同的Data Service來獲得數據，尤其在getNotesActivity中，Data Service會被循環調用，這使得系統性能大打折扣。原本有一個解決方案可以在一定程度上提高getNotesActivity的效率，就是修改被調用的Data Service，使得它能夠一次性接收多個request的數據，處理完之后再將所有的結果一次性返回，這樣就避免了Data Service的循環調用，有效地減少了數據在網絡上的來回次數。但是，這種解決方案需要更改Data Service的Request Schema，這個改動是很大的，因為可能有很多其它的Business Service都在調用這個Data Service，牽涉的范圍太廣了。

　　根據實際項目，稍加分析不難發現，這個Workflow中的Activity有如下幾個特點：

• 三個Activity的輸入屬性參數都來自于Workflow（即通過與Workflow中定義的DependencyProperty進行綁定而獲得數據），并不存在下游的Activity的輸入參數需要依賴上游Activity的輸出參數的情況
• 每個Activity的輸出屬性參數都只關注某一種類型的數據，在Workflow Runtime執行完某個Activity后，也會通過DependencyProperty將處理結果傳遞給Workflow，而這些輸出屬性參數之間也并沒有任何關聯
• 三個Activity所調用的Data Service也比較獨立，基本上可以說是在做三個完全不同的工作
• 時間主要消耗在Data Service的調用上，不存在由于復雜的運算邏輯導致CPU利用率近似100%的情況，也不存在由于物理內存用完而需要頻繁讀寫虛擬內存的情形

　　上述的幾個特點中，第四點為我們引入多線程或并行任務處理提供了主要依據。這里需要額外岔開一下。有很多軟件人員認為，多線程一定能夠提高系統性能，因為事務可以分派到多個線程中進行并行處理。我覺得，應該這樣去看待這個問題：首先，根據Martin Fowler的《企業應用架構模式》（也就是著名的PoEAA）一書中有關性能的討論認為，有很多術語可以描述性能，比如：響應時間、響應性、等待時間、吞吐率、負載、負載敏感度等。假設完成某個任務需要的時間很長，比如需要5秒，那么其響應時間就是5秒，而如果讓用戶等待這5秒過去后，再將系統的控制權交給用戶，就會讓用戶明顯感覺很不順，于是響應性就很差；但如果能將這個任務交給另一個執行體去處理，而程序本身直接將系統控制權交給用戶，等那個執行體完成任務處理后，再將結果提供給用戶，那么，同樣處理這個任務需要5秒鐘，這種方式的響應性就明顯要好于前者，這也是我們以前做Windows Forms開發的時候，要把耗時的處理交給另一個線程處理，以不至于因為主線程的阻塞而導致界面凍結的尷尬局面。因此，多線程的引入，可以提高系統的響應性。

　　其次，多線程是否能夠提高系統的響應時間？這也未必，在單核處理器上，多線程是采用時間片輪循的方式實現的，也就是說，相同時間點上，只有一個線程在執行，只不過是時間片足夠小，輪循頻率足夠高，才讓我們感覺線程是并行執行的，在這樣一種體系結構下，完成任務的處理還是需要那么長時間，甚至時間片的切換倒還會帶來額外的開銷。在多核系統中，或許真的可以提高響應時間，不過我目前沒有實際的測試數據用來比較，因此在這個問題上，我還沒有足夠的發言權。

　　而對于目前項目的情況，Data Service是分布在網絡上不同位置的資源，如果能讓這些Data Service同時處理數據請求，再讓Business Service去組織分別來自這些Data Service的處理結果，那么整個Business Service的響應時間是可以明顯提高的，響應時間提高了，響應性也同樣提高了。假設第一個Activity耗時t1，第二個Activity耗時t2，第三個Activity耗時t3，那么，如果按上圖中的順序方式執行，Business Service的響應時間就是t1+t2+t3。但如果讓這些Activity并行處理（也就相當于并行調用Data Service使其同時處理數據請求），那么Business Service的響應時間應該就是max(t1, t2, t3)。

　　于是，我打算將上述的Workflow修改一下，采用多線程的方式來分別運行每個Activity，最后再將結果匯總。我修改后的Workflow如下所示：

　　在此需要對ParallelActivity說明一下。.NET Workflow 3.5的ParallelActivity并沒有做到所謂的并行執行，因為Workflow Runtime是在單獨的線程上執行Workflow Instance的，因此，要讓多個Activity真正并行執行是做不到的。ParallelActivity的真正用意在于協調每個分支中的SequenceActivity（注意：ParallelActivity的每個分支只能接收一個SequenceActivity），使得其中的每個Activity都有一次執行的機會。

　　某個分支中的一個活動執行過后，就會輪到下一個分支。當這個分支執行了一個活動后，執行又會轉移到再下一個分支，以此類推。當所有分支都有了執行機會之后，又會從第一個（最左側）分支開始這一過程，繼續執行第一個分支的下一個活動（如果存在的話）。因此，在我們的這個例子中，完全可以不用ParallelActivity，而仍然選擇原來的結構即可。之前我并沒有完全清楚地了解ParallelActivity，開始一直以為ParallelActivity的意思是，讓Workflow Runtime同時安排（Schedule）每個分支的執行，以便當每個分支都以異步方式運行時，所有的分支可以實現并行處理。

　　不過也不要緊，在這里使用ParallelActivity，雖然沒有有效地利用它的特性，但與原來的Workflow相比，從可讀性上講，這種結構更容易讓人覺得這是一種并行的運行方式。

　　另一個變化是，原本每個操作都是寫在一個自定義的Activity中的，通過重寫Activity的Execute方法來做業務處理，而現在則是用CodeActivity來代替原來的Activity，這樣做的好處是，可以將業務處理的代碼放在同一個Context中，這也為線程同步提供了便利，降低了使用線程的復雜度。

　　以下是改進后的Workflow的代碼，供參考。

　　從上面的代碼中可以看到，每個CodeActivity在執行的時候都會啟動一個線程，這個線程會調用相應的Data Service來實現其業務邏輯，線程創建以后，會被保存在一個線程列表里，用來在syncCodeActivity中進行線程同步。syncCodeActivity則通過線程的Join方法來等待所有線程全部完成各自的工作，最后對運行結果和異常進行處理。

　　此處線程的運用需要遵循.NET線程使用的最佳實踐，應該盡量避免線程的阻塞，在訪問臨界資源的時候應作加鎖處理以防止狀態異常。由于在這個例子中，每個線程又會牽涉到其它Service的調用，因此在線程中捕獲的異常，我建議還是先將其記錄下來，然后溫和地直接使用return語句終止線程執行，而不是隨意拋出異常而使得線程進入一個不確定的狀態。當然，讀者朋友如果在多線程環境中有處理異常的經驗，也懇請在本文留言指導。

　　對Workflow進行調整之后，重新編譯、部署并運行這個Business Service，然后用已經寫好的Client程序進行測試，我們得到了如下的結果（幾個明顯的噪音數據已經被劃掉，沒有包含在統計中）。從這個報表可以看到，針對我們的這個案例，在Workflow中引入多線程的確可以明顯地提高系統性能。