如何組織一場JAVA技能大練兵

近期，公司爲了鍛鍊開發人員技能，舉辦了一場涵蓋多個技術線的技能大練兵，我有幸受邀負責java技術方向的出題和評審工做。下面從如下幾個方面回顧下整個過程：

• 題目設計
• 程序要求
• 測試方法

題目設計

題目設計主要考慮如下幾點：

• 技術演進需求：在公司系統雲遷移的戰略背景下，咱們的應用即將從原來傳統的虛擬機部署向PAAS雲環境進行大規模遷移，須要開發人員掌握雲環境的開發技能，應用開發框架須要從原來的SpringMVC+dubbo升級爲SpringCloud服務治理框架。

• 新老員工兼顧：目前公司的開發人員構成中，入職一兩年的新員工超過一半，題目設計須要考慮到新員工的技能水平，不宜難度過大，不然會打消新員工參與的積極性。同時，還須要能體現正真的技術實力，不能由於題目過於簡單而使得分數拉不開差距。所以，題目設計要使你們都能完成基本功能，同時拿高分的難度較大。

• 解決生產難題：大練兵的初衷就是鍛鍊開發人員技術實力，提高企業級應用的開發技能，更好的完成平常任務，最終要解決生產難題，保障線上系統穩定。相似力扣網上的算法題，不適合做爲這次大練兵的題目。

基於以上幾點考慮，最終題目設計以下：

完成一個交易系統：
產品子系統（product）、訂單子系統(order)、積分經驗子系統(experience)，3個子系統完成分佈式部署和調用。
業務場景：
一筆交易過程當中，產品子系統要扣減庫存，訂單子系統要新增訂單，積分子系統要有相應的積分增長。積分規則爲每消費1元增長1積分。

功能要求：

完成5只接口：下單、查詢庫存、查詢訂單、查詢積分、我的交易信息概覽

題目意在考察你們在完成基本功能的同時，如何保證數據的一致性。

程序要求

根據前期統計的報名意向來看，預計會有50人左右提交比賽交付物。這麼多交付物若是要依靠線下演示評審打分的話，週期很長，並且須要人工部署調試，帶來巨大的工做量。所以，必須使用自動化的方式進行打分。同時爲了控制程序實現範圍，防止開發人員無限蔓延開發需求，增長過多考察範圍以外的擴展，所以對程序作了如下限制：

• 中間件限制：因爲本次大練兵意在爲後續的雲遷移作技術儲備，所以中間件的選型必須控制在雲上中間件的範圍內，所以要求使用SpringCloud+consul的服務治理框架、Nginx軟負載等中間件，不能使用Apache、Dubbo等雲上不用的中間件。

• 數據格式：題目提供3個子系統中核心的數據庫表結構，例如產品信息表、訂單信息表、用戶經驗表等。同時給出5個接口的上送和返回字段，全部人必須按照此格式對前提供服務。

• 組包格式：因爲決定要實現自動化的打分程序，就必需要統一組包要求，包括壓縮包的目錄層級結構、sql腳本格式、nginx配置文件、start和stop腳本等。題目要求必須實現3個模塊（product、order、experience），同時提供了一個可選的其它模塊（other），參賽者可根據須要本身實現，如網關、聚合服務等功能均可以放在other模塊實現。other模塊組包要求同其它3個模塊一致。

本次題目主要的考察難點是如何保證數據的一致性。可是因爲測試環境是同網段的機器，內網測試環境很是穩定，在正常的程序運行過程當中，很難發生數據不一致的狀況。如何產生使數據可能不一致的事件，是本次出題的重點。

所以除了以上幾個限制，本次大練兵還引入了一個大殺器：chaos-monkey。

chaos-monkey：是由netflix開源的一款軟件，它能在生產系統中隨機產生異常事件，包括超時、程序異常、宕機等。chaos-monkey的想法源自於「混沌工程」。

混沌工程，是一門對系統進行實驗的學科，旨在瞭解系統對應生產環境各類混亂情況的能力，創建對系統的信心。經過開展混沌工程方面的實驗，能夠測試出系統是否存在缺陷，從而瞭解系統在混亂的生產條件下如何表現。

chaos-monkey的原則，避免大多數失效的主要方式就是常常失效。經過常常在生產環境製造故障，以保證生產環境的彈性。

本次比賽提供了chaos-monkey的jar包和配置，要求參賽者必須引入，以模擬超時或者異常，從而引起數據不一致，測試程序的健壯性。

測試方法

測試主要分爲兩步驟：自動部署和自動測試。

服務拓撲圖以下：

自動部署

全部選手的交付物都提交到統一的ftp目錄，所以從ftp中遍歷文件並觸發部署便可。

流水線步驟以下：

for(遍歷ftp上的包)
    清除redis緩存
    執行題目提供的sql建表語句，初始化數據庫
    從FTP獲取壓縮包，並解壓
    If(有nginx配置文件)
	替換nginx配置文件，並重載
    else
	分發默認的nginx配置文件，並重載
    執行鋪底數據腳本
    For(遍歷服務個數)
	按規則將各個服務壓縮包分發至各服務節點
	if(存在額外的init.sql)   
            執行init.sql
	執行服務的啓動腳本start.sh
    運行測試腳本，收集測試結果，計算分數，並輸出到CSV文件
    中止各服務

一般狀況下，自動部署使用Jenkins實現。可是Jenkins不支持循環遍歷，一個job只能完成一個參賽者的部署和測試。若是每一個參賽者一個job，不能保證每一個job配置的正確性，而且因爲只有一套評審環境，每一個人一個job的話，不能保證job的串行執行，多個job同時執行會相互影響。所以決定本身編寫部署腳本，僅在部署完成後，須要測試時觸發測試job，由測試job完成測試和打分。部署腳本監聽測試job的狀態，測試完成後，再開始執行下個參賽者的部署流程。

自動化測試

公司原本就具有完善的Robot Framework自動化測試基礎設施，本次測試直接使用便可。因爲部署程序已經在程序啓動前完成了數據庫和緩存的初始化，所以測試程序僅需讀取測試數據並向Nginx發起調用便可。

因爲要測試程序異常時，數據的一致性，所以要在測試開始以前開啓chaos-monkey，在執行寫入數據的邏輯後（即下單接口），關閉chaos-monkey，再開始查詢，經過查詢各個接口的數據並於寫入的數據相比對，驗證數據的一致性，並打分，步驟以下：

1.開啓各服務的chaos-monkey功能；

2.執行寫數據的測試腳本，即調用數百次下單接口；

3.關閉各服務的chaos-monkey功能；

4.執行單個數據查詢接口，驗證每一個接口的可用性，並記錄分數；

5.執行組合驗證邏輯，驗證多個服務的數據一致性，並記錄分數。

每一個參賽者的測試執行完成後，要將計算的分數寫入彙總到csv文件中。拿到最終的csv文件後，便可利用excel實現按照成績排序。

思考

經過本次大練兵，有如下幾點思考：

• 工具建設要持續投入：工具建設可以使用最小的成本，獲取最大的收益。這次練兵，開發部署流水線和自動化測試腳本各投入1人，僅在2周內使用業餘時間就完成了開發和測試，比人工部署、演示、測試的成本要低得多。同時工具可重複執行，每次修改完後自動觸發。平常的開發和測試過程應儘量多的使用工具去作迴歸測試，避免人爲疏忽引發的分析遺漏而沒回歸覆蓋。
• 環境問題不容忽視：每一個人都能在本身的環境中跑通程序，可是在評審環境中，有些程序卻沒法運行。所以在平常測試過程當中，咱們除了程序自己的正確性之外，還需關注環境差別可能帶來的問題。這裏順帶吐槽一下，若是公司能使用docker等容器技術，將會提高咱們的版本質量，下降因環境不一樣而出錯的機率。
• 規範意識有待提升：雖然題目中已經將組包格式、程序端口等作了要求，也已將注意點通知到全部人，可是仍是有不少人沒有遵照，致使測試程序跑分較低。這反映出大部分開發人員的特色，只管悶頭寫代碼，卻忽視了規範要求，致使往後返工，甚至產生線上故障，致使嚴重的後果。建議你們在平常編碼以前，提早熟悉並遵照規範和要求，避免走彎路。

最後，感謝你們對個人容忍。2021，願全部程序都不出bug！