244
分布式測試框架架構與思考(1)奠基
“工欲善其事必先利其器”。無論是哪個行業，這都是一句至理名言，軟件測試當然也不例外。這也正是分布式測試框架（下文簡稱DST）設計的初衷。
DST是海量數據項目背景下，為了解決測試集管理、運行、查詢和測試執行、控製以及監控、日誌數據的收集整理的一個通用型測試與分析平台。這個平台既包含了傳統測試框架的特點也包含了自身的開創性思想。作為DST從前端界麵到後端服務的親身經曆和開發者，下麵我將從技術選型、架構設計、功能點分析、使用場景以及周邊支持工具這幾個角度來對DST測試平台做一個總結，進一步思考和回顧，以便發現不足和需要改進之處。
第一篇 奠基
對於一個好的軟件來說，技術選型無疑是最重要的一步，這將決定軟件是否有良好的擴展性、健壯性、可靠性以及可維護性。對於DST來說，傳統的B/S是一個顯而易見的架構性選擇，那麼從前端到後端都需要有良好的Framework以及清晰的技術軌道與之配合。
好的技術選型可以大大縮短開發周期，並提高代碼的質量，減少bug產出率，優良的技術往往是具有清晰的結構化框架的，便於追蹤問題，以及向其他開發者分享代碼。
技術選型貫穿了整個DST的設計與開發始終，並經曆了多次回滾調整，最終采用現在的技術軌道並非是一件一帆風順的事情。下表列舉的是DST使用到的相關技術：
|
名稱 |
描述 |
|
Webx |
基於經典MVC設計模式的WEB框架，構建前端UI的主要骨骼脈絡，具有清晰地層次化構造，良好的擴展機製。 |
|
Velocity |
基於java的模板引擎，允許僅僅簡單的使用模板語言（template language）來引用由java代碼定義的頁麵對象。 |
|
ibatis |
持久層框架包括SQL Maps和Data Access Objects（DAO），是一種“半自動化”的ORM（Object/Relation Mapping）實現。 |
|
Jeasyui |
jQuery Easyui，基於jQuery的前端頁麵和javascript設計框架，簡單且易於上手，封裝的AJAX簡潔易用。 |
|
HBase |
一個分布式的、麵向列的開源nosql數據庫，DST利用其實現海量監控和日誌數據的存取。 |
|
Mysql |
持久化前端以及測試數據。 |
|
HighCharts |
一套界麵美觀的純Javascript圖表庫。 |
|
RESTful |
REST (REpresentational State Transfer) 描述了一個架構樣式的網絡係統。 |
|
Ueditor |
一個百度開源的富文本編輯器。 |
|
AJAX |
交互式網頁應用的網頁開發技術。 |
|
SyntaxHighlighter |
高亮顯示代碼用的Javascript庫。 |
|
Thrift |
Facebook開發的一個軟件框架，用來進行可擴展且跨語言的服務的開發。 |
|
Jetty |
開源的servlet容器。 |
其他還有一些例如SimpleTip（浮動標簽）、MapReduce（用來做nosql數據的定期備份）等技術，由於涉及不多，不再列舉。
在整個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在開發之初，有過一些並不是很適宜的對某些開發點的反複關注和修改，浪費了一些時間。這在隨後持續進行的迭代開發周期中，還是需要警醒自身，並持續改善的。一方麵避免代碼浪費，另一方麵還要和業務需求層麵多進行溝通，以便做出的產品與實際需求之間偏差較小。
綜上所述，技術選型的過程並非是一帆風順的，其過程尤其是人與人之間交互中，需要各方不斷的爭執和妥協。有些選型也並非一成不變，在發現問題之後，及時的回滾就可以了，最重要的是不可一條錯路走到黑。而我們平時更願意隻選擇自己最熟的路走，這對於開發產品來說並不是一件好事。
我認為一個比較好的習慣是，無論遇到什麼問題，哪怕是自己已有成熟想法的，都應該首先去搜索一下業界同類問題的解決辦法，能夠走大部分人共同走過的路，才是最安全可靠的。我們設計一個優秀的軟件，做一個零散部件的組裝者要比做一個從礦工開始的開發者需要付出的更少，且有更多的機會獲得成功。技術選型正是一個選擇零件的過程，這比架構的角色更為重要，無論擁有多麼優秀的架構，一個足夠分量的錯誤的零件都有可能會毀掉你設計的整座大廈。
來源：https://www.taobaotest.com/blogs/2162
最後更新：2017-04-02 16:48:16