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

这个东西瞅着好眼熟

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

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


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


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

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

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

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

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

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

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

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

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

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

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