最近的两个发布回滚问题分析：一定要重视细节

1：一次是因为log.error()，后台日志报出大量的ERROR，虽然前台页面功能没有任务影响，但后台的日志文件要爆了，IO量过大。原因是程序员在CATCH一个异常后，直接打log.error(),而且ERROR MESSAGE直接就是把stack抛出。这个CATCH会发生在99%的用户修改产品的场景，逻辑存在问题。新功能，新字段增加时，一定要考虑老的业务。99%的时候会走到老业务场景时，程序就会走到异常，然后打log。异常抛出要考虑一下逻辑，像这种99%的情况走到log的场景，一定是逻辑上要处理掉的，不能用CACHE来处理；
2：预发布环境发现用户产品迁移时速度很慢，一个用户的产品只有一百个，去迁移了半小时。测试环境 时，一切都正常，检查程序也正常。后来发现SQL有性能问题，追问下去才知道，SQL REVIEW过了。但又作了小修改，没有再次提交DBA 进行SQL REVIEW。而这个SQL影响只是加了一个WHERE条件，这个条件加上后影响了ORCAL的索引引化，加上生产库的数据量是测试环境的几百倍，所以性能问题出现。又一教训。
这两个问题都是开发质量的问题，如何提高开发的质量意识，是一个问题。

一种包依赖引发的通宵发布与回滚

引用来自架构组姚明同学的邮件：

Intl-biz/wsproduct里面的代码修改如下：

public void setIndByAll(Integer indByAll) → public void setIndByAll(Integer indByAll, Object… objects)

对应于intl-biz/wholesalesearch里面的代码：

WsProductDO.setIndByAll

由于intl-biz/wholesalesearch是依赖于intl-biz/wsproduct，但是无论Intl-biz/wsproduct里面的代码是否修改，都是能编译通过的。

那么问题出在哪里呢？问题出在方法签名不一样。

这里，我们的编译脚本有一个致命问题：

我们的编译脚本是先编译了intl-biz/wholesearch，这时候对应的方法签名是：WsProductDO.setIndByAll(Ljava/lang/Integer;)

接着才编译了intl-biz/wsproduct，这时候这个方法签名发生了变化，变成了WsProductDO.setIndByAll(Ljava/lang/Integer;[Ljava/lang/Object;)

所以到线上的时候，intl-biz/wholesearch需要的是前者，但是intl-biz/wsproduct提供的却是后者，所以出现了大家看到的异常。

我的看法：

1. 减少不必要的包依赖；可以走远程服务的走远程服务；
   
2. 底层有变动接口签名，一定要通知相关方，当我们改的人不知道相关方有哪些团队时，一定要在发布群里说一下，并找架构组同学REVIEW；架构组同学的信息会比较全面一些；
3. 发布时的编译顺序很关键，这个编译顺序列表要随时维护；
   

一次阿里旺旺SNS应用接口问题解决的经验[2]

想到上回发布阿里旺旺上的一个SNS应用接口，这个应用就是传说中的阳光农场。应用需要调用阿里旺旺的用户资料，比如头像，昵称等属性。调用方式是HTTP接口，登录的时候应用会对当前用户所有好友调接口，获取头像URL。

在用户量达到70万左右时，系统开始出现问题（每个人会有50个游戏好友，相当于早上登录每分钟5000人的话，会有250000HTTP请求），甚至影响了其它子网站的登录。基于一周的排查，验证，确认问题出在头像接口对头像HTTP服务器压力过大引起，并且由于头像URL大多不同，CACHE的命中不高。

将头像改成一个固定的相同的URL后，问题解决，因为这个URL头像有缓存，并且命中率100%。

之后用户量再上升，发现又出现问题。系统登录出现问题。后经排查发现，头像接口服务器LOAD很低，没超过1，连接数很大，全部TIME_WAIT。原来头像接口是通过HTTP调用内网另一台服务器B获取到URL，虽然URL已经成为固定值了，但是内网调用还是存在，并且这个内网调用没有走内部VIP的域名，走了公网的普通域名。而B服务器的VIP对公网HTTP请求有访问速率的控制，内网VIP走相对控制较少。系统改成内网VIP后这个问题缓冲。当然最后是去掉了这个内网的调用。

经验就是：内网高频高并发调用HTTP最好走内网域名和IP，并要注意内网设备的一些限制。