想做个 短信群发的平台，感兴趣的 可以一起讨论一下。大家互补。

Question

短信大家讨论

Answer 1

sp接口跟短信猫的应用概念完全不同。使用sp的接口，给每一个用户通常有几位“扩展码”。例如假设是3位，并且假设你们的单位分配的编号是345，那么假设你给 13810900778 发送5条信息，这个手机收到的发信端的服务可能就是（假设sp特服号是10088打头）10088345001、10088345002、10088345003、10088345004、10088345005，而不是10088345，更不是10088。这样，如果用户的这部手机随便挑出第4条短信回复了，那么sp接口收到的信息就知道是“13810900778手机给10088345004”回复的短信，它会先路由10088然后再路由给345（也就是你们）发来消息。这样，你们的系统要根据 10088345004 这个编号，找到当初发送这个信息时预先保存好的“处理其回复信息所用的程序”的记录，调用相应的处理程序来处理。这样，虽然你们这个公司只有3位扩展码可以用，那么你们可以给每一个目标手机发信息时都按照“流水号”的方式去使用这扩展码，例如发送4条消息：
    
    目标手机号     扩展号
  -----------   -----
   138....0778   001
   138....0778   002
   138....0778   003
   138....0779   001这样每一个目标手机上，在1000条短信范围内，是不会弄混淆的。1000条短信范围内，选择任何一条短信回复，你们的服务器系统都能准确地找到对应的处理程序。  而短信猫，是不可能为每一个发送手机号再追加扩展码的。结果你虽然给 13810900778 手机发送了5条信息，用户也确实挑选了第4条信息回复了，你们的系统根本不知道如何准确处理它，根本知道用户是选择了第4条信息回复的。这个区别，就能决定你的所谓“短信系统”根本就是不同档次的系统！

Answer 2

根本知道用户是选择了第4条信息回复的  -->   根本不知道用户是选择了第4条信息回复的当设计一个服务系统的比较高层的架构时，其实根本不必要出现什么“数据库”这个词儿。你把数据库的当作一个应用服务系统、完成什么业务操作，这本身就是那些做“小办公室里的OA”的习惯，而不是做SOA架构设计的习惯。数据库只是用来保存数据的，丢垃圾的，不是用来处理业务的。