近期，公司为了锻炼开发人员技能，举办了一场涵盖多个技术线的技能大练兵，我有幸受邀负责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中遍历文件并触发部署即可。