记忆深刻的高考查询业务后,工作重心来到了电信级业务“短信营业厅”,这个项目是07年启动的,项目的核心是短信和BOSS接口,电信级业务是7X24小时工作,业务必须保证高可用,下面就分享一下,短信营业厅的异步框架。
07年还没有像redis,kafka这样的应用,所以初期设计时,我们还是采用了数据库来存储用户上行信息,用一个中间程序读取用户上行,这个中间程序还要负责均衡的将信息发布给网络上处理业务的服务器上,这就是我们当时的高可用方案,如图:
业务服务器可以横向扩展,上线时需要向分发服务器注册,与分发服务器通过tcp进行通信,分发服务器也是有多台的,之间通过tcp进行通信,保证同一时间只有一台读取oracle数据(后来感觉性能不好,采用了选举制,也就是一台坏了,另几台在选举出一个服务,和现在的zookeeper蛮像的),这个服务架构,除了oracle这个当时的单点之外,还是不错的,但是Boss接口的能力不行,导致业务服务器有业务积压,所以进行了下面的改造。
业务服务器和分发服务器之间采用,业务器服务拉取的机制,也就是谁有能力谁拉取(和现在的redis队列,kafka队列是不是很像)。
oracle后期又进行了RAC改造,高可用!
至今的遗憾是业务一直没有在改造升级过,一是因为短信应用用户量下降,二是移动更加信认Oracle,而不是redis与kafka。