回顾联通短信SGIP网关平台设计

回顾联通短信SGIP网关平台设计

    沉疴一年，病情有所好转。应公司要求闲暇时刻维护一下公司的短信平台。那是几年前的作品了，重拾旧作，顺便做一总结。
    SP端的联通短信网关其实说白了就是一个简单的SGIP协议接口，不过SP公司需要在实现接口的基础上做一些业务方面的考量和实现。为此整个系统的结构设计仍然需要认真设计，便于扩展。
    整个系统基本上两大模块：就是协议转换模块和业务产品模块。
    协议转换模块的基本功能：
    1，各种协议包的接收、识别和响应，这是最基本的功能啦，没有这样的功能，谈不上是一个网关。
    2，各类信息的迅速转发。这是对一个接口功能上的考虑。如果一个协议接口不能迅速处理大量的协议包，会造成接口的堵塞。只要编程正确，Java1.5提供的API完全能够胜任SP目前的大业务量，即时是堵塞式API也能胜任有余，当然concurrent包是应该采用的。

    产品模块相当来说非常简单啦，当然必须是线程为基础。线程的run（）方法本身完全就可以作为产品类的一个独立的唯一接口。

    既然有了这两个模块，其间的通讯当然也是非常重要的，很容易成为整个系统的瓶颈，毕竟短信MT大都来自的产品模块。推荐采用并发长连接实现。

    在整个平台的结构设计中，因为有很多业务方面的需要，譬如业务合作（每个合作方的接口不一定一致），统计（不同来源的统计，各种这样的功能统计）等各方面的需求，往往在各模块的接口设计上加入各种字段，甚至要求向协议转换模块传入业务模块的一些信息，往往看上去方便了一些功能的实现，譬如是统计，但是却破坏了模块概念上的纯洁性，而且不便于后期的维护，所以，最终还是放弃了一个将合作方信息字段加入到协议转换模块的想法。

    性能、数据完整性方面的考虑：
    1，及时入库还是日志入库，看需要。如果网关信息库是独立的，可以考虑及时入库，只是要保证信息的完整性，入库异常的要保存日志。
    2，各个模块接口前加入前端缓存，建议采用concurrent包。大量数据应该存储转发，尤其是类似下发话单这样的场合。
    3，产品模块因为要保证业务信息的及时和准确，所以在实现上必须使用缓存。大量的用户业务数据信息缓存处理和数据库存储是实际应用中必须衡量使用。

    整个结构设计清楚了，实现应该没有太大的问题。目前这个应用平台已经运行了两年，中间也经受了业务推广鼎盛时期的考验，及其稳定，尚算满意。打个及格分，呵呵。做一总结在此，希望能给新手一个设计上的借鉴。

    写的词不达意。望谅解。