一次失败的架构

两年后,再次来到北京后做了一个大数据项目。整个项目其实将上海的成功复制到新的项目中,包括系统架构。因为当时确实没有认真接触大数据项目,所以只能直接照搬系统架构,这也是我认为犯的一个致命错误,险些导致项目功能无法满足性能要求!虽然目前系统也能凑合着运行,但是我们原本可以根据实际情况,做出更好用户体验的系统!

但是若要说为什么让一个没有认真接触过大数据的人来做系统架构呢?这个我觉得是目前项目外包的普遍现象吧。。。虽然我可以以此为自己开脱,但是从内心上,我还是认为自己有责任。最麻烦的是,现在即便想到更好的方案,但是也无法做出改变,因为上线后系统再做出重大架构调整,客户肯定会追责。所以只能先凑合着,等到合适时机再改变吧。

在架构中,有几处失误:

1、没有考虑服务器数量和性能对架构的影响。当前系统架构严重依赖于solr,在上海的时候有几十台服务器,结果北京这边只购入了二十来台,留给solr的服务器只剩下了不到十台。在对solr的深入了解,发现solr最高性能需要与数据存储相近的内存容量。我们最终宽表数量20来亿,数据存储大概2TB。这样solr内存就需要2TB。

2、没有意识到一些需求导致数据量翻倍,进而导致硬件资源要求翻倍,这是最为致命的。因为在这边的项目中,硬件资源是急缺的。一开始宽表也就10亿,后来需求变更,导致宽表数量翻倍变成20亿。当时如果能理解到对硬件资源有如此影响,势必坚决拒绝该需求变更。

3、对系统架构中关键组件(例如本项目的solr),没有认真研究其性能特性以及资源要求。以后在使用不熟悉的组件的时候,必须慎重,再三研究。而不是别人说什么组件好,就用组件。还要考虑对硬件等各方面的要求。