今天在觀察叢集時，發現nn節點的負載過高，雖然對nn節點的資源進行了調整，同時對nn節點上的應用程式進行重新打包調整，負載問題暫時得到緩解。但是，我想了想，這樣也不是長久之計。通過這個問題，我重新分析了一下以前應用部署架構圖，發現了一些問題的所在，之前的部署架構是，将打包的應用直接部署在hadoop叢集上，雖然這沒什麼不好，但是我們分析得知，若是将應用部署在dn節點，那麼時間長了應用程式會不會搶占dn節點的資源，那麼如果我們部署在nn節點上，又對nn節點計算任務時造成影響，于是，經過讨論後，我們覺得應用程式不應該對hadoop叢集造成幹擾，他們應該是屬于一種松耦合的關系，所有的應用應該部署在一個appserver叢集上。下面，我就為大家介紹今天的内容。
由于之前的應用程式直接部署在hadoop叢集上，這堆叢集或多或少造成了一些影響。我們知道在本地開發hadoop應用的時候，都可以直接運作相關hadoop代碼，這裡我們隻用到了hadoop的hdfs的位址，那我們為什麼不能直接将應用單獨部署呢？其實本地開發就可以看作是appserver叢集的一個節點，借助這個思路，我們将應用單獨打包後，部署在一個獨立的appserver叢集，隻需要用到hadoop叢集的hdfs位址即可，這裡需要注意的是，保證appserver叢集與hadoop叢集在同一個網段。下面我給出解耦後應用部署架構圖，如下圖所示：
從圖中我們可以看出，appserver叢集想hadoop叢集送出作業，兩者之間的資料互動，隻需用到hadoop的hdfs位址和java api。在appserver上的應用不會影響到hadoop叢集的正常運作。
下面為大家示範相關示例，以wordcountv2為例子，代碼如下所示：
在本地ide中運作正常，截圖如下所示：
然後，我們将wordcountv2應用打包後部署到appserver1節點，這裡由于工程是基于maven結構的，我們使用maven指令直接打包，打包指令如下所示：
然後，我們使用scp指令将打包後的jar檔案上傳到appserver1節點，上傳指令如下所示：
接着，我們在appserver1節點上運作我們打包好的應用，運作指令如下所示：
但是，這裡卻很無奈的報錯了，錯誤資訊如下所示：
首先，我們來定位下問題原因，我将打包後的jar在hadoop叢集上運作，是可以完成良好的運作，并計算出結果資訊的，為什麼在非hadoop叢集卻報錯呢？難道是這種架構方式不對？經過仔細的分析錯誤資訊，和我們的maven依賴環境，問題原因定位出來了，這裡我們使用了maven的assembly插件來打包應用。隻是因為當我們使用maven元件時，它将所有的jars合并到一個檔案中，所有的meta-info/services/org.apache.hadoop.fs.filesystem被互相覆寫，僅保留最後一個加入的，在這種情況下filesystem的清單從hadoop-commons重寫到hadoop-hdfs的清單，而distributedfilesystem就會找不到相應的聲明資訊。因而，就會出現上述錯誤資訊。在原因找到後，我們剩下的就是去找到解決方法，這裡通過分析，我找到的解決辦法如下，在loading相關hadoop的configuration時，我們設定相關filesystem即可，配置代碼如下所示：
接下來，我們重新打包應用，然後在appserver1節點運作該應用，運作正常，并正常統計結果，運作日志如下所示：
這裡需要注意的是，我們應用部署架構沒問題，思路是正确的，問題出在打包上，在打包的時候需要特别注意，另外，有些同學使用ide的export導出時也要注意一下，相關依賴是否存在，還有常見的第三方打包工具fat，這個也是需要注意的。
這篇部落格就和大家分享到這裡，如果大家在研究學習的過程當中有什麼問題，可以加群進行讨論或發送郵件給我，我會盡我所能為您解答，與君共勉！