POC-失败的纪念

前不久,参与了一个POC,主要内容做实时数据流处理,并到前端实时展现。原本以为只是简单的技术POC,只要根据用户的要求完成功能即可。

可是最后客户说我们只是达到了功能的基本要求,并没有想到基本要求外的东西,没有做出更好的方案,或者在原来的POC要求外再提出更好的方案和功能!

难以理解,这和以往的POC都不一样了。以前只需要根据要求列出功能是否达标即可,这次还要从方案层面给出更高的指导。我们从一开始就朝这个思路上想,只是单纯从技术上思考。而客户是需要我们认真的去理解业务痛点,理解需求的真正意图,然后指出客户想法上存在的问题并纠正,最后才是通过技术手段提出最好的解决方案。

当然,我觉得最大的可能还是被客户玩了,毕竟商业还是有一些商业的东西。

Solr优化二:启用MMapDirectory

SOLR默认使用的是NRTCachingDirectoryFactory,但是当我们不需要NRT的时候,可以使用MMapDirectory。

为什么要使用MMapDirectory?
简单来说,它比普通的文件目录要快。

前提:
1、操作系统最好是64位的。这样指针地址空间几乎不用考虑。32位只能使用3G左右。

性能对比:
1、使用前:

2、

树控件优化

今天在使用系统的时候,意外发现页面加载树形空间异常缓慢,慢到了10秒以上。之前将数据库中数据转换成树形结构是我写的,虽然没有对数据做缓存,依然是每次从oracle中读取并组装成树,但是不至于慢到10秒以上。

经审查发现,返回的数据信息合计三千条,数据大小尽然达到4.4MB,整个数据下载花费8秒。而等待只花了1.75秒。

整个分析说明服务器只花了1.75秒就把数据组装完成并返回到客户端,只是返回的数据量达到了4.4MB。
仔细查看返回的数据,发现同事写的返回结果中包含了太多前端不需要的字段,足足包含了60多个字段。而easyui前端其实只需要4个字段就够了。

很明显了,优化方案可以如下:
1、只返回前端需要的字段,将60个字段变成4个字段,大大缩小返回数据量;
2、由于这类数形数据基本不会变更,可以变为缓存存起来,避免每次从数据库中读取并组装。
3、使用异步数加载,每次点击只加载一个层级的数据,避免一次性加载过多数据,提高页面响应速度。

使用iframe报错X-Frame-options Deny

今天在easyui中使用iframe的时候,报错:X-Frame-options to Deny。而且iframe访问的网址是同域的,还不存在跨域的问题。都是localhost。

仔细搜索了一番(面向搜索编程),发现是spring security设置了这个响应头。所以我们可以改掉它,允许同域访问。

添加代码如下:
http.headers().frameOptions().sameOrigin();

解释下frameopthons的几个参数意思:

  • DENY – is a default value. With this the page cannot be displayed in a frame, regardless of the site attempting to do so.(禁止网页现在到iframe中)
  • SAMEORIGIN – I assume this is what you are looking for, so that the page will be (and can be) displayed in a frame on the same origin as the page itself(同域页面可以显示在iframe中)
  • ALLOW-FROM – Allows you to specify an origin, where the page can be displayed in a frame.(制定可以显示在iframe中的来源域)

参考资料:
1、https://stackoverflow.com/questions/28647136/how-to-disable-x-frame-options-response-header-in-spring-security
2、https://stackoverflow.com/questions/42196013/spring-security-x-frame-deny

一次失败的架构

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

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

在架构中,有几处失误:

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

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

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