衡量一个优秀系统的标准(工作总结)

各位：

最近我们在开发一些项目过程中，或多或少都遇到了一些大大小小的问题，这些问题涉及多个项目，比如PPC、支付中心等等，也涉及到各个组许多同事。

这几天我一直在想这些问题为何会发生？是因为我们做事不认真或者是我们的能力本身就不够？？再或者是这些问题本身属于不可抗力非人力所能做好？

想了几天其实现在也没有很好的答案，不过倒是联想到了如何衡量一个系统是否是优秀的标准。在这里就不重复书本上说的什么健壮性、可扩展性等等比较高深的理论了，只说一下在安居客网站中优秀系统的标准。

一、功能

这个指标比较基本，也比较容易实现，只要严格按照PRD保质保量开发，并且相关的测试同事按标准进行正规测试就好了。但这里要强调一点，技术人员绝对都是高智商人郡，很多的时候在产品设计阶段都需要体现出技术人员的思想、创新。

二、速度

这个是指系统运行的速度，简单来说就是一个页面执行时间。通常在我个人的观念里，正常的页面时间都应该在100MS以内，超过这个时间的或多或少都会给系统造成压力，给使用者以打开缓慢的感觉。这个100MS各个公司各个人的标准不一样，我想说的是大家在开发一个程序或者一个系统的时候，是否想过性能问题呢？？做过哪些性能的检测和优化呢？

三、容灾

任何一个系统都会有出现异常的情况，对于我们网站我们的程序来说就是比如操作数据库失败、操作SOLR失败、调用某个API失败等等，再往上来说就是DB出问题了怎么办？再狠一点就是DB的磁盘坏了，数据都丢了怎么办？APP出问题了怎么办？DNS解析出问题了怎么办？LB出什么了怎么办？网络出问题了怎么办？等等等等。大家也许会觉得这是否乞人忧天呢？我可以很明确的告诉各位，一个系统是否优秀往往就是在出现异常时候体现出来的。而一个优秀的系统也一定在正常运行同时也建立了容灾或者异常情况处理机制。比如现在所说的HA、双通道、记日志等等等等。而这方面恰恰是我们系统现在最最薄弱的环节。

四、监控

这里的监控通常分为两个方面，1是系统级别的监控，这个主要是针对服务器、操作系统及该系统本身运行情况的监控（比如是否运行，是否正常结束等等）。

2是数据级别的监控，因为我们经常发现一个程序是正常的执行完成了，也就是说系统级别没有任何问题。但因为程序中的某个逻辑写错了，导致结果是错误了，比如要给A经纪人加分，结果加到B身上了等等。这类错误第一种监控是发现不了的，只能是对系统业务逻辑很了解的人才能进行这种监控。所以我们说凡是重要的系统（尤其是重要的JOB）都应该说一个相对应的数据监控程序。

五、报表

这里的报表与监控有些像，大体也分为两部分，分别是系统运行情况的报表和数据的报表。就拿支付中心举例来说，我们现在通常关心的就是支付中心的每天有多少次扣费请求多少次充值行为等等，这些就是系统运行级别的，这钱本身关系不大。而另一个要关心的就是现在支付中心里存了多少钱呢？昨天扣了多少？分别是哪些渠道扣的？昨天充了多少？等等等等，这些都是与系统有关的业务数据。从时间上来说报表通常分为日报、周报、月报、季报、年报等，展示方面除了能够在特定的后台看到，还应在适当的时候发给这个系统的相关干系人。

六、安全

安全主要是指三个方面，1是指这个系统程序部分有没有安全的漏洞，比如被注入什么的。2是指这个系统运行环境是否安全？比如服务器是否要开外网啊？是否只开了必需的端口？服务器的操作系统是否存在漏洞？这些机器哪些人能够登录？等等。3是指数据安全，比如会不会有人进去越权读数据呢？更有甚者甚至去更改数据呢？等等等等。

7、文档

一个优秀的项目在规划、建设、运行中一定有各种各样各个阶段的设计、实施等相关文档，所以文档是否完备准确也是一个衡量一个系统是否优秀的非常非常重要的点，而这点是我们所有人基本都不考虑的点。

以上7大点只是我最近的一点小心得，当然如果每个系统每个程序都把这7点做到完美也是不可能的，涉及的东西、工作量及资源太多，但是我们不能因为我们做不到而不去想，你可以在写每个程序建立每个系统的过程中，思考一下这7个点，哪怕最后的结论是我只需要完成第1点，其它6点都是现在所不需要的，2年后再说吧，这样也是我们认真分析过的结果。而不应完全不考虑这些东西，需知完全没想与想过之后但没有实质性的行动也是两个非常大的差别。

奋斗，是一件长期而漫长的过程，在这个过程中，会有很多失败来阻扰你前往成功的信念，你唯一要做的，就是坚信自己对的方向，一步一步的大胆迈进。=============================================



关于速度优化小结：

通过自己速度优化以及昨天的旁听，有以下总结，只记住了部分，可能还有错的,多多沟通 ^_^：

1. 优化页面，首先要搞清楚页面的功能模块，以及模块间的先后逻辑关系

注：可以去掉已经不需要的代码。同时，在取数据的时候，如果有先后逻辑，若前者无数据，后者可以不取，减少数据的查询量。

2. 通过debug或者log日志，分析controller和page等调用的时间是否在正常的范围之内，若异常可着重分析。

3. 对于solr的使用：

首先，不能把希望寄托在别人的身上，比如solr本身的查询速度，主要的应该从自身开始优化。

其次，where的条件命中量 尽可能的减少。

然后，可以分析数据，重构方法，减少每次的solr查询次数，比如 有的是每次搜索一个id，可以通过in来一次查询

然后，当有多次查询的时候，如果有先后逻辑关系，当前者搜索无结果时，下面的查询可不进行，或者根据逻辑关系，再进行相关查询，而不是每次把所有的数据都查询出来。

4. 加快取数据的速度，可以考虑使用zmq或者缓存，当然，要尽量增加缓存的命中率。

当数据量较少时，可以考虑全部存缓存，不用查询solr。

5. 对于api的调用，可以选择异步的方式。

6. 在页面上，尽量的少用component。

分析页面模块，对于实时要求并不高的，可以选择显示缓存中的内容，即使没有内容或者内容不是最新，在其他地方异步更新缓存。

对于一些用户加载时看不到或者不太引人注意的地方，可以加载后使用ajax异步调用然后再显示数据。