|
精华帖 (1) :: 良好帖 (5) :: 新手帖 (11) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-31
这东西应该没有那么复杂吧?
其实说来说去,最需要的就是定义一个调用者和服务者之间的数据交换协议. 调用者把要调用的请求按照这个数据交换协议发过来,这边服务者收到一个数据包,然后拆包分析,将结果按照约定的数据交换格式发回去. 这样整个过程就解决了. 至于服务方具体如何存储信息,如何处理信息,这是服务方要解决的问题,和调用者无关. 应该属于两个问题分别进行讨论研究才对. |
| 返回顶楼 | |
|
发表时间：2009-05-31
fjlyxx 写道 天机老人 写道 fjlyxx 写道 总感觉你这个东西做的 网关不像网关,接口不像接口. 有点粗糙的感觉.
1,根据你业务我任务可以定位成一个短信网关. …… 恩楼上两位的发言都非常中肯，都是金砖。 …… quote] 楼主,可能你有点误解我的意思了.我说的第二点 并不是指错误代码.和你举个例,比如你去银行取钱,你要先拿个流水号吧.我说的返回信息其实是指这个流水号,这个流水号是让企业用户能够查看这次任务的执行情况的.因为你上线程队列后其实用户是不知道执行情况如何的,你也不可能让用户一直保持连接 然后告诉他执行结果 了解你的意思了，这有点像队列。 目前我们就有用户差不多有这种需求，他需要了解有哪些号码的内容没有发送成功。就是你说的这种实现方式，每次请求就给分返回一个流水号（像去银行先领一张排队号）。然后能根据流水号返回相应的执行情况。 不过我们这个体系目前还不是建的很完整，需要更健全一点。谢谢你的提醒，我们当时有点是被这个需求牵着走不得以做了这么一个功能。你这么一说我倒提醒我了，有必要把这个功能做的更健全一些，以应对合作商的需求！ 哥们 你们是不是返回一个叫messageid的东西啊？这个就是她说的流水号的东西，这个号码可以用来才客户发的信息，这个接口下发情况，网关下发情况，移动返回情况。。。晕 |
| 返回顶楼 | |
|
发表时间：2009-05-31
那是 移动的SP网关不是这么简单. 个人觉得移动的SP网关没有联通的做的好. 联通的技术确实不错 不过不知道为什么就是搞不过移动. 可能是销售,商务没有移动厉害. 技术评论本人不是联通的.
|
| 返回顶楼 | |
|
发表时间：2009-05-31
考虑到单条数据量不会很大，所以没有必要把通讯协议做成二进制的。所以我个人推荐已经非常普及的 xml-rpc。
然后是系统的瓶颈，总的来说瓶颈一分为二： 第一个就是数据库的瓶颈。这里都是插入数据的操作，所以效率上应该是不会有什么大的问题。 第二个系统能不能抗得住并发的压力，在并发很多的情况下响应时间和吞吐率是不是会直线下降。这可是HTTP接口。 然后还有安全的问题，基本上和楼主说的一样。当然还有另外的做法，比如新建用户的时候生成一对密钥，分配给客户端一个，服务器端自己保留一个。信息提交过来的时候都是经过客户端密钥加密的，只有服务器端密钥能够解密。这样很安全，可是效率上会有一些损伤。我觉得限制IP地址这个就足够了。 我们有一个类似的东西，下面是用jmeter的测试结果。 系统很简单，就是传递两个数字，做两个数的加法运算。此处单纯测试HTTP并发压力。 我的机器配置是 2G内存 1.73GHZ的CPU O(∩_∩)O~ 
请求数据
<?xml version="1.0"?>
<methodCall>
<methodName>com.join.rpc.server.test.Calculator.add</methodName>
<params>
<param>
<value><i4>200</i4></value>
</param>
<param>
<value><i4>200</i4></value>
</param>
</params>
</methodCall>
断言 200+200当然是400咯。O(∩_∩)O~ 
测试结果 
|
| 返回顶楼 | |
|
发表时间：2009-05-31
最后修改：2009-05-31
chenyongxin 写道 fjlyxx 写道 天机老人 写道 fjlyxx 写道 总感觉你这个东西做的 网关不像网关,接口不像接口. 有点粗糙的感觉.
1,根据你业务我任务可以定位成一个短信网关. 2,前端请求应该是一个短连接请求,只是负责发送指令,企业发送完指令后服务的应该给它一个服务令牌标识(标识这次任务的) 这样交互就完成了. 3,服务的(短信网关)在收到指令后应该是进行静默处理的.日志应该批量写(10000条写一次或者10分钟写一次), 线程也许可以帮你解决一些问题 但是要考虑线程的模型,这种我推荐用LF线程模型. 4,服务的应该有一个完整的任务处理机制,提供包括重试,任务状态定位,任务日志记载,容错处理等功能 比如某些任务可以进行重试的,某些任务不能重试直接到失败状态的等等 5,对于楼上agapple的建议,楼主可以考虑在设计模式上进行解决.应用链模式(可以包括校验链,任务链等等).服务的的框架应该是基于会话的,一个客户请求是一个会话,这个会话包括的流程可以有 合法性校验链(IP,用户,时间,业务ID等等), 前期处理逻辑链条(解压,加密,编码转换等等),业务处理链.这些JAVA的接口可以帮你的忙.这样做基于两个地方考虑 第一.你的领域是一个会话,领域模型很固定 第二,方便扩展,可以实现热插拔功能.代码也容易维护 6,客户端要跟踪这个任务的情况,可以根据2的任务标识进行跟踪.所以你的服务的应该有几个子处理逻辑 最少要包括 登入,提交,跟踪,退出. 个人意见仅供参考! 恩楼上两位的发言都非常中肯，都是金砖。 楼上说的第二点我们确实是做了，每次请求结束，我们也会返一个信息给合作商。同时对于各种错误我们也约定好一些错误码：比如返回０１００就是成功，０２００ip验证无效等！ 非常感谢大家提的一些好建议！ 楼主,可能你有点误解我的意思了.我说的第二点 并不是指错误代码.和你举个例,比如你去银行取钱,你要先拿个流水号吧.我说的返回信息其实是指这个流水号,这个流水号是让企业用户能够查看这次任务的执行情况的.因为你上线程队列后其实用户是不知道执行情况如何的,你也不可能让用户一直保持连接 然后告诉他执行结果 楼主是那公司的？你的设计怎么这么熟悉呢？ 不过要说一点哦，你这个接口只是一个接收数据的功能，正真和移动通信的功能不在这。。。呵呵 人肉公司就莫有意思了！ 只谈业务与技术，别的没必要！ 我们这个通道会经过这样一个步骤： １ 合作商发下信息经过我们的通道，将短信内容+Ｎ个手机号 ２ 重新组装成Ｎ（个短信内容+手机号）然后下发到网关 在与网关通信的时候，调用了公司已经做好的接口。（所以很大的压力在这里，但这一块对我们来说是透明的！） ３ 返回发送报告 |
| 返回顶楼 | |
|
发表时间：2009-05-31
fjlyxx 写道 那是 移动的SP网关不是这么简单. 个人觉得移动的SP网关没有联通的做的好. 联通的技术确实不错 不过不知道为什么就是搞不过移动. 可能是销售,商务没有移动厉害. 技术评论本人不是联通的.
与网关的接口有专门的底层人员开发，专职的。 我们负责把合作商的信息重新组装，通过网关下发，并返回发关情况！ |
| 返回顶楼 | |
|
发表时间：2009-05-31
楼上的 loadrunner 啊 还要自己开发压力测试工具啊.
|
| 返回顶楼 | |
|
发表时间：2009-05-31
fjlyxx 写道 那是 移动的SP网关不是这么简单. 个人觉得移动的SP网关没有联通的做的好. 联通的技术确实不错 不过不知道为什么就是搞不过移动. 可能是销售,商务没有移动厉害. 技术评论本人不是联通的.
不过我确实有几个朋友在联通开发，好像听说很累，全国各个点都是实地开发的！ |
| 返回顶楼 | |
|
发表时间：2009-05-31
jmeter
apache的。 |
| 返回顶楼 | |
|
发表时间：2009-05-31
最后修改：2009-05-31
fireflyc 写道 考虑到单条数据量不会很大，所以没有必要把通讯协议做成二进制的。所以我个人推荐已经非常普及的 xml-rpc。
然后是系统的瓶颈，总的来说瓶颈一分为二： 第一个就是数据库的瓶颈。这里都是插入数据的操作，所以效率上应该是不会有什么大的问题。 第二个系统能不能抗得住并发的压力，在并发很多的情况下响应时间和吞吐率是不是会直线下降。这可是HTTP接口。 然后还有安全的问题，基本上和楼主说的一样。当然还有另外的做法，比如新建用户的时候生成一对密钥，分配给客户端一个，服务器端自己保留一个。信息提交过来的时候都是经过客户端密钥加密的，只有服务器端密钥能够解密。这样很安全，可是效率上会有一些损伤。我觉得限制IP地址这个就足够了。 我们有一个类似的东西，下面是用jmeter的测试结果。 系统很简单，就是传递两个数字，做两个数的加法运算。此处单纯测试HTTP并发压力。 我的机器配置是 2G内存 1.73GHZ的CPU O(∩_∩)O~
请求数据
<?xml version="1.0"?>
<methodCall>
<methodName>com.join.rpc.server.test.Calculator.add</methodName>
<params>
<param>
<value><i4>200</i4></value>
</param>
<param>
<value><i4>200</i4></value>
</param>
</params>
</methodCall>
断言 200+200当然是400咯。O(∩_∩)O~
测试结果
哈哈，你这不会是自己写的测试吧！ 我手里的工作下来也要为我们这个通道写个测试。想做一个能全面测试又能单个测试的！ 看来我这块“砖”是抛对了，学了不少东西，呵呵！ |
| 返回顶楼 | |
