1.首先說一下業務和需求
最高法院發佈不一樣的標的在京東、淘寶、中拍協等總共五家網拍平臺進行拍賣，法院經過內網上傳zip包（包含法院須要發佈的公告及標的等信息）到內外網交互的光閘上，光閘掃描到文件後將文件上傳到ftp服務器上各網拍平臺對應的文件目錄下，各平臺使用定時任務掃描到對應文件目錄有對應文件就下載到本地，而後解壓解析、本地備份、上傳雲備份、刪除ftp文件、刪除本地文件等等一系列步驟，最終獲取法院數據通過一系列業務處理將數據展現在頁面。如今法院2040接口變動，要求各平臺將獲拍結果返回更多的信息(競買人所有信息列表，包括競買人名稱、身份證號、聯繫方式等等)給法院，要求週四（四天時間）完成開發和上線，而後老大把這個「偉大而艱鉅」的任務交給我了，還語重心長的囑咐我必定要重視，週四必須完成上線，由於這實際上就是京東和淘寶的一次比拼，萬一淘寶按時完成任務而京東沒作好那就很尷尬了。2.說一下該業務涉及到的應用以及應用之間的交互前端
1）網關係統
負責從ftp下載文件，完成解壓解析備份工做，將解析的數據推送給拍賣中心；負責從拍賣中心獲取數據，將數據封裝成xml打成zip包，最後把zip包上傳到ftp，供法院下載，網關係統不作任何業務處理
2）拍賣中心(拍賣後臺)
拍賣中心負責拍賣幾乎全部業務的處理，數據的存儲，將數據推送給拍賣前端
3）拍賣前臺
拍賣前臺是單獨的一個研發團隊，拍賣前臺相似於京東的單品頁，負責將數據搞成頁面展現給用戶，不一樣的是，拍賣前臺獲取拍賣中心的數據會存儲在本身的數據庫，最終擁有本身的主數據，聽說我們立刻要跟拍賣前臺研發團隊進行一場撕逼，將主數據大權「搶奪」過來，讓我們的拍賣中心占主導地位。git
2.說一下經常使用的中間件技術
1）JSF京東傑夫服務框架
jsf相似於webService，在京東幾乎全部系統間的系統交互都是經過jsf完成的，拍賣前臺、拍賣中心、網關係統之間數據的交互也離不開傑夫，具體的jsf原理就不講了。
2）JMQ京東消息隊列
也常常用於系統間和系統內的信息交互，具備解耦、異步和削峯值的優勢，用戶在拍賣前臺完成交保證金、出價最終獲拍等操做，拍賣前臺都會發送MQ消息到拍賣中心，拍賣中心作一系列的業務處理後也是經過MQ的形式將數據id發送到網關係統，網關係統收到MQ消息後經過id調用拍賣中心的傑夫接口查詢相關信息，而後封裝成xml打成zip包等等，MQ具體的原理就不講了，網上一搜一大把
3）J-ONE自動部署系統
J-ONE是用來部署應用到預發環境（預生產環境，走的是線上數據）和線上生產環境的，J-ONE會直接從git地址上拉取你想要部署應用的分支，而後進行項目的編譯和發佈。
web
3.從熟悉到開發：
這個需求看似很簡單，可是在個人第一想法裏，涉及到的應用不少，做爲一個拍賣業務小白，首先我能想到須要變更的地方有這些，拍賣前臺經過MQ給咱們推送的獲拍結果的數據須要改變、身份證信息好像是存儲在用戶組那邊的，須要跟用戶組溝通調用用戶組接口查詢身份證信息、中心推送給網關係統的獲拍結果數據須要改變、網關將獲拍結果封裝成2040xml配置文件信息須要改變、xsd約束須要更改成按照法院給的格式等等，涉及到多個應用間的數據交互，溝通難度、開發難度和測試難度天然天然少不了。這樣一來，四天時間仍是很是緊湊的。
固然，以上這些都是基於本身對業務和流程不熟悉瞎想的。
週日把這一系列代碼流程都看了一遍，而後記錄一些不肯定的業務，週一上午找相關產品真正把全部業務都弄明白了，而後又仔細梳理了一下本身的設計思路，oh，個人天哪，簡直是把我嚇到了。
4.從開發到測試：
其實真的很簡單，簡單到我感受均可以放在週四開發了，哈哈，固然不能這麼幹，這麼驕傲會被打臉的，結果~~~真被打臉了。
週一下午花了幾個小時就開發完了，想一想還有點小激動，晚上還想着搞搞些其餘的事呢！其實這一塊的開發徹底不須要再讓拍賣前端對拍賣中心提供任何數據，這樣一來就少了一個須要打交道的應用了，競買人信息這些數據在獲拍結果以前的交保證金操做時就已經從拍賣前臺給拍賣中心了，數據都存在我們本身的數據庫裏，而中心提供給網關的MQ消息體也不須要變，只是須要在中心提供查詢全部競買人信息的接口供網關調用便可，當網關收取到MQ消息後，根據id調用中心接口獲取數據，而後網關再按照相應的xml格式把獲拍結果數據封裝起來就ok了。
開發很簡單，最難的就是測試了，這麼一小功能測試總共花了三天時間，天天還累成狗。。。
5.從測試到測試：
首先是本機自測，因爲測試環境限制，本地測試只能寫測試類去測試接口了，中心打包上傳私服，網關升級jar包，中心本地開8088端口起服務，網關開80端口用測試類調用中心接口，測試沒問題，數據能獲取，按道理說這一塊沒問題就基本沒問題了。但是我們的程序啊，我們的測試啊，就是不跟你講道理。
額，準備上預發環境測試時，我們組的測試女同事要求我這個功能跟另一個同事開發的功能合在同一分支一塊兒測，其實在我看來這種狀況最好分開測，由於這兩個不一樣分支改動比較大，功能又互相干擾和影響並且我這個優先級又是最高的必須週四上線，因此我認爲分開測試分開上線比較好，正所謂好男不跟女鬥，研發不跟測試鬥，我認慫了，結果週二咱們就開始了瘋狂的測試了。
兩個小功能，整整測三天啊！三天吶！阻礙咱們的不是別人，是。。
1)法院規定拍品上拍時間最低一個小時，不然xsd校驗過不去，所以，測數據造完後，最低一個小時才能看到結果
2)沒有限制機器消費MQ致使錯誤數據
預發環境就是線上環境，咱們要在線上作測試，最重要的一點就是不能影響線上數據，咱們都很聰明，中心預發機器和網關預發機器都知道改配置文件中的jsf別名，目的就是爲了網關預發機調用的恰好就是中心預發機而不是中心線上機器，本覺得就能夠這樣開開心心的造幾條數據開始測試了，咱們只要時刻盯着日誌就能夠了，剛傳完數據，而後去線上頁面交保證金，等呀等呀一個小時眼看就到了，繼續盯着日誌，結果拋出了一大堆異常，從異常信息來看，調用中心接口返回信息爲null，致使網關拋異常，拋出異常會致使MQ消息一直重試，重複繼續調用，就這麼一直調用一直拋異常，如今咱們最關心的就是爲何調用中心返回爲null，跟蹤了一下中心代碼發現當表中數據有一個字段爲null時就會給網關傳null，可是爲何這個字段會爲null 啊，按理說不該該存在這種狀況，結果發如今交保證金的時候，前臺會發送MQ到中心，因爲MQ沒有打到擁有我們開發的分支的預發環境上而是打到線上機器，因此處理的邏輯就按照線上機器代碼邏輯處理了，致使插入數據庫的數據有問題，最終網關獲取數據的時候就獲取不到相應數據了
3)限制機器消費MQ有延時
意識到這個問題後，咱們就去JMQ消息管理平臺限制線上機器消費MQ了，由於限制線上機器消費的話，風險很大，可能會致使法院獲取不到數據，可是有得必有失，爲了測試這也是沒有辦法的辦法了，因而每次交保證金的以前咱們都會去限制一下線上機器的ip，保證拍賣前臺發送的MQ恰好能被我們中心的預發機器消費，到了快要結束的時候又去限制一下中心提供給網關消費的MQ，消費完以後爲了避免長時間佔用而影響線上數據，咱們就趕忙放開，因而咱們真的就這麼作了，結果造完一條數據再測一遍，發現仍是出現了一樣的錯誤，查看數據庫結果仍是出現了錯誤數據，看日誌發現又是被線上機器消費了，額，好吧，這下懵逼了，這招無論用啊，而後猜測是否是限制有延時，從新造一條數據，每次操做前五分鐘加限制，一小時事後，好像還真管用了，可是再最後獲拍結果的時候又拋出了異常，connection refused，這是爲何？？
4)測試環境沒有ftp服務器
鏈接被拒絕，第一反應就是是否是鏈接ftp達到上限了（上傳和下載控制最多四個鏈接），因爲拋異常致使MQ一直重試，重試完以後開始消費，而後生成zip包獲取鏈接準備上傳ftp固然會佔用一個鏈接了，沒辦法了只能把重試的消息給刪了，次日，咱們才得知預發環境上配置的ftp過時了，致使一直鏈接不上。
5)JMQ限制黑名單出問題了
上午測試好好的，能生成2040文件，測得都是成交的狀況，沒有問題，下午準備測一下流拍的狀況，測試同事造好的數據正常上傳，，，一個小時過去了，結果差很少就要出來了吧，what fuck？竟然沒有競買人信息所有列表標籤？？？雖然沒有競買人信息，可是起碼也得有個空標籤吧，個人第一反應就是個人代碼寫的有問題，苦苦思索加上找資料並無發現任何問題，因而我開始寫一個測試類，在本地環境測試流拍狀況，生成的2040卻意外地顯示正確了，難道測試環境沒問題，預發環境就有問題了？即使如此，我仍是果斷排除是代碼的問題，轉眼去logbook查看日誌，額。。。一個同事用個人別名上了本身的分支，好吧，處理完這個問題後，又開始在預發上測試流拍的狀況，這下總不會有問題吧，一遍遍的造數據，結果也挨個出來，但是經過查看日誌，全部的mq消息全被線上機器消費了，這時我清楚地知道，限制ip黑名單功能無論用了。
6)把1小時的測試改爲6分鐘
次日問了中間件部門jmq管理團隊，的確他們給的反饋就是昨晚jmq不太穩定，而後咱們用一樣的方法又測了一遍，由於測試狀況分不少種，而每次都要等一個小時，何況今天就要上線，迫在眉睫啊，因而咱們梳理了那一塊的業務，將前臺頁面展現時間改爲了5分鐘，意味着每五分鐘就能看到拍賣結果，改完以後開始測了，第一條測試數據生成了2040文件，看到zip包我都是一種忐忑的心情不敢點開，就怕格式不對，最後點開發現沒問題這才放鬆了心情。。
6.從測試到上線
上線之路很平坦，上線前記住升級jar包，日誌級別從INFO改成ERROR，時間改回一個小時就ok了。
7.總結：
從不熟悉到熟悉，中間的測試過程碰到了許多坑，可是填坑讓我學到了不少，讓我更全面的掌握了Jmq的使用，更加熟練的去差日誌寫測試類去排查問題，仍是那句話碰到的坑越多，記憶越深入，成長的越快。