技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> 基础系统软件的价值

基础系统软件的价值

浏览:1231次  出处信息
    盛大推出云计算服务,看起来想做类似于Amazon AWS的IaaS。看了一下,结构化数据管理的功能很弱,只有最简单的Key-Value服务,只有GET/PUT/DEL,没有条件更新没有锁,没有扫描,这让我觉得很不靠谱。结构化数据管理是99.9%的应用都需要的,而基于盛大云这样简单Key-Value来开发应用是很麻烦的事。比如:

    1、如果把多个实体属性拼起来,没法索引,效率也不高;如果分开,那经常得用很多个GET;

    2、没有索引和扫描,各种数据列表都不容易,比如按时间/阅读次数/评论次数排序的文章列表,你要用一个KV来维护ID列表,这会涉及复杂逻辑(比如按阅读次数排序的列表就不好搞),而且还会数据不一致;

    3、刚说到阅读次数,好把,基于盛大云要维护一个会被并发更新的准确的计数是不容易,很不容易,简单到文章阅读次数,评论次数,好友个数等等。因为没有条件更新和并发控制,你把值读出来,+1再存回去,一并发就错了。

    总之,这种最简单的Key-Value系统,我一直认为是对系统实现者来说是福音,但对系统使用者来说是绝对坑到祖宗的玩意。如果盛大云就只有这把刷子,没几个开发者愿意用。还好盛大云据说会推出MongoDB服务,这还算有点靠谱。

    最近侧面了解到隔壁单位的一些消息,挺好玩。据说隔壁单位也有DDB,基本原理跟我们没区别,但功能很简单,稍简单的查询搞不定,分布式事务搞不定,有哥们了解到我们的DDB后惊呼:都是DDB,怎么差距这么大呢!但那边做系统的说这些复杂的功能不能提供,否则会被滥用,不能保证性能。还说有一些大P做一些系统,外人和主管看上去很牛,因为技术很先进。但用的人怨声载道,因为稳定性实在不行,两天必死一次。

    我越来越觉得这不是正确的做事方式。我觉得做基础系统软件,是希望能够让用户(也就是基于这些基础软件来做应用的人)能够很简单的做出正确、稳定并且高效的应用。很简单的做出应用是指开发效率高;系统不出错并且稳定,这几点是最重要的,高效是在满足前面这几点之后再追求的。系统常出错或不稳定,性能再高也没用,这点可能不用多说。但开发效率的重要性,是工作之后再深刻的体会到的。

    做了5年系统,有一件事最失败。我们在DDB里支持了Master/Slave读写分离,希望对数据实时性要求不高的查询去访问slave。这样系统好伸缩,撑不住了加个slave就行了。唯一的缺点是slave上读不到实时的最新数据,可能晚个几秒。我们想几秒有啥关系呢,我写了篇博客,其他人过几秒钟才看到,这有毛关系?但这个功能作了两三年了,几乎没人用。开发者说,要用这个,代码得多很多判断逻辑,每个Dao都要加个参数标明能不能访问slave。这得增加多少开发成本,多出多少bug啊。进度这么紧张,系统正确性这么重要,你好意思再让他们用吗?后来我们被逼上绝路,硬是基于复制实现了系统的准在线扩容,这次大家都满意。这才是帕累托改进!

    之前看Codd的图灵奖获奖感言,把关系数据库跟生产力扯到一起,觉得这哥们比较虚,上纲上线。Dijistra多实在,那么大成就,说是humble programer。这几年,看了不少真实的数据库应用,感觉Codd所言不虚。如果没有关系数据库,如果没有陈述式的SQL,没有ACID,开发应用不知道会复杂多少,系统bug不知道会多多少,开发人力成本不知道会增加多少。看基于RDBMS开发的应用,Service调Dao,Dao操作数据库基本上就一两条SQL,业务逻辑清晰无比。要是换成盛大云那样的简单Key-Value,复杂可想而见,基本类同Python和C的开发效率差别。

    基础系统软件跟产品一样,首先要考虑的是用户的感受,而不是实现的难易或技术的先进。用户最需要的就是系统用起来爽,只要写几行业务逻辑代码,剩下的基础系统软件都帮他搞定。这样,开发效率才能上去,系统质量才能上去,在互联网领域竞争中才能领先。反之,即使基础系统软件稳定、可靠、性能高效,但用户在此基础之上没法直接写业务逻辑,得重复干系统层应该干的事,开发效率和系统质量都没法保证。像网易这样规模的公司,如果没有DDB、DFS,让开发者像用一个单机数据库和文件系统那样简单,那每个产品都要自己来分库、分表、分存储、搞索引,一大堆烦杂的事,花气力也一定搞不好。

    搞系统的人喜欢做性能优化。性能优化了,自然是好的,但一定要明白系统的性能是个整体。如果为了让底层系统好实现,好优化,把底层系统的功能弱化,则底层系统的性能是高了,但却导致上层做了更多的系统性工作,反而导致系统整体来看更复杂,性能更差。这些工作,总是要做的。要么在底层系统做,由更专业的人做一次;要么在上层做,由不专业的人来做多次。哪种好一目了然,基础系统应该做多点。

    所以一直对很多NoSQL系统、最终一致性不太感冒。虽然可伸缩性没问题了,但系统功能退步了,应用开发难了,这样的系统不会有主流市场。

    NoSQL只有功能不断丰富到可与RDBMS相比、数据保证强一致性,我觉得才有戏。目前只有Google Megastore还凑合,开源的还都不行。选Key-Value/Entity不选关系模型和SQL、选最终一致性不选ACID,总感觉是做基础系统的人推脱责任。当然可以以此起步,千万不可以此为目标。那些吼吓ACID一定性能和可伸缩性不行的人,就相当于吼吓Java性能不行一定得用汇编,我觉得是主次不分。

QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1