項目需求：讀取阿里雲數據庫數據，通過webservice接口上傳給第三方。
概要設計,項目滿足以下幾點：
1、動態接口調用
2、給多平臺上傳
3、數據保持（減輕數據庫壓力）
4、上傳任務管理
5、擴展成實時數據服務器
實現方案：
設計1：對於第一個需要我們上傳數據的平臺給出的藉口是webservice接口（不能get/post表單訪問的那種），考慮到以後可能會有類似於restful/webapi之類的接口，
所以此處必須採用動態接口調用。目前實現了webservice動態接口訪問。關於動態訪問，有2中實現思路，第一種：預讀取WSDL，動態編譯，反射方法，調用。
由於我在項目中實現第一種方法失敗了（動態編譯時死活不能加載程序集，未解決的問題），因此我用了另外一種思路，通過字符串構造滿足soap協議的xml發送給接口。
此處採用了開源的 https://github.com/LiveXY/Pub.Class/blob/master/Pub.Class/Class/WebService.cs
設計2：以後有類似於此項目結構的需求，爲了避免重複開發，因此這裏定義了上傳平臺，平臺包括接口（全部構建在XML中），動態讀取。
但是目前所有的接口都未知，不知道將會是什麼結構或者需求，因此這裏實現的比較粗糙。但是比較大尺度的隔離了各個平臺的操作，因此擴展性也是比較強。
設計3：當需要上傳的項目較多，重複索引同一個項目的數據的時候，勢必會給數據庫服務器造成很大的壓力，因此，這裏做了數據保持，通過項目的結構形式，將數據保存在內存中，
滿足一定的條件纔去從數據庫讀取數據。（爲做成實時數據服務器做準備）。但是由於時間 原因，沒有繼續朝設計5去設計實現。
設計4：系統採用Quartz.net組件實現定時上傳作業，使用過程中碰到的坑有關於時區問題和單次觸發（triggerJob）無效。在實踐中發現時區問題不存在，即時存在也可以通過cronExpress 的合理設置而避免。單詞觸發無效，我找來了源碼，一步步執行下去，發現又沒有問題了（amazing！懷疑跟載入的符號系統相關跟動態編譯不能載入程序集一樣沒解決）
關於任務管理，作爲第二版的功能實現，此處暫時不實現。
設計5：預計將來擴展成實時數據服務器，開放webservice給外界調用數據，目的爲了減輕數據庫服務器壓力，由於時間原因，暫未實現！
補充：該項目同時使用了log4net組件和Newtonsoft.Json。採用DevExpress實現的簡單界面。
log4net使用步驟總結，引用組件、編寫log4net配置文件、啓動log4net，通過assembly或者log4net.Config.XmlConfigurator.Configure()載入啓動、getlogger、寫入。
總用時11天。（框架設計4天，業務邏輯代碼實現2天，關於任務以及學習Quartz.net2天，webservice動態調用2天，測試和補充log4net寫日誌1天）