|
精华帖 (1) :: 良好帖 (5) :: 新手帖 (11) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-31
apache的测试。。。。
天啊。。。怎么都以为是我自己写的测试工具啊。。。。。。哭了。。。 |
| 返回顶楼 | |
|
发表时间：2009-05-31
最后修改：2009-05-31
我猜 你 是 我兄弟！
|
| 返回顶楼 | |
|
发表时间：2009-05-31
最后修改：2009-05-31
fireflyc 写道 apache的测试。。。。
天啊。。。怎么都以为是我自己写的测试工具啊。。。。。。哭了。。。 充分说明偶很孤陋寡闻！ nishifei 写道 我猜 你 是 我兄弟
人渣，现在一搞连人肉都不需要了！ 
|
| 返回顶楼 | |
|
发表时间：2009-05-31
最后修改：2009-05-31
我这个菜菜觉得优化的地方还有很多,
1.如果采用HTTP协议POST XML请求固然能规避你对多线程了解的缺乏，但是最好你的HTTP是长连接，否则你会发现挺多消耗都在TCP握手、WEB服务器响应HTTP请求上。 2.海量的日志，最好还是记录到数据库里，按日期或者月份建表，不建索引。为什么呢？很明显，以后你查日志的时候，不会乐意到处去grep的，我就曾经遇到过接口挂了，对方说是我们某个时间段请求的请求太多导致的，我们没有数据库日志，都是我按时间段grep出来后wc -l才解决纠纷，如果再麻烦点我就顶不住了。 3.接口安全问题，可以考虑用加密BODY的内容来实现啊，关键的HEAD部分包含有商家ID，可以根据这个商家ID去缓存或者数据库里面找到对应的密钥进行解密。如果真的要做到限制IP地址的话，最好不要依赖服务器，这点楼上众多大侠都已经说清楚了，我有收益匪浅。同样可以根据商家ID去查对应的IP段。 4.异常返回代码。个人建议最好是用NUMBER，因为可以swtich(){case}呵呵，编码简单，而且效率比字符串要高。异常返回代码尽可能丰富、细致，最好有规律，比如说网络原因的以2开头等等，这样以后在统计的时候会帮助你节省不少时间。 5.协议内容可以改进。如果说是一条群发的短信下发给客户－－比如说手机报，这些内容都是一样的，区别在于发送的目标手机号码，那么我们没有必要发100W次内容，你说是吧。 6.如果担心一台WEB服务器压力顶不住，可以考虑用一台apache来做负载均衡，这样横向添加WEB服务器就可以解决压力问题。 以上是我这个小菜菜提出的观点...不知道是否正确 |
| 返回顶楼 | |
|
发表时间：2009-05-31
２、万一要是人家利用了别人的通道如何？Url发错了，编号通过了。或者更极端点。这安全级别不够。于是想到一个办法，在服务器Apache上做了手脚：验证IP（非合作商无法进入）。同时共用一个Url，会将合作商编号与产品编号一起生成一个md5号，通过后去验证一下md5就行了。虽然不是在最大程序上做到安全，不过我们都建立在友好合作的前提下的，没必要那么干，冒充别人的发。而且md5值你也无法知道。
|
| 返回顶楼 | |
|
发表时间：2009-05-31
２、万一要是人家利用了别人的通道如何？Url发错了，编号通过了。或者更极端点。这安全级别不够。于是想到一个办法，在服务器Apache上做了手脚：验证IP（非合作商无法进入）。同时共用一个Url，会将合作商编号与产品编号一起生成一个md5号，通过后去验证一下md5就行了。虽然不是在最大程序上做到安全，不过我们都建立在友好合作的前提下的，没必要那么干，冒充别人的发。而且md5值你也无法知道。
安全这块你可以先用IP验证,每个合作商分配一个企业ID,产口ID,密码,另外加一个时间戳,由企业ID+密码+时间戳生成MD5. 这样每次的MD5值都不会一样,防止网络上的嗅探器. |
| 返回顶楼 | |
|
发表时间：2009-05-31
fjlyxx 写道 天机老人 写道 fjlyxx 写道 总感觉你这个东西做的 网关不像网关,接口不像接口. 有点粗糙的感觉.
1,根据你业务我任务可以定位成一个短信网关. 2,前端请求应该是一个短连接请求,只是负责发送指令,企业发送完指令后服务的应该给它一个服务令牌标识(标识这次任务的) 这样交互就完成了. 3,服务的(短信网关)在收到指令后应该是进行静默处理的.日志应该批量写(10000条写一次或者10分钟写一次), 线程也许可以帮你解决一些问题 但是要考虑线程的模型,这种我推荐用LF线程模型. 4,服务的应该有一个完整的任务处理机制,提供包括重试,任务状态定位,任务日志记载,容错处理等功能 比如某些任务可以进行重试的,某些任务不能重试直接到失败状态的等等 5,对于楼上agapple的建议,楼主可以考虑在设计模式上进行解决.应用链模式(可以包括校验链,任务链等等).服务的的框架应该是基于会话的,一个客户请求是一个会话,这个会话包括的流程可以有 合法性校验链(IP,用户,时间,业务ID等等), 前期处理逻辑链条(解压,加密,编码转换等等),业务处理链.这些JAVA的接口可以帮你的忙.这样做基于两个地方考虑 第一.你的领域是一个会话,领域模型很固定 第二,方便扩展,可以实现热插拔功能.代码也容易维护 6,客户端要跟踪这个任务的情况,可以根据2的任务标识进行跟踪.所以你的服务的应该有几个子处理逻辑 最少要包括 登入,提交,跟踪,退出. 个人意见仅供参考! 恩楼上两位的发言都非常中肯，都是金砖。 楼上说的第二点我们确实是做了，每次请求结束，我们也会返一个信息给合作商。同时对于各种错误我们也约定好一些错误码：比如返回０１００就是成功，０２００ip验证无效等！ 非常感谢大家提的一些好建议！ 楼主,可能你有点误解我的意思了.我说的第二点 并不是指错误代码.和你举个例,比如你去银行取钱,你要先拿个流水号吧.我说的返回信息其实是指这个流水号,这个流水号是让企业用户能够查看这次任务的执行情况的.因为你上线程队列后其实用户是不知道执行情况如何的,你也不可能让用户一直保持连接 然后告诉他执行结果 fjlyxx兄应该是做电信级的网关通讯的吧! |
| 返回顶楼 | |
|
发表时间：2009-05-31
liujunsong 写道 这东西应该没有那么复杂吧?
其实说来说去,最需要的就是定义一个调用者和服务者之间的数据交换协议. 调用者把要调用的请求按照这个数据交换协议发过来,这边服务者收到一个数据包,然后拆包分析,将结果按照约定的数据交换格式发回去. 这样整个过程就解决了. 至于服务方具体如何存储信息,如何处理信息,这是服务方要解决的问题,和调用者无关. 应该属于两个问题分别进行讨论研究才对. 这个要看需求,如果一秒只有一个并发,这个东西就好做,如果每秒要成百上千个并发,需要注意的地方就多了. |
| 返回顶楼 | |
|
发表时间：2009-05-31
北京移动 短信网关，有 长短信 群发丢失现象。
建议使用生产消费模型，控制向网关发送短信的速度。 |
| 返回顶楼 | |
|
发表时间：2009-05-31
wzpwork 写道 ２、万一要是人家利用了别人的通道如何？Url发错了，编号通过了。或者更极端点。这安全级别不够。于是想到一个办法，在服务器Apache上做了手脚：验证IP（非合作商无法进入）。同时共用一个Url，会将合作商编号与产品编号一起生成一个md5号，通过后去验证一下md5就行了。虽然不是在最大程序上做到安全，不过我们都建立在友好合作的前提下的，没必要那么干，冒充别人的发。而且md5值你也无法知道。
安全这块你可以先用IP验证,每个合作商分配一个企业ID,产口ID,密码,另外加一个时间戳,由企业ID+密码+时间戳生成MD5. 这样每次的MD5值都不会一样,防止网络上的嗅探器. 你这个加密建议不错！嘿嘿！太谢谢了，而且实现起来也容易！ |
| 返回顶楼 | |
