电信行业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接口的框架啊啥的。大家也可以推荐一下！