--------------------------------------------------------------------------------
對于一個好的軟件來說，技術選型無疑是最重要的一步，這將決定軟件是否有良好的擴展性、健壯性、可靠性以及可維護性。對于DST來說，傳統的B/S是一個顯而易見的架構性選擇，那么從前端到后端都需要有良好的Framework以及清晰的技術軌道與之配合。
在整個DST的開發周期中，圍繞技術選型，曾經發生過幾次重要的爭論，列舉如下：
1、框架之爭
DST之前有Kelude測試平臺可以借鑒，Kelude采用Ruby語言的Rails框架，其特點是輕巧靈活，代碼極少重復，開發效率極高。然而考慮到精通Ruby語言的程序員不多，后端服務的技術人員大多精通Java而非Ruby，且海量數據平臺的大部分產品都是Java開發（如Hadoop），將來在DST與測試場景接合的時候，相同的語言可以省卻很多麻煩。最終定選的Webx作為一個成熟的MVC設計模式，在淘寶的使用很廣泛，有大量資料實例可以參考。
持久層采用Hibernate還是ibatis，這要歸功于我們團隊的leader葉渡的技術選型，在后來的開發過程中，不談外部的一般說法，我的感覺是ibatis結構非常清晰，sql語句完全被抽象到了sqlmap文件中，適合DBA以及其他開發人員對sql語句的審核。從DAO接口到之上的事務層，都可以通過ibatis很好的管理起來。但是ibatis從生成到增刪改非常繁瑣，增加一條sql語句，一般情況下至少要修改6、7個文件，這個過程很容易出錯。
2、UI設計之爭
作為后端測試工程師，因為我在DST立項開始的時候并沒有太多的前端開發經驗，因此在UI設計上，曾經發生過是否要專業UED參與的爭論。這個爭論雖然之后隨著DST的開發漸漸消失，但此時提及，是為了記錄我在設計過程中的一些思考。
我覺得DST如果有專業的UED協助進行用戶體驗的設計那是最好不過的事情，但是對于此類項目的開發早期，很多功能點不是很清晰的情況下，由開發人員掌握住整個流程還是相當有必要的。開發者的親身參與會省去許多探雷的過程，且測試人員自己才最清楚需要一個什么樣的系統，UED的參與更多從普通用戶角度思考，而測試框架作為一款特殊的軟件產品，更需要從開發者角度去思考他們的操作習慣。
3、海量數據持久化之爭
身處海量數據開發項目，自然少不了和動輒上千個節點的集群打交道，從這些集群收集到的監控數據和日志數據的量也可以用浩如煙海來形容。按常規經驗，一個百臺規模的集群，收集到的監控數據一年約有8TB，傳統關系型數據庫撐住這樣的數據量還要保持高效的并發讀寫效率，往往需要一個很有經驗的團隊來支撐，分表操作會成為一個常態。而我們所需的查詢動作往往又非常簡單，基本上都是掃描一段時間內的數據。這恰好是nosql型數據庫最擅長的領域。
但是在這部分設計之初，我們發生了關于持久化是通過直接存取二進制文件方式，還是存取HBase方式之爭。
直接存取二進制文件方式的理由是，可以直接從RRD（Round Robin Database）數據庫文件中讀取所需的監控數據，對查詢請求可以通過固定算法計算出數據所在位置后，用seek函數直接跳轉過去進行連續讀取，好處是速度快，硬件資源需求少。但這樣的方式帶來的問題，一是查詢依賴于編程，不利于查詢方式的擴展和數據挖掘；二是沒有足夠可靠的數據冗余備份方案，一旦機器損壞，數據就將發生不可逆轉的丟失；三是擴展性不夠，能夠hold住百級別節點的集群，并不意味著我們僅僅只有百臺機器需要存取監控和日志數據，一旦規模擴大，這樣的解決方案將面臨無法動態擴容的危險。
最終我們選擇了將監控和日志數據存到HBase中這個方案，上述的三個問題都不會發生。而在后來的設計中，我進一步發現與其從gmond保存的RRD數據庫文件中讀取監控數據，不如通過替代gmond master節點的方式來直接解析xml形式的監控數據。這樣可以避免磁盤操作這個性能瓶頸，數據流完全是從內存到網絡（gmond）再到內存（我們的工具）再通過網絡到HBase集群的內存中。整個過程完全將沒有磁盤這種慢速設備的干擾。關于這部分的詳細設計思想，我將會在后文中繼續描述。
4、敏捷開發模式實施之爭
采用敏捷開發模式是DST設計過程中不可忽視的一個重要技術選型。按照書本上的定義：敏捷開發強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重做為軟件開發中人的作用。
而DST在開發之初，有過一些并不是很適宜的對某些開發點的反復關注和修改，浪費了一些時間。這在隨后持續進行的迭代開發周期中，還是需要警醒自身，并持續改善的。一方面避免代碼浪費，另一方面還要和業務需求層面多進行溝通，以便做出的產品與實際需求之間偏差較小。
綜上所述，技術選型的過程并非是一帆風順的，其過程尤其是人與人之間交互中，需要各方不斷的爭執和妥協。有些選型也并非一成不變，在發現問題之后，及時的回滾就可以了，最重要的是不可一條錯路走到黑。而我們平時更愿意只選擇自己最熟的路走，這對于開發產品來說并不是一件好事。
我認為一個比較好的習慣是，無論遇到什么問題，哪怕是自己已有成熟想法的，都應該首先去搜索一下業界同類問題的解決辦法，能夠走大部分人共同走過的路，才是最安全可靠的。我們設計一個優秀的軟件，做一個零散部件的組裝者要比做一個從礦工開始的開發者需要付出的更少，且有更多的機會獲得成功。技術選型正是一個選擇零件的過程，這比架構的角色更為重要，無論擁有多么優秀的架構，一個足夠分量的錯誤的零件都有可能會毀掉你設計的整座大廈。