短信平台的核心逻辑

需求场景

公司项目中需要发送短信的场景包括：

• 用户忘记密码，通过短信找回密码。
• 向项目联系人、项目负责人或专家发送短信通知。

场景二的逻辑

在场景二中，用户需要输入短信内容和手机号码，然后点击“发送”。如果验证通过，会跳转到短信发送成功的提示页面；如果验证失败，会显示错误信息，方便用户进行修改。

实施方式

原始方案是直接在项目中配置短信服务商提供的账号、密码和接口，并调用发送短信的界面。根据返回值判断是否成功提交给短信服务商。

为了提高稳定性，可以采用多服务冗余调度的方式，当一个服务提供商发送失败时，切换到下一个服务提供商，直到发送成功或所有服务提供商都发送失败。

为了避免重复工作和沟通成本过高，可以将发送短信的代码标准化成工具类，并打造新的短信平台，为不同项目提供统一服务。

为了提高短信发送的高可用性，可以将短信发送异步化，将发送请求持久化到数据库中，然后通过调度算法尽可能多地发送短信。如果发送失败，会进行重试。

为了解决网络错误和短信平台服务停机的问题，可以进行持久化改造和集群化部署，提高短信发送的可用性和服务能力。

为了向外界提供服务，可以增加绑定用户和IP的功能，为每个系统或组织分配唯一的账号和密码，并让客户自行下载对比短信账单。

为了优化短信发送，可以引入调度程序，先发送一条确认是否发送成功的短信，然后再分批发送剩余的短信。同时，可以引入优先级的概念，对短信发送界面进行改革。

后续工作

未来的优化方向可以考虑引入消息队列来解决短信发送的生产者和消费者问题。

在安全性、高性能和高可用性方面还有很多工作要做，随着业务范围的扩大，需要解决原有功能和设计方案的问题。

阶段总结

在项目初期，主要满足业务的基本需求，以灵活性为原则。

随着业务的发展，需要逐步解决可用性、可修改性、安全性、可测试性和易用性等质量属性。

在业务开发中，每个功能和模块都可以作为独立的服务向内部和外部提供服务。

随着对业务领域的深入了解，业务趋于稳定，系统的重组成为必要的工作。