扫一扫添加我为好友
扫一扫添加我为好友
扫一扫添加我为好友
扫一扫添加我为好友
发布时间:2021-04-15来源:九天企信王作者:闻人易文
公司做的项目中有以下场景需要发送短信:
当用户忘记密码时,可以通过短信找回密码;
需要向项目联系人、项目负责人或专家发送短信通知。
场景1的逻辑太简单,不变,跳过吧。
场景二的逻辑是用户输入短信内容和手机号码,然后点击“发送”。如果验证通过,跳转到短信发送成功的提示页面;如果验证失败,会出现错误信息,方便用户根据错误信息进行修改。
原始方案:
短信服务商提供的账号、密码、接口都是在项目中直接配置的。如果需要发送短信,可以直接调用发送短信的界面。根据返回值可以判断是否成功提交给短信服务商。
该方案在项目初期采用,简单高效,快速实现业务需求。
问题1:服务提供商不稳定
使用一段时间后,项目组发现短信服务商提供的服务不够稳定,于是换了新的服务商,但实际上不同的短信服务商不够稳定。
解决方案:多服务冗余调度
为了保证稳定性,自然会想到,如果服务提供商A发送失败,就会由服务提供商B发送,然后依次切换,直到发送成功或者所有服务提供商发送失败。
问题2:代码复制还是独立服务
新项目也需要发短信,业务场景类似。因为是不同的项目组,所以在初期是独立实现的。在做内部沟通的时候,我们发现大家都在做重复的工作,于是项目组合作把代码标准化成工具类。但是每次修改都需要项目组之间的配合,沟通成本太高,没有相应的协议和流程,导致混乱。
考虑到后续的优化和变更,项目组自主协商打造新的短信平台,为不同项目提供统一服务。到目前为止,服务商的调度优化与具体项目无关,项目中的短信发送代码变得非常简单。
问题3:网络错误如何保证短信发送的高可用性
短信发送一般属于非核心业务范畴。为了提高性能,项目团队将异步转换通知短消息的发送。是一种转换,其实就是把同步短信发送变成异步。改造完成后,项目的性能确实有所提高。但是由于公司网络的原因,短信平台和短信服务商的网络之间出现了很多问题,导致一些重要的短信没有发送成功,也没有相关的发送记录。
项目团队正在为业务变革而努力。当网络不稳定或者服务商出现问题时,如何尽最大努力保证短信发送成功的问题就留给短信平台组了。经过多次讨论,决定将短信发送分为两步:第一步,接收主叫方的发送请求,将其持久化到数据库中,等待发送;然后从数据库中读取要发送的记录,然后通过调度算法尽可能多地发送短信。如果由于异常原因(如网络中断或服务提供商不稳定等)导致发送失败。),相应标记,一段时间后再试,达到最大重试次数后失败再标记。该方案使发送请求持久化,使短信平台尽最大努力保证发送成功,重试的设置也提高了短信发送成功的概率。
问题4:服务呼叫者与短信平台之间的网络错误以及短信平台服务的停机时间
上述在短信平台持久化短信发送记录的方式,解决了短信平台和短信服务商之间的问题,但是服务主叫和短信平台之间的网络错误以及短信平台宕机的错误是无法避免的。参照上述方案,服务调用方也进行了持久化改造,短信平台集群化。
持久化转换和之前一样,这里就不描述了。由于无状态服务,短信平台的集群转换变得更加容易。部署方案调整后,集群改造基本完成。聚类的转换在一定程度上提高了短信发送的可用性和服务能力,但负载均衡仍然存在单点故障,只能后期优化。
问题5:短信平台对外提供服务
一些小系统或合作客户的系统也有发送短信的需求,但不愿意单独与短信服务商打交道。所以,了解了我们的短信平台之后,一定会用到的。然而,要向外界提供服务,就必须考虑安全和收费的问题。
经过小组讨论,形成以下方案:
参考各大短信服务商的做法,增加了绑定用户和IP的功能,即给每个系统或组织分配一个唯一的账号和密码。同时为了避免密码泄露等异常纠纷,对用户和系统的外部IP进行绑定,基本满足安全要求。
充电的问题比较简单。由于短信平台本身坚持发送请求,所以参考支付系统的“对账”概念,按照与客户约定的频率,在指定路径生成短信账单,让客户自行下载对比。
问题6:短信发送优化
持久化转换后,短信通过线程池发送,发送时每个线程都是独立的。这种方法简单,易于理解和实现,因为每个线程都是相互独立的,没有考虑并发和锁定。
我们知道,向服务提供商发送短信时需要匹配模板。如果每批发送的短消息中有一条因内容与模板不匹配而被拒绝,则默认情况下,该批中的其他短消息发送请求应标记为待处理。
但是短信发送的线程是相互独立的,在出现异常发送时,无法及时通知对方,会耗费大量资源做无用的工作。为了解决上述问题,引入了调度程序。对于一批短信,先发一条确认是否发送成功,如果发送成功,则分批发送同一批剩余短信。
同时,调度程序还根据每次短信发送记录服务提供商的服务状态,用于发送调度。
在上述场景中,发送的通知短信数量将明显高于登录、注册和密码检索即时消息。但是从业务角度来说,即时消息是不可能等着顶部通知短信发送的。因此,在短信发送的优化中,引入了优先级的概念,并对短信发送的界面进行了改革。
随着对短信发送业务的逐渐深入了解,我们可以发现短信发送其实是一个典型的生产者和消费者问题,项目组解决的很多问题可以直接引入消息队列一次性解决,这也是未来的优化方向。
当然,在安全性、高性能和高可用性方面还有很长的路要走。随着业务范围的逐步扩大,原有的功能和设计方案亟待解决。
因为业务优先的原则,一开始主要满足业务的基本需求,技术上以灵活性为基本原则。
随着业务的发展,设计要逐步解决,可用性、可修改性、安全性、可测试性、易用性等质量属性要逐步优化。
在业务开发中,每个功能和模块都可能与当前的项目分离,作为独立的服务向内部和外部提供服务是一种趋势。
随着对业务领域的深入了解,业务趋于稳定,系统的重组应该提上日程。每次改制都要考虑“投入产出比”。不然怎么说服领导支持改制工作?