[旧文搬迁]偶有所感——为什么我想先做产品技术


感谢IT牛人博客聚合上还能找到我之前博客的一些内容,因为之前主机没续费等各种原因,也懒得翻之前的备份文档了,就把那上面的文章直接拷过来整理一下好了,只搬迁一些还有意义的内容好了,其他的就让它随风而去吧。

最近在淘宝处在一个转折点,一方面有转化面试,一方面就快回学校报到了,再另一方面也是关于自己更应该做什么的思考。刚到淘宝实习时,第一天培训,神奇般的得到了华黎的赏识,希望我能去他那组。当时因为怕社区线这边可能会做前端表现层去做业务逻辑,同时自己也是对中间件很感兴趣,就想去他那里。不过国藩没同意,因为毕竟我还没有真正到社区线实习过,也并不知道我就真的不喜欢这边的工作,所以还是让我现在社区线这边实习,如果实在感觉不给力,再考虑transfer的问题。现在看来,国藩老大是对的,原因一会再说。

然后就是开始在社区线的架构组实习,很幸运,我被分去做社区线的搜索引擎。虽然说这里做搜索引擎并不是想象中那么“高端”——搞分词,搞索引,搞匹配等等,只是基于lucene和solr进行开发,因为这个搜索其实现在也是处于成长阶段,正如育森老大所说的,先要让自身的架子稳定下来,才能想去做一些更高级的事情。但是,实际上在做搜索引擎的开发时也接触到很多以前在学校经验几乎为0的东西——分布式系统。

其实真正去做了才发现自己其实欠缺很多东西,如果真的要是去了平台架构组,我可能不会得到在社区线这么多机会,同时因为根本不了解淘宝的应用,就去盲目做中间件,我真能做的好么?也许在老大们的思想下写好代码还是很简单的,但是这样的东西真的是我的么?显然不是,也不会是,因为我根本不了解这个中间件所应用的场景。

一晃将近两个月过去了,就在转化面试的前一天晚上,华黎问我实习的感受,还有在社区线这边呆的怎么样,如果不爽可以来他那里。之前在和育森交流时,育森也说过,如果我想专心只做技术,可以推荐我去平台架构那边,之前他也有机会去那边,但是他没去,因为他觉得脱离业务很难搞好技术,而且技术也是为了服务于业务,因此他选择回到社区线。这点我还是很认同的,所以在和华黎交流时,我也说我觉得我应该先在社区线这边多锻炼锻炼,毕竟如果不对淘宝的产品应用有了解,很难做好中间件。华黎也是很认同我的想法,也说在SNS的架构组锻炼还是很有好处的,而且毕竟中间件也是产生于生产系统,是将那些共性提取出来,做通用的服务。

今天转化面试时,其实也是和毕玄交流了一下这方面的感想,也说自己做搜索引擎也是用到了淘宝很多中间件,但是站在用户的角度看问题,会发现这个视角和程序员是不一样的。从用户的角度才能更加清楚的知道如何去做中间件,如何能把中间做的易用、稳定、健壮、可扩展性高、通用等等。毕玄也是比较同意的,而且还就我说的底层透明,给我讲了HSF的底层透明带来了什么不便,所以这个底层透明到底是好还是不好,还是值得商榷的。

其实说到底,由于终搜的目标是一个通用性搜索框架,因此实际上终搜本身就是中间件。而且从这次做server-dump的相关接口设计实现上来说,真的重构了无数次,为什么?就是为了做到更加通用、易用、易于扩展等等。

今天负责协助淘女郎那边升级,他们的Dump需求是:从表a取主要数据,然后在根据表a的某字段去另外一个库(实际上是另外一个应用的数据)的表里去取其他信息,然后整个拼合起来做索引。问题来了,我们现在的模型就是单条SQL去dump数据,基本都来自一个应用,即使分库分表,也仅需配置相应规则即可。显然,这个需求不能套在原本的框架里。老大建议还是重写一个DataProvider,然后去管理连接什么的,但是要便于扩展,虽然另外那个辅助表只是分表而已,但是保不准哪天就分库了,所以你尽量帮他们做的好更改些。

于是我开始思考他们的业务逻辑,因为涉及分表,以后还可能涉及分库,所以在利用原本分库分表规则解析器的情况下,我需要得到一个反向索引——原先是数据源对应一堆分表后缀,现在要分表后缀对应数据源。但是我得想好怎么把数据源交给用户,既不用让他们做太多事,同时我也在考虑万一以后还有这种需求,我不是还得写个DataProvider么。既然这样,我不如不把数据源给你了,我只给你结果,剩下的交给我管理,于是有了下面接口:

public interface SQLEngine {
    public Map<String, String> execute(String param) throws Exception;
}

SQL语句是预先注入,然后根据传进来的参数进行相应替换。继而我又想,现在淘女郎是只要一个参数,如果需要多个参数的怎么办,于是接口变为:

public interface SQLEngine {
    public Map<String, String> execute(Map<String, String> param) throws Exception;
}

这样就给力多了嘛,然后又想,现在淘女郎是一一对应的关系,如果现在情况变成一对多了,该怎么办,于是接口变为:

public interface SQLEngine {
    public List<Map<String, String>> execute(Map<String, String> param) throws Exception;
}

经过一番改造,做后终于做出了一个比较通用的东西出来,只需要注入需替换的Sql语句以及分库分表规则(数据源本身就在配置文件里定义了),我就可以返回你要的东西。这样对于用户来说就简单多了。在请育森老大review代码时,他说你这个List实际上有内存溢出的风险,如果数据量比较大的话。不过这个可以在应用端控制,只是理论上的风险,不过iBatis也是这么做的。

iBatis也是这么做的,对啊,我这个东西基本上不就相当于是一个简化版只支持查询的iBatis么,尽管我完全不管O/R关系。但是,最关键的是,我可以支持分库分表啊。一直说想做个分布式数据访问层,对这个有点兴趣,但是现在竟然误打误撞做出这么一个Prototype来!这个,虽然是是在终搜体系中的,但实际上它也是一种中间件,可以应付80%的场景,除非你业务特别复杂。这就是所谓的中间件诞生于生产系统吧。

现在想想,为什么之前想做个DDAL玩玩但是始终没什么思路,但是现在却真的做出来了(虽然它不是一个完整意义上的DDAL)。首先,之前只接触了一些分库分表思想,但是没有实际去了解它的应用场景,一开始可能会无所适从。第二,我从一开始就是想的实现一个完整的DDAL,这样要考虑的点实在太多。又有多少中间件是从一开始就设计出一个伟大的架构然后去实现它,然后让用户去使用它呢?可能不会有,大多数中间件就是从一个小的点子慢慢扩展出来的。如果不是这次淘女郎的业务有需要,我可能不会去写这么一个东西,连这么一点小东西都实现不了,还空谈什么DDAL呢?

所以,我觉得我留在产品技术部门是一个正确的选择,一开始站在一个很高的起点上,虽然是高,但是脚下的铺垫不够厚实,摔下去也很容易。相反,如果每一步路都实实在在的踩下去,夯实基础,我一定会站的更高。


文章作者: Odin
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 Odin !
  目录