用Springboot幹掉IBM的WAS-爲公司省點錢

1 那一晚上，你傷害了我

今夜的雨下得涼快，小南睡得正香，忽然收到遠洋運維小周的電話：Hello, Are you OK? WAS有issue，快起來help me!

只見小南登錄WAS機，查看了機器日誌、應用日誌，終於定位了問題，登上WAS管理界面，一頓操做猛如虎，應用終於恢復了。但不記得這是第幾回新人不懂WAS而向小南求救了。

次日，小南向領導呈上《替換WAS表》，開始了一場浩蕩的服務器之戰。其文曰：

先弟修bug未半，而中道離職。今WAS已老，Springboot又新，此誠用Boot換WAS之秋也。

......

今當替換，臨碼涕零，不知所言。

所謂WAS，即IBM的WebSphere Application Server，是一種Java應用服務器。相對Tomcat等，會更重型，更復雜；更重要的是價格昂貴。得益於IBM及它一整套的企業開發套件，也仍是有必定的市場佔有率，特別是在傳統行業裏。

隨着技術向前發展與以前轟轟烈烈的去IOE運動，用WAS的人愈來愈少了，許多新人更是徹底沒有接觸過，又因其價格昂貴且不利於DevOps，我司決定要替換掉它。經討論，代替它上場的就是如今紅紅火火的Springboot，緣由衆多，如開源免費、開箱即用、利於發佈、容易運維等。

2 大刀闊斧仍是小打小鬧

硬件、軟件同時替換，就必須謹慎當心，主要方案以下：

（1）硬件上從裝有WAS機器的Linux轉移到普通的Linux機器，但須要注意關鍵指標如處理器、內存、硬盤等。

（2）軟件上從以前打成war包，現改成jar包，包結構徹底改變，引入Springboot後，Spring容器和bean要對應調整、數據庫池化也對應調整。原來WAS跑的是SOAP Webservice，現經過Springboot整合cxf-spring-boot-starter-jaxws實現。

（3）網絡上依然是https協議，但之前WEB服務器爲IHS，如今直接使用Springboot，證書須要從新生成和導入。客戶端證書要先從IHS服務器的密鑰文件導出，須要查看IBM官網資料。

關於https的內容可參考：HTTPS專題。

同時引入新的負載均衡器F5，且須要在上線當天更新DNS到新F5上。結構圖以下：

服務器1與服務器2在同一個數據中心，正常運行時處於工做狀態。若是該數據中心發生災難（如地震等），就會啓用服務器3，並把DNS更新到災備服務器的地址。

（4）發佈上由手工發佈改成Ansible發佈，可減小人力和錯誤風險。

（5）監測上有日誌監控，但Springboot日誌文件更少更集中，同時Springboot可整合Springboot Admin，可參考：用Springboot Admin監控你的微服務應用。

（6）UAT須要實現多環境部署，可經過maven實現。

3 測試

任何變動都有可能出錯，都會引入風險。由墨菲定律可知，凡是可能出錯的事就必定會出錯。因此測試變得極爲重要。在整個項目的測試中，功能測試和端到端測試都發現了問題，因此不要放過能夠發現問題的機會，否則上了生產再出現，成本可過高了。

所謂君子不立危牆之下，讓咱們看看都怎麼測試。

3.1 單元測試

單元測試在開發階段就要完成，特別要關注測試覆蓋率、圈複雜度等指標。可使用Sonar、Findbugs等工具進行檢測，能夠參考下面的文章：

Maven整合JaCoCo和Sonar，看看你的測試寫夠了沒

Docker搭建代碼檢測平臺SonarQube並檢測maven項目

3.2 功能測試

根據業務定義測試場景，儘可能全面。特別是基線用例，必須覆蓋。能夠增長異常場景的用例，保證服務不會受影響，依然保持可用；錯誤場景是否有合理的告警，也是很關鍵的。

3.3 性能與壓力測試

測試出關鍵性能指標，看是否能知足如今的生產需求，要特別注意測試環境與生產環境的差別有多大，測試報告有多大的參考價值。壓力測試能夠分爲兩類，大請求和高併發，大請求是一個請求數據量很大，高併發是指多個請求同時產生。

3.4 端到端測試

聯繫其它相關團隊（客戶端，即請求端）進行端到端的測試，在測試環境發送正式的請求。

4 上線

領導說過，生產是最好的測試環境，哈哈，測試差很少了，就該上生產了。

但上生產不是那麼容易的事，首先要確保發佈的這個downtime沒有客戶端發請求過來，須要和其它團隊約定好時間停服。更重要的是，由於但願只是本身作變動，不能要求別人作變動，因此域名不能變，就須要找網絡團隊更新DNS到新服務上。

爲了縮短停服時間，提早把Springboot部署到新服務器上，並把新服務器配置在新的F5上，發佈那天直接更新DNS到F5上便可。DNS更新完成後，找客戶端發送請求進行測試，沒有問題即大功告成了！

雖然已經成功上線，但舊服務器仍是要並行一段時間，萬一新服務出問題，緊急狀況難以修復，還能夠回滾。

5 還能再作什麼

雖然已經上線了，但仍是有更多東西能夠作的。

文檔：人的記憶都是不可靠的，同時也要減小人員流動的風險，須要經過文檔把相關內容記錄下來，並分享到整個團隊。主要內容有開發過程、架構原理、生產環境運維指南、測試環境使用、關鍵知識索引等。

災備測試：作了災備，但並無測試。還好公司要求按期要作災備測試，到時能夠覆蓋，如今沒作會增大風險。

ELK：日誌收集沒有統一到日誌平臺，須要登錄到指定機器查看。幸虧所用的機器很少。

Metric指標：能夠收集JVM內存、CPU、GC等信息，以便定位問題，能夠展現到Grafana上。

OpenTracing：能夠記錄每次請求的詳細狀況。可參考：實例講解Springboot整合OpenTracing分佈式鏈路追蹤系統（Jaeger和Zipkin）

REST/RPC改造：如今的服務爲XML格式的WebService，可改造爲RESTful+Json或gRPC。

最後，並非引入新技術就是好的，有時候須要KISS(Keep it simple and stupid)，簡單能用就是好的，不要想着搞些大新聞，這樣有時間仍是很naive的。

6 總結

小南獨立完成了此次改造後，去了趟黃山修練內功，修仙成果以下：黃山徽州五日行-最美風景與攻略獻給你。

回來後，又開始新的征程，此次要改造整個舊系統：System Entire Rebuild (SER)。後續如何，請聽下回糞解。

---

歡迎訪問南瓜慢說 www.pkslow.com獲取更多精彩文章！

歡迎關注微信公衆號<南瓜慢說>，將持續爲你更新...

多讀書，多分享；多寫做，多整理。