电信行业Http接口(通道)设计思路与实现过程

　　最近接口做了好长时间了，觉的有必要记录点什么下来！（虽然最近这一块不是我负责了有别的事要忙去，但是我还是经常会去看看项目开发情况。）

　　

　　项目主要是一个Http接口的开发，利于与其它公司合作在信息交互！因为我们这个是电信行业的项目，所以呢，在与合作商合作的时候会下发大量的短信，走数据库这有点太不专业了！用Ejb？这有点太过份了，而且很多公司赚钱是赚了不少钱，但技术实力不行。别的不说，就Http接口合作的好几家公司还真不会。 

　　先说一下这个接口设计的一些重点：

　　１、安全：这是肯定的，不能随便一个家伙跑过来就要用我们的接口发短信啊。

　　２、效率：一家合作商用户订阅量在100多万，一天十几家下去，你的接口的扛的住啊。

　　３、备份：这合作商发的信息你得有详细log啊，要是出了问题，这能找责任人啊。

 

　　出于以上三点要抓信核心要点：

　　１、加入安全验证机制

　　２、减少数据库访问量，重构代码注重条理减少没效率的代码。采用Http能还有个好处就是规避了多线程的问题。

　　３、采用log4j把详细的下发日志记录到log上，每个log的大小限制在１M.

 

 

      一、安全

　　在安全方面最先考虑的是一个合作商就给他一个http链接,同时定义一个合作商编号，这样就可能起到隔离，起码你不是我和合作商你不知道发哪个Url，更别说编号了.

　　但往深层想想这也不妥当：

　　１、每加个合作商你得再搞个Url链接吧，这你多少还得重写点代码吧。不利于扩展。

　　２、万一要是人家利用了别人的通道如何？Url发错了，编号通过了。或者更极端点。这安全级别不够。于是想到一个办法，在服务器Apache上做了手脚：验证IP（非合作商无法进入）。同时共用一个Url，会将合作商编号与产品编号一起生成一个md5号，通过后去验证一下md5就行了。虽然不是在最大程序上做到安全，不过我们都建立在友好合作的前提下的，没必要那么干，冒充别人的发。而且md5值你也无法知道。

　　３、在实体类中加入：周未是否充下发（本来还想搞节假日，这太不靠谱了除非专门找人维护这个去，一年一个变。）、开启状态（关闭，暂停，运行）。从而决定这一堆信息能否下发。

　　

　　二、性能

　　说实话安全这块做到这基本上就算成了。但还并不是很完美，但是有时候在性能上考虑，还真不能再加太多东西了，一天量一大必然影响性能。

　　１、为了能够更好的实现性能上的最优，大家都知道减少数据库访问次数，这是最先考虑的，因为代码的速度运行远远高于数据库啊。所以呢我们的数据库就采用了一张大表设计（把合作商id，名称，产品，发送所有方式，发送方向，合作商md5编号等）。有些东西并不怎么符合范式，但是为了效率吗，这种东西多一张表，他就会多更多的复杂度。性能上会有更多的损耗。基本上每一个产品发送取一次数据库就行了。（一个产品上百万手机号+信息内容）

　　２、其次就是代码了，数据库已经不是瓶颈了，基本上用户从进为就已经通过Ip验证了，也就是有钥匙了，而且去数据库取的东西无非就是“指纹验证”，并且预读入一些用户信息。数据库就算是一个钟头下发两三百个产品也不是问题。

      ３、 所以现在的优化方向是代码：做的第一件事就是重构。大家也注意到了其实有多个下发方式，选择的下发方式不同那么实现代码也不同。原来写的代码if else过多，基本上代码没有可阅读性。于是采用策略模式重构了一下，把相同的代码抽出来，这样代码条理就清晰了。在策略模式上我们没有选择反射，更没有选择数据库，因为怕效率上跟不上，为了效率我们有context里写了个静态map用于存储各种实现方法。因为我们的下发方式非常固定，基本上大半年也改不了一两次，所以写到代码上比较合适。

　　４、第四点从一定程度上还是讲的第一点，但是我还是有必要提一下。就是尽量把通用性的属性用静态方法写到代码里，这样会好很多。（虽然在数据库上数据是一口气全拿上来的，但是感觉这样会好点。至少便于阅读）

　　　

　　三、日志

　　这一点非常重要，说难听的，以后出了问题打官司还得用他呢（至于能不能作为呈堂证供就是我们要过分研究的东西了。）。但我们的记录的详细，啥时间，啥内容，发向啥手机，发送状态等。这里主要就使用log4j.

      这个现在实现有点凌乱（到处乱加log），但是吧。主要是原来那个程序，一起还没按我写好的代码把东西重构好，不然这log得在一个统计的地方调用他。

 

　　

      这个接口的设计吧我就写这么多，但是，总感觉不是很全面，也希望听听大家的想法。有什么砖可以拍。不过目前我们还没用上好的http接口的框架啊啥的。大家也可以推荐一下！

　　

     

评论

54 楼 mx122723 2009-06-04  

是做SP的吗？ 感觉您这对电信的网关，还不是很了解啊

53 楼 kunee 2009-06-02  

参考facebook，肯定够用了

52 楼 netstorm 2009-06-02  

我这边也做过类似的移动接口，大致是这样的

1. 颁发数字证书给合作商(山塞版)
2.合作商先进行登录认证
ip认证，平台号认证，数字签名认证
3. 登录成功后，服务端分配一个session 给合作商
4. 合作商用这个session做业务认证
5. 设置闲时机制，超过n分钟没有交易的，自动把合作商session删除
6. 设置同异步开关，业务量大时也切换到异步模式
7. 后台数据库会记录每笔交易日志

51 楼 天机老人 2009-06-02  

josen 写道

如果没有猜错，分众无线的...

很高兴告诉你，猜错了！

50 楼 josen 2009-06-01  

如果没有猜错，分众无线的...

49 楼 xiuxiuxiu 2009-06-01  

关于接口可以参考facebook.com或者51.com的实现吧.通过public key和private key来实现安全认证.性能和可靠性大家都看得到.

48 楼 chen4059 2009-06-01  

几个运营商的sp平台都支持地址群发。1l的是不是做sp代理的？
小的sp不能直连运营商，听说注册资金过千万的才能连。。。。

47 楼 lottons 2009-06-01  

wzpwork 写道

lottons 写道

wzpwork 写道

lottons 写道

前面好像有人回复了这个问题了：
1.如果采用HTTP协议POST XML请求固然能规避你对多线程了解的缺乏，但是最好你的HTTP是长连接，否则你会发现挺多消耗都在TCP握手、WEB服务器响应HTTP请求上。

其实大家最担心的就是HTTP的响应问题，目前就我了解电信有的项目使用的是webservice，其实应该说性能还好（我之前做过中国电信的一个项目，使用的就是webservice）。至于安全性，我个人认为采用验证IP应该就可以了，没有必要搞得太复杂，一般来说能连到电信网络的系统不是一般系统做得到的。

这个网关其实可以参考一下MM7 API,发送跟接收在里面都有实现,只要再稍稍改造下即可.

何必这么复杂参考MM7呢，其实很简单，用xml消息，按照一定的格式整合消息在服务端解析就可以了。而且还方便以后的扩展，解析消息的类是可以扩展的。且，即使以后不使用HTTP而改用MQ的方式（电信行业系统大多数都会使用MQ）因为性能和系统压力的需要。
网关其实也需要分层的，安全性我觉得还是直接有专业的安全网关来作吧，要接入到电信系统第一步要做的就是先通过验证，这个应用网关采用客户端地址校验足够了。

在这个API中多线程,长短连接,还有安全验证都有很好的实现.这个API是中兴给移动写的,它的并发我测试过,可以达到每秒100以上.

移动的网络和系统建设我不是很清楚，中国电信我倒是比较了解。但是就我个人了解到的情况是其实移动的系统建设的不如电信，移动靠的是什么我觉得就是垄断（无线的发展，因为移动在初期垄断了无线）。
现在移动也慢慢在像电信的系统学习，开始构造CRM这些东西了。（都是题外话了）

其实我的最主要目的就是怕过渡的设计，适合的就是最好的。

46 楼 wzpwork 2009-06-01  

lottons 写道

wzpwork 写道

lottons 写道

前面好像有人回复了这个问题了：
1.如果采用HTTP协议POST XML请求固然能规避你对多线程了解的缺乏，但是最好你的HTTP是长连接，否则你会发现挺多消耗都在TCP握手、WEB服务器响应HTTP请求上。

其实大家最担心的就是HTTP的响应问题，目前就我了解电信有的项目使用的是webservice，其实应该说性能还好（我之前做过中国电信的一个项目，使用的就是webservice）。至于安全性，我个人认为采用验证IP应该就可以了，没有必要搞得太复杂，一般来说能连到电信网络的系统不是一般系统做得到的。

这个网关其实可以参考一下MM7 API,发送跟接收在里面都有实现,只要再稍稍改造下即可.

何必这么复杂参考MM7呢，其实很简单，用xml消息，按照一定的格式整合消息在服务端解析就可以了。而且还方便以后的扩展，解析消息的类是可以扩展的。且，即使以后不使用HTTP而改用MQ的方式（电信行业系统大多数都会使用MQ）因为性能和系统压力的需要。
网关其实也需要分层的，安全性我觉得还是直接有专业的安全网关来作吧，要接入到电信系统第一步要做的就是先通过验证，这个应用网关采用客户端地址校验足够了。

在这个API中多线程,长短连接,还有安全验证都有很好的实现.这个API是中兴给移动写的,它的并发我测试过,可以达到每秒100以上.

45 楼 lottons 2009-06-01  

whaosoft 写道

电信业的那数据库设计看的我脑袋那个疼啊 我在也不想碰了~

呵呵， 复杂也是因为业务上复杂造成的。其实现在软件系统最怕的就是过渡设计，这种情况在电信行业也比较突出。为了一个无足轻重或者是添花的小功能都会导致设计上的过渡和复杂，这就需要很好的谈判与周旋技巧了。

以后电信行业逐渐会做到融合（无论是电信网和互联网的融合，还是预付费与后付费的融合）。

44 楼 pipilu 2009-06-01  

怎么建立长连接？一个客户端一个长连接？客户端每次调用都使用已有的连接？没明白具体是咋回事。
另外，生命期要多长？

43 楼 lottons 2009-06-01  

wzpwork 写道

lottons 写道

前面好像有人回复了这个问题了：
1.如果采用HTTP协议POST XML请求固然能规避你对多线程了解的缺乏，但是最好你的HTTP是长连接，否则你会发现挺多消耗都在TCP握手、WEB服务器响应HTTP请求上。

其实大家最担心的就是HTTP的响应问题，目前就我了解电信有的项目使用的是webservice，其实应该说性能还好（我之前做过中国电信的一个项目，使用的就是webservice）。至于安全性，我个人认为采用验证IP应该就可以了，没有必要搞得太复杂，一般来说能连到电信网络的系统不是一般系统做得到的。

这个网关其实可以参考一下MM7 API,发送跟接收在里面都有实现,只要再稍稍改造下即可.

何必这么复杂参考MM7呢，其实很简单，用xml消息，按照一定的格式整合消息在服务端解析就可以了。而且还方便以后的扩展，解析消息的类是可以扩展的。且，即使以后不使用HTTP而改用MQ的方式（电信行业系统大多数都会使用MQ）因为性能和系统压力的需要。
网关其实也需要分层的，安全性我觉得还是直接有专业的安全网关来作吧，要接入到电信系统第一步要做的就是先通过验证，这个应用网关采用客户端地址校验足够了。

42 楼 whaosoft 2009-06-01  

电信业的那数据库设计看的我脑袋那个疼啊 我在也不想碰了~

41 楼 wzpwork 2009-06-01  

lottons 写道

前面好像有人回复了这个问题了：
1.如果采用HTTP协议POST XML请求固然能规避你对多线程了解的缺乏，但是最好你的HTTP是长连接，否则你会发现挺多消耗都在TCP握手、WEB服务器响应HTTP请求上。

其实大家最担心的就是HTTP的响应问题，目前就我了解电信有的项目使用的是webservice，其实应该说性能还好（我之前做过中国电信的一个项目，使用的就是webservice）。至于安全性，我个人认为采用验证IP应该就可以了，没有必要搞得太复杂，一般来说能连到电信网络的系统不是一般系统做得到的。

这个网关其实可以参考一下MM7 API,发送跟接收在里面都有实现,只要再稍稍改造下即可.

40 楼 lottons 2009-06-01  

前面好像有人回复了这个问题了：
1.如果采用HTTP协议POST XML请求固然能规避你对多线程了解的缺乏，但是最好你的HTTP是长连接，否则你会发现挺多消耗都在TCP握手、WEB服务器响应HTTP请求上。

其实大家最担心的就是HTTP的响应问题，目前就我了解电信有的项目使用的是webservice，其实应该说性能还好（我之前做过中国电信的一个项目，使用的就是webservice）。至于安全性，我个人认为采用验证IP应该就可以了，没有必要搞得太复杂，一般来说能连到电信网络的系统不是一般系统做得到的。

39 楼 天机老人 2009-06-01  

pypcjs 写道

安全性：
使用https
1、验证CA（机构证书）。
2、验证客户端证书。（这个证书有客户信息，由某机构授权的）
3、限制IP合法性。
4、拼url的时候，用md5算一下摘要防止修改。

并发性：
client -> httpd -> db_server -> db
这样设计可以扩充方便，而且易于做优化。

楼主参考一下在线支付公司的案例。

不过有些东西还真想问一下！
为什么大家都喜欢用长连接呢？在我看来一个Url把所有的信息传回就行了。处理完一个结果返回去不就好了吗！

38 楼 天机老人 2009-06-01  

vlinux 写道

呵～～pypcjs的安全性方法我的确忘记了https了，B4自己一下
对了，关于并发性的解释，我有点看不明白你的这个解决方案有什么特别的地方呢，感觉原来就这样设计的呀

恩,pypcjs这个还是比较专业的！

37 楼 vlinux 2009-06-01  

呵～～pypcjs的安全性方法我的确忘记了https了，B4自己一下
对了，关于并发性的解释，我有点看不明白你的这个解决方案有什么特别的地方呢，感觉原来就这样设计的呀

36 楼 pypcjs 2009-06-01  

安全性：
使用https
1、验证CA（机构证书）。
2、验证客户端证书。（这个证书有客户信息，由某机构授权的）
3、限制IP合法性。
4、拼url的时候，用md5算一下摘要防止修改。

并发性：
client -> httpd -> db_server -> db
这样设计可以扩充方便，而且易于做优化。

楼主参考一下在线支付公司的案例。

35 楼 天机老人 2009-05-31  

swen00 写道

vlinux 写道

我这个菜菜觉得优化的地方还有很多,

2.海量的日志，最好还是记录到数据库里，按日期或者月份建表，不建索引。为什么呢？很明显，以后你查日志的时候，不会乐意到处去grep的，我就曾经遇到过接口挂了，对方说是我们某个时间段请求的请求太多导致的，我们没有数据库日志，都是我按时间段grep出来后wc -l才解决纠纷，如果再麻烦点我就顶不住了。


4.异常返回代码。个人建议最好是用NUMBER，因为可以swtich(){case}呵呵，编码简单，而且效率比字符串要高。异常返回代码尽可能丰富、细致，最好有规律，比如说网络原因的以2开头等等，这样以后在统计的时候会帮助你节省不少时间。


以上是我这个小菜菜提出的观点...不知道是否正确

wzpwork 写道

２、万一要是人家利用了别人的通道如何？Url发错了，编号通过了。或者更极端点。这安全级别不够。于是想到一个办法，在服务器Apache上做了手脚：验证IP（非合作商无法进入）。同时共用一个Url，会将合作商编号与产品编号一起生成一个md5号，通过后去验证一下md5就行了。虽然不是在最大程序上做到安全，不过我们都建立在友好合作的前提下的，没必要那么干，冒充别人的发。而且md5值你也无法知道。

安全这块你可以先用IP验证,每个合作商分配一个企业ID,产口ID,密码,另外加一个时间戳,由企业ID+密码+时间戳生成MD5. 这样每次的MD5值都不会一样,防止网络上的嗅探器.

结合下以上几位提到的,我比较支持,也是目前采用的方法.

通信协议比较重要,LZ可以贴出来看看.

发送速率是否也要限制下,短信网关我这是1秒只能发3条,如果不限制,当大量请求过来,排队是否有性能问题?

如果发送失败,超时,是如何处理的?简单丢弃还是会记录到数据库中?

我这里是一秒400！