《續》“糟糕”的設計

正因為問題的存在，所以我們才知道如何進步。《糟糕的設計》一文中所提到的幾個問題都是我曾經和正在處理的。有些已經被解決，有些至今還沒有。可能很多人會問，為什麼一開始就沒有考慮好這些情況呢？記住一句話：羅馬不是一天建成的，任何優秀的產品也不是一次就能設計得很完美。

本文主要是分享三個問題，相信對很多用C#.NET開發資訊系統的朋友們有協助。

1）串連問題

1.1 不同協議的兩個Web資訊系統互傳資料的問題

當一個Web系統通過POST方式向另一個Web系統提交資料的時候，出現如下錯誤資訊：

Could not establish trust relationship for the SSL/TLS secure channel.

注意一點，這個錯誤資訊不是每次都能遇到。還有，提交資訊的Web系統是HTTP協議，接受資訊的Web系統是HTTPS協議。後來經過大家的努力，在網上找了一些資料，終於把這個問題給解決了。解決的方式很簡單：添加下面紅色框裡面的代碼就可以了。

650) this.width=650;" border="0" height="257" src="http://www.bkjia.com/uploads/allimg/131228/140SMD4-0.png" alt="image" title="image" style="border-bottom: 0px; border-left: 0px; border-top: 0px; border-right: 0px" />

具體的情況，可以參考如下兩篇網上資料：

A. RemoteCertificateValidationCallback Delegate

B. SSL Encrypted Session with ServerCertificateValidationCallback

1.2 WebService的逾時異常

由於我們平時習慣在web.config裡面設定Web Service的連線逾時時間。如，此處的300是300 Second.

650) this.width=650;" border="0" height="22" src="http://www.bkjia.com/uploads/allimg/131228/140SMP1-1.png" alt="image" title="image" style="border-bottom: 0px; border-left: 0px; border-top: 0px; border-right: 0px" />

但是，在負責付費中轉的網站另外一個單獨的網站）裡面，連線逾時長度在代碼中被設定為300毫秒自以為是300 秒），結果導致不時的連線逾時異常。而且，這個問題也不是經常可以碰到的。一般情況下，我們作為支援人員與服務工程師的第一反應是問題在網路速度上。無論何種逾時異常可能原因：網路，資料庫，交易處理），我們都建議提交請求的一端在Timed Out Exception出現時應該嘗試3次。

650) this.width=650;" border="0" height="222" src="http://www.bkjia.com/uploads/allimg/131228/140SM308-2.png" alt="image" title="image" style="border-bottom: 0px; border-left: 0px; border-top: 0px; border-right: 0px" />

2）緩衝問題

這個問題很奇怪！在幾秒鐘前我們把資料存進Cache裡面，突然間莫名其妙地丟失，導致整個付費流程失敗。後來查了一些系統日誌，發現IIS中的某一個進程進行了回收操作，所有儲存在Cache裡面的資料都被清掉。最後，我發現IIS的預設設定是每隔29個小時就會自動回收。為了避免因為Application Pool的自動回收操作導致的問題，我們建議使用者修改IIS的Application Pool的設定，採用在固定時間進行回收，例如淩晨2:00。

650) this.width=650;" border="0" height="108" src="http://www.bkjia.com/uploads/allimg/131228/140SJA2-3.png" alt="image" title="image" style="border-bottom: 0px; border-left: 0px; border-top: 0px; border-right: 0px" />

650) this.width=650;" border="0" height="345" src="http://www.bkjia.com/uploads/allimg/131228/140SKU6-4.png" alt="image" title="image" style="border-bottom: 0px; border-left: 0px; border-top: 0px; border-right: 0px" /> 

650) this.width=650;" width="584" border="0" height="408" src="http://www.bkjia.com/uploads/allimg/131228/140SH644-5.png" alt="image" title="image" style="border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-right-: " />

3）並發問題

 這個問題更加的奇怪！一般所說的並發問題，是指多個使用者同時操作某一個東西。這裡所說的並發問題，是一個使用者同一時間多次提交相同的請求資訊。例如：首先我在一個網站購買一個產品，然後跳轉到第三方去付費。在第三方付完費之後，第三方網站將會“回調”原來網站的某一個介面。按照正常的情況，原來的網站只需要根據傳回來的唯一標識碼進行處理就可以了。但是，第三方網站不知道出於何種意圖，使用相同的資訊對同一個介面“回調”了多次，前後兩次請求的間隔很短，即第一次請求還沒有處理完畢，第二條請求就提交過來，導致建立了兩條付費記錄。註：此處的回調是第三方網站通過POST方式提交資料）

很多人的想法是用鎖，問題是如何用好這把“鎖”。要做到兩點：1）支援多個使用者同時付費；2）不支援對同一個使用者的一個付費記錄同時在多個事務中處理。就好比：幾個人可以同時在不同的ATM機上取款，但是不支援同一個使用者在不同ATM機上同時取款。

650) this.width=650;" border="0" height="306" src="http://www.bkjia.com/uploads/allimg/131228/140SJI5-6.png" alt="image" title="image" style="border-bottom: 0px; border-left: 0px; border-top: 0px; border-right: 0px" />

後話

從客戶將這些問題反饋過來，我們一直用電子郵件交流直到解決，前前後後花了很長的時間。很多時候不是我們不努力，而是很多時候彼此的測試環境不一樣。所以，很多問題都沒有辦法很容易地找到問題的根源。當然，技術能力和經驗也是一個很大的因素。不過，有了這種在客戶抱怨的壓力之下工作的經曆，使得我們真正體會到客戶和使用者的感受 - 他們非常的信任我們這些技術工程師！

本文出自 “CTO-360” 部落格，請務必保留此出處http://penzhaohui.blog.51cto.com/3311602/637823