實現(xiàn)有效 APM 策略所面臨的挑戰(zhàn)：

• 代碼依賴
• 過度或不必要的日志
• 同步與鎖
• 潛在數(shù)據(jù)庫問題
• 潛在的基礎(chǔ)架構(gòu)問題

1、代碼依賴

開發(fā)程序是一項具有挑戰(zhàn)性的工作。你不僅要為了滿足商業(yè)需求而建立程序邏輯，還要選擇最合適的代碼庫和工具來幫助你。你能想象自己創(chuàng)建所有的日志管理代碼，XML 和 JSON 解析邏輯，或所有的序列化庫么？你當然可以編寫代碼來完成這些事，但是諸多開源開發(fā)者團隊已經(jīng)做好了這些事情，你又何必親力親為呢？此外，如果你正在與第三方系統(tǒng)集成，你會自己讀完專有的通信協(xié)議規(guī)范，還是購買供應(yīng)商提供的庫幫你完成呢？

我相信你會同意：如果有人已經(jīng)解決了你的問題，使用他的解決辦法會比自己想辦法解決效率更高。如果這是一個已經(jīng)被許多公司采用的開源項目，那么很可能它已經(jīng)經(jīng)過完備的測試，文檔充足，而且你應(yīng)該找得到許多使用教程。

然而，使用依賴庫是有危險的。你需要回答以下問題：

• 這個庫真的寫得很好并且已經(jīng)充分測試了嗎？
• 你是否用與眾多公司一樣的方式使用這個庫？
• 你的使用方式是否正確？

請確保在選擇外部庫之前進行一些調(diào)查，如果你對某個庫的性能有什么疑問，那就進行一些性能測試。開源項目很好的地方在于你可以訪問它們的全部源代碼以及測試套件和構(gòu)建流程。下載它們的源代碼，執(zhí)行編譯過程，并查看測試結(jié)果。如果你看到很高的測試覆蓋率，那么就可以比沒有測試案例時信心百倍！

最后，確保正確地使用依賴庫。如果正確使用，ORM 工具的確能夠大大提高性能。ORM 工具的問題在于，如果你不花時間去學習如何正確地使用它，你就會輕易的砸自己腳，破壞自己的應(yīng)用性能。關(guān)鍵就在于如果不花時間學習這些工具，本應(yīng)幫助你的工具反而會傷害你。

2、過度或不必要的日志

日志記錄是調(diào)試工具庫里的強大武器，可以幫助你識別應(yīng)用執(zhí)行過程中在特定時間內(nèi)可能發(fā)生的異常。當錯誤發(fā)生時，捕捉錯誤信息并收集盡可能多的上下文信息是非常重要的。然而，簡潔地捕捉錯誤條件和過度記錄之間是有差別的。

最普遍的兩個問題就是：

• 多級別異常日志
• 錯誤配置生產(chǎn)日志級別

異常日志能幫助你了解應(yīng)用程序中發(fā)生的問題，因而非常重要。但一個常見的問題是，應(yīng)用程序所有層級的異常都進行記錄。例如，你的某個數(shù)據(jù)訪問對象捕獲到一個數(shù)據(jù)庫異常，并將該異常傳達到服務(wù)層。服務(wù)層可能會捕捉該異常，并將其傳達到網(wǎng)絡(luò)層。如果我們在數(shù)據(jù)層、服務(wù)層和網(wǎng)絡(luò)層上都記錄該異常，那么我們對此相同的錯誤條件就有三條堆棧記錄。這會導致寫入日志文件的額外負擔，還會使日志文件充滿冗余信息。但這個問題非常普遍，我敢斷言，如果你檢查自己的日志文件，你很可能會發(fā)現(xiàn)多個這樣的例子。

生產(chǎn)應(yīng)用中常見的另一個大的日志問題與日志級別有關(guān)。.NET 日志記錄器定義了以下日志記錄級別（.NET TraceLevel 與 log4net 中的命名會有所不同，但絕對相似）：

• Off
• Fatal
• Error
• Warning
• Info
• Verbose / Debug

在生產(chǎn)應(yīng)用程序中，你應(yīng)該只記錄 error 或 fetal 級別的日志語句，在更寬松的環(huán)境中，捕捉 warning 甚至 info 級別的日志信息也完全可以，但是一旦應(yīng)用投入生產(chǎn)環(huán)境，用戶負載將迅速填滿日志并使應(yīng)用程序陷入癱瘓。如果你不經(jīng)意地將生產(chǎn)環(huán)境下的應(yīng)用日志級別設(shè)為 debug，應(yīng)用的響應(yīng)時間比正常情況下高兩或三倍都不奇怪！

3、同步與鎖

有時候，你想確保應(yīng)用代碼中每次只有一個線程執(zhí)行一段代碼子集。 例如，讀取單線程規(guī)則執(zhí)行組件之類的共享軟件資源，以及文件句柄或網(wǎng)絡(luò)連接之類的共享基礎(chǔ)架構(gòu)資源。.NET 框架提供了許多不同類型的同步策略，包括鎖/監(jiān)視器、進程間互斥，和讀/寫鎖這類的專用鎖。

不管你為什么要同步代碼或者選擇什么機制實現(xiàn)代碼同步，都會導致一個問題：那就是有部分代碼一次只能由一個線程執(zhí)行。 設(shè)想去超市，只有一個收銀員在工作：許多人進入商店，瀏覽商品，將商品放進購物車里，但某一時候，他們不得不排隊以進行支付。在這個例子中，購物是多線程的，每個人都代表一個線程。然而結(jié)賬是單線程的，這意味著每個人都要花費排隊付款的時間。這個過程如圖1所示。

 圖1：線程同步

我們有七個線程，都需要訪問一段同步代碼塊，所以它們依次獲得權(quán)限訪問該代碼塊，執(zhí)行其功能，然后繼續(xù)。

在圖2中總結(jié)了線程同步的過程。 

圖2 線程同步過程

首先，為特定的對象（System.Object 派生）創(chuàng)建鎖，意味著當一個線程試圖進入同步代碼塊時必須獲取該同步對象的鎖。如果該鎖可用，則該線程被授予執(zhí)行同步代碼的權(quán)限。在圖2中的例子中，當?shù)诙€線程到達時，第一個線程已經(jīng)占有了該鎖，所以第二個線程被強制等待，直到第一個線程執(zhí)行完畢。當?shù)谝粋€線程執(zhí)行結(jié)束時，會釋放該鎖，然后第二個線程被授予訪問權(quán)限。

正如你可能猜測到的，線程同步將給 .NET 應(yīng)用帶來一個極大的挑戰(zhàn)。我們設(shè)計應(yīng)用程序時，希望其能支持數(shù)十個甚至數(shù)百個同步請求，但線程同步會把所有處理這些請求的線程串行化，導致性能瓶頸！

解決的辦法有兩種：

• 仔細檢查同步的代碼，以確定是否存在其他可行辦法
• 限制同步代碼塊的范圍

有時候，你要訪問必須同步的共享資源，但很多時候，你可以用完全避免同步的方法重新解決該問題。例如，我們之前使用的規(guī)則過程引擎有單線程的要求，因此拖慢了程序中所有請求的執(zhí)行速度。這顯然是一個設(shè)計上的缺陷，我們可以用一個可以并行工作的庫取代之。你需要問自己是否有更好的選擇：如果你在往一個本地文件系統(tǒng)寫入信息，你是否可以把信息發(fā)送給某項服務(wù)，再由該服務(wù)將信息存儲到數(shù)據(jù)庫中？你是否可以將對象設(shè)為不可變，從而無論是否有多線程訪問它都沒關(guān)系？等等，等等…

對于那些必須要同步的代碼段，請合理地選擇鎖。你的目標是將同步代碼塊隔離以滿足最低限度的同步要求。通常最好是定義一個特定的對象進行同步，而不是對包含同步代碼的對象進行同步，因為你可能會在不經(jīng)意間拖慢該對象的其他交互。最后，考慮使用讀/寫鎖，而不是標準的鎖，這樣，你可以在資源只進行同步變化時，允許讀操作。

4.潛在的數(shù)據(jù)庫問題

幾乎所有的內(nèi)容應(yīng)用最終都會涉及到向/從數(shù)據(jù)庫或文檔存儲儲存/檢索數(shù)據(jù)。因此，數(shù)據(jù)庫、數(shù)據(jù)庫查詢，以及存儲過程調(diào)優(yōu)對應(yīng)用程序的性能來說是最重要的。

程序架構(gòu)師/開發(fā)人員和數(shù)據(jù)庫架構(gòu)師/開發(fā)人員之間有一個哲學性的劃分。應(yīng)用程序架構(gòu)師傾向于認為所有的業(yè)務(wù)邏輯都應(yīng)該駐留在應(yīng)用程序中，數(shù)據(jù)庫應(yīng)該只提供訪問數(shù)據(jù)的通道。另一方面，數(shù)據(jù)庫架構(gòu)師更傾向于認為將業(yè)務(wù)邏輯推到數(shù)據(jù)庫中更有益提高性能。這個劃分的答案很可能就是介于兩者之間。

作為一個應(yīng)用程序架構(gòu)師，我傾向于將更多的業(yè)務(wù)邏輯應(yīng)用在程序當中，但我完全承認數(shù)據(jù)庫架構(gòu)師能更好的理解數(shù)據(jù)和與數(shù)據(jù)交互的最佳方式。我認為，這兩個群體之間的協(xié)同合作才能產(chǎn)生最佳的解決方案。但是，不管你傾向于哪一方，請確保你的數(shù)據(jù)庫架構(gòu)師檢查你的數(shù)據(jù)模型，所有的查詢語句和存儲過程，他們都有豐富的知識幫助你以最佳的方式來調(diào)整和配置數(shù)據(jù)庫，他們有大量的工具可以為你調(diào)整查詢語句。例如，有一些工具可用于 SQL 調(diào)優(yōu)，遵循以下這些步驟：

• 分析 SQL 語句
• 確定查詢的執(zhí)行計劃
• 利用人工智能生成備選的 SQL 語句
• 確定所有備選方案的執(zhí)行計劃
• 提出最佳的查詢方式來完成目標

當我在寫數(shù)據(jù)庫查詢代碼時，我使用了這類工具，并在高負載情況下量化了結(jié)果，一些細微的調(diào)整和優(yōu)化，都能導致極大的性能提升。

5、潛在的基礎(chǔ)架構(gòu)問題

之前提過，.NET 應(yīng)用運行在分層的環(huán)境中，其層級結(jié)構(gòu)如圖3所示：

 圖3.NET分層執(zhí)行模型

你的應(yīng)用程序運行在 ASP.NET 或是 Windows Forms 容器中，使用 ADO 庫與運行在 CLR 內(nèi)部的數(shù)據(jù)庫交互，而 CLR 運行在操作系統(tǒng)中，操作系統(tǒng)又運行在硬件里。而該硬件又與其他包含不同技術(shù)堆棧的硬件通過網(wǎng)絡(luò)相連。在你的應(yīng)用與外部環(huán)境之間，以及在應(yīng)用的組件之間，通常有多個負載平衡器。我們還有 API 管理服務(wù)以及多級緩存。所有這一切，都是為了說明，基礎(chǔ)構(gòu)造數(shù)量龐雜，都可能影響應(yīng)用程序的性能！

因此，你必須細致地調(diào)整基礎(chǔ)架構(gòu)。檢查你的應(yīng)用組件和數(shù)據(jù)庫所運行的操作系統(tǒng)和硬件設(shè)備，以確保它們的最佳表現(xiàn)。測量服務(wù)器之間的網(wǎng)絡(luò)延遲，并確保你有足夠的帶寬來滿足應(yīng)用程序之間的交互。檢查緩存，確保較高的緩存命中率。分析負載平衡器的行為以確保請求很快地分發(fā)到所有可用的服務(wù)器?？傊?，你需要全面檢查應(yīng)用程序的性能，既包括應(yīng)用業(yè)務(wù)交易也包括支持它們的基礎(chǔ)架構(gòu)。