1. 阿里云短信服务基础配置第一次接触阿里云短信服务时我被它复杂的控制台界面弄得有点懵。不过实际操作下来发现企业级短信通知的配置流程其实就像搭积木只要按步骤来就能搞定。这里分享下我在工单系统中配置短信通知的真实经历。首先要在阿里云官网完成企业实名认证这个过程需要准备营业执照和法人身份证。有个坑我踩过如果公司注册地和运营地不同要特别注意选择正确的地区。认证通过后在访问控制RAM页面创建子账号并授予短信服务权限这比直接使用主账号AccessKey安全得多。短信签名审核是最容易卡壳的环节。我们第一次提交的签名是XX科技系统通知结果被拒了原因是需要明确说明短信用途。后来改成【XX科技】工单系统通知才通过。建议签名格式采用【公司名】用途说明通过率会高很多。模板审核更是个技术活。我们有个模板内容是您的工单${orderId}已被${operator}处理结果${result}审核时要求提供每个变量的使用证明。后来我们把${result}改成固定选项完成/驳回并附上系统截图才通过。实测发现包含动态变量的模板最好控制在3个变量以内。2. Java项目环境搭建在Spring Boot项目中集成阿里云短信SDK我推荐用Maven管理依赖。除了官方提供的核心SDK还需要注意日志组件的兼容性问题。以下是我们的pom.xml配置dependency groupIdcom.aliyun/groupId artifactIddysmsapi20170525/artifactId version2.0.23/version /dependency dependency groupIdcom.aliyun/groupId artifactIdtea-openapi/artifactId version0.3.1/version /dependency配置文件我更喜欢用YAML格式放在application.yml里aliyun: sms: access-key-id: your_access_key access-key-secret: your_secret endpoint: dysmsapi.aliyuncs.com sign-name: 您的短信签名 template-codes: order-create: SMS_123456 order-update: SMS_234567这里有个实用技巧把各种模板编号集中管理避免硬编码。我见过有团队把模板编号写在业务代码里后期更换模板时差点崩溃。3. 短信工具类封装实战直接使用原生SDK发送短信就像用铁锤敲鸡蛋 - 能用但不好用。我封装了一个带重试机制的SmsHelper类核心代码如下public class SmsSender { private static final Logger logger LoggerFactory.getLogger(SmsSender.class); Value(${aliyun.sms.access-key-id}) private String accessKeyId; Value(${aliyun.sms.access-key-secret}) private String accessKeySecret; public boolean sendWithRetry(String phone, String templateCode, MapString, String params, int maxRetry) { for (int i 0; i maxRetry; i) { try { SendSmsResponse response send(phone, templateCode, params); if (OK.equals(response.getBody().getCode())) { return true; } logger.warn(短信发送失败准备重试...); } catch (Exception e) { logger.error(短信发送异常, e); } } return false; } private SendSmsResponse send(String phone, String templateCode, MapString, String params) throws Exception { Config config new Config() .setAccessKeyId(accessKeyId) .setAccessKeySecret(accessKeySecret); Client client new Client(config); SendSmsRequest request new SendSmsRequest() .setPhoneNumbers(phone) .setSignName(signName) .setTemplateCode(templateCode) .setTemplateParam(JSON.toJSONString(params)); return client.sendSmsWithOptions(request, new RuntimeOptions()); } }这个封装解决了三个痛点一是自动JSON序列化模板参数二是内置了指数退避重试机制三是统一异常处理。在日均发送量2万的生产环境中这种设计将失败率控制在了0.1%以下。4. 业务集成最佳实践在工单系统中我们采用事件驱动的方式触发短信通知。当工单状态变更时系统发布领域事件由专门的短信处理器消费EventListener public void handleOrderEvent(OrderStatusChangedEvent event) { String templateCode templateCodes.get(event.getEventType()); if (StringUtils.isEmpty(templateCode)) { return; } MapString, String params new HashMap(); params.put(orderId, event.getOrderId()); params.put(status, event.getNewStatus()); smsSender.sendWithRetry( event.getUserPhone(), templateCode, params, 3 ); }这种设计有三大优势一是业务代码与短信发送解耦二是支持动态模板匹配三是易于扩展新的通知场景。我们在用户注册、密码重置、支付提醒等场景都复用这套机制。对于批量发送场景我们实现了异步批处理Async public void batchSend(ListNotificationTask tasks) { tasks.forEach(task - { boolean success smsSender.sendWithRetry( task.getPhone(), task.getTemplateCode(), task.getParams(), 2 ); if (!success) { notificationLogService.logFailure(task); } }); }配合线程池配置这套方案在双十一期间成功处理了单日50万的促销通知短信平均耗时控制在300ms以内。5. 监控与异常处理短信服务最怕的就是发了但用户没收到或者重复发送。我们建立了三级监控体系日志监控所有发送记录落库包含请求参数、返回结果和时间戳状态回调配置阿里云的消息回执推送更新发送状态对账机制每天比对阿里云控制台的发送记录和系统日志异常处理方面我们定义了专门的错误码体系public enum SmsError { TEMPLATE_NOT_FOUND(1001, 短信模板未配置), PARAM_ILLEGAL(1002, 模板参数不合法), SEND_FAILURE(1003, 短信发送失败), RATE_LIMITED(1004, 触发频控限制); private final int code; private final String message; // 构造方法等... }对于频控问题我们的解决方案是引入本地缓存记录发送频率public boolean checkRateLimit(String phone) { String key sms:limit: phone; Long count redisTemplate.opsForValue().increment(key); if (count 1) { redisTemplate.expire(key, 1, TimeUnit.MINUTES); } return count 5; }这套机制有效防止了恶意刷短信的情况同时避免了触发阿里云的风控限制。6. 性能优化技巧在高并发场景下短信发送可能成为系统瓶颈。我们通过几个优化手段将吞吐量提升了10倍连接池优化复用HTTP客户端连接Bean public Client smsClient() throws Exception { Config config new Config() .setAccessKeyId(accessKeyId) .setAccessKeySecret(accessKeySecret) .setMaxIdleConns(50) .setReadTimeout(5000); return new Client(config); }异步化改造使用CompletableFuture并行发送ListCompletableFutureBoolean futures phones.stream() .map(phone - CompletableFuture.supplyAsync( () - smsSender.send(phone, template, params), smsExecutor )) .collect(Collectors.toList()); CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();本地队列缓冲突发流量时先入队再异步处理Bean public Queue smsQueue() { return new LinkedBlockingQueue(10000); } Scheduled(fixedRate 1000) public void processQueue() { ListSmsTask batch new ArrayList(100); smsQueue.drainTo(batch, 100); if (!batch.isEmpty()) { batchSend(batch); } }这些优化使得系统在百万级流量下依然保持稳定P99响应时间控制在800ms以内。7. 测试方案设计短信功能的测试需要特别关注我总结了一套四层测试体系单元测试验证工具类逻辑Test public void testSendSms() { Mockito.when(client.sendSmsWithOptions(any(), any())) .thenReturn(new SendSmsResponse()); boolean result smsSender.send(13800138000, SMS_123, null); assertTrue(result); }集成测试验证配置是否正确SpringBootTest public class SmsIntegrationTest { Autowired private SmsSender smsSender; Test public void testRealSend() { boolean sent smsSender.send( 测试手机号, SMS_测试模板, Collections.singletonMap(code, 1234) ); assertTrue(sent); } }契约测试验证模板变量匹配Test public void testTemplateVariables() { String template 您的验证码是${code}5分钟内有效; MapString, String params new HashMap(); params.put(code, 1234); String content TemplateRenderer.render(template, params); assertFalse(content.contains(${)); }压测验证并发性能LoadTest(threads 100, duration 60) public void stressTest() { smsSender.send(13800138000, SMS_123, null); }这套测试方案帮助我们发现了多个潜在问题包括变量渲染异常、并发条件下消息丢失等。