城的灯

论技术选型

人生就是一道选择题,对于码农来说更是如此。

谁都不想做“起来一个大早,却赶了一个晚集”的人,如果人生的命运你不能掌握,至少在技术这条崎岖的道路上,我们也要努力避免这种悲剧的发生。

风起云涌的新技术,喧闹浮华背后的各大社区,各种榨取码农血汗钱的会议,当然还有各种很久不编码的人生导师,这些会对你每一次技术选型的抉择起到多大作用,我不得而知。我曾经流连于各大技术社区,听各路布道师的成功学,并将很多时髦的技术运用到我的工作中。我一度自我膨胀,认为自己是块材料,至少不是一块废材。陶醉在各种新技术的研究与布道上,直到有一天我离职的时候,我的大老板对我说“你们研究的那些非常好,但是跟业务有点脱钩”。我当时没有在意,因为谁会在意一个不懂技术的Boss的建议呢!但是有一天我在地铁上突然想起那句话,突然思绪就开始飞扬,所以就有了下面的文字。附带一句,本人坐地铁很少玩手机,一般我就做三件事情。

1
2
3
1.思考人生
2.思考技术
3.看美女

正式由于第一件事情,让我对码农这个行业产生了新的认识。如果你不赞成我的观点,没有关系,因为我不企图改变任何人;如果你赞成,那我至少没有白忙活。


别高射炮打蚊子

如果你是老板,5K的工程师能搞定的事情,你不会请个20K的人来搞。Hadoop在10年时还没有现在这🔥,至少没有到各家培训机构都在靠此赚钱的地步。11年有机会在公司上了一套Hadoop,直到我14年离开时,也就几台的规模,主要受限于公司的发展。在这2年多的时间里面我在hadoop上做了很多的小扩展,当时spring-data-hadoop项目还没有发布。

  1. 支持自动打包直接上传到jobtracker,可以在任意java项目中运行。
  2. 使用snappy压缩。
  3. 扩展多种InputFormat/OutputFormat。
  4. 研究map端和reduce端join所代理的差异。
  5. 运维。
  6. 日志数据转化的自动化。
  7. 编写一些DSL的规则,自动生成job。
  8. ……

这些事情,可能对于一些专职搞hadoop的人来说,这都不是个事。我就一个人瞎折腾,别人都在封装的底层类上进行逻辑封装。最后才发现我们3年下来的数据压缩之后才2T左右。而且我们根本就不会分析一年之前的数据。以前觉得这绝对是一个成功的项目,现在回想也许我用更低成本就可以做到比这还好。很火的大数据行业,究竟多少公司有大数据,我想大概一双手就能数过来吧。成本和收益对老板来说,才是最关心的事情,但是对于码农来说技术的成长才是最重要的。


是否有成功案例

12年底,由于公司的业务发展,需要一套实时推送的服务。之前是通过client端http定时轮询来拉去消息的,Boss觉得实时性不够高,要自己开发一套实时推送系统。虽然之前用OIO写过简单的socket server,但是从来没有开发过支撑百万级别的长连接的NIO Server,因为当时公司的APP装机量已经超过2000万。当然Android的活跃数并没有到百万级别,但是后台service一直连接着,所以对该推送Server的链接支撑数要求还是较高的。

查阅了网上很多资料,发现方案有如下几种:

1
2
3
1. 基于MQTT协议的消息中间件
2. 基于MXPP协议
3. 自己开私有协议

当时网上有很多文章使用MQTT消息中间来实现推送服务,我当时就想到了Rabbitmq。由于Rabbitmq在公司内部已经稳定运行一年多了,并且有插件支持MQTT协议,加上是用Erlang开发的。我一想,这不是很简单嘛,在测试环境一测试,调了些Erlang虚拟机的参数,轻轻松松一台服务器就支撑到了30W链接的规模。Android端直接用IBM的MQTT Client,每一个id维护一个队列,有消息就往队列里面扔。第一版的方案就这样定了,在我们测试环境,表现得很理想。当时我们采用的是零时队列,就是如果链接断掉,队列就消失,这样内存就能回收。发送时去查询有哪些链接在上面,然后将消息通过routing key路由到指定的队列。我们当时知道这肯定会丢失消息,不过我们能够接受。我们最后放到移动网络一测试发现,我们的Rabbitmq中文件句柄一直增长,即使链接断掉了,当然我们在TCP参数调整方面有做了很多工作,但是都不能解决该问题,只好果断放弃该方案。我们花了大量的时间,在该方案上,结果发现该方案不行。当然最后我们自己基于Netty开发了一套自己私有协议的推送server,表现相当不错。XMPP太重,我们当时也排除了,当然不久之后,由于工作的变动,我有基于XMPP做了一套IM,不过个人认为这个方案远不及私有协议来得爽。

最后说一句:网上有很多不负责任的方案,自己根本没有做大量的测试就放出来,所以一定要有所甑别。