thinking in asp 之二 高端大气上档次

那么，什么是高端大气上档次呢？我想先放一张图，然后来逐一解释。

什么是高端？把“端”字举高点儿——设计别人没想到的、做别人没做到的。

比如小翟同学，把股票分析的原理和公式引入对热点视频数据的分析和预测，这种玩儿法我们在学院派的paper里面偶尔能见到，工程应用这么玩儿的恐怕很少。最重要的是，实际效果也很好，这个是学院派的paper——特别是国内的大部分硕士论文比不了的。

 

专用吐槽格，可以跳过，不影响阅读。

关于对国内硕士论文的不爽，由来如下：本人在研究cache策略的时候，找到一篇硕士论文，论文对缓存算法的设计基础是zipf law。经过仔细阅读之后，终于来到了最后一个章节：实验论证。问题粗线了：实验数据是用的基于zipf-law的模拟数据。得到的结果当然很牛X。但是，这特么的跟“自己打枪、自己画靶子”有什么区别？作者你还敢再无耻一点儿么？ 虽然如此，我还是把他的算法实现到我的测试框架中，用线上的真实数据做了一个测试，结果得到的命中率说起来都是泪啊……

 

那这个东东跟asp有关系么？当然有。这个本来打算应用在Asp的子系统DQnet（快播网络）里面，小翟同学的设计文档也写了，而且也出了产品原型，只不过因为硬件条件的限制等原因没有在生产环境实际跑起来。

再比如国鑫同学，写了个智能监控预警的原型。这个东东是做这个的：

传统的监控报警模式是设定一个阈值——threshold，不是阀值。比如连接数1000，超过此数就报警。

但是服务器都有自己的小脾气，有的跑到2000还很稳定，有的到了700就完蛋。管理员得一台台去手动设置。而且更重要的一个因素是，1000这个数值本身就是蒙出来的——没法不蒙，只能先蒙再调。

所以国鑫同学就做了一个程序，先根据每台服务器自己的历史数据做聚类（cluster），找出其中的稳定波形。然后用当前的监控曲线去和历史稳定波形做拟合（匹配算法DTW：dynamic time warping），拟合偏差大就报警。——这个跟咱们公司人工干的是一样的事情：看图表，当前曲线跟历史曲线不对付就赶紧找人排查是否有故障——这个也足够高端。

这个原型也是在asp开发过程中，面临系统监控问题的时候头脑风暴出来的一个小玩意儿（顺带向友情赞助历史监控数据的刘同学致谢），至于为什么没用在现有的系统中，主要原因是没有精力去继续完善。

 

专用吐槽格，可以跳过，不影响阅读。

一个更带有炫耀而且无耻意味的解释是：对于asp这个大西瓜而言，这种小芝麻粒粒（国鑫和小翟同学辛苦了）就搁着吧，有时间想起来再说啦blah blah。

 

关于大气，主要指的是大家都在用或者是知名的公司、项目组在用。

这个一方面是面子因素或者是思想偏见，至今我还是能碰到一些公司吹嘘自己的产品的时候使用诸如“我们基于java j2ee开发”等等，这种句式在几年前更常见，仿佛php和其他开发语言就注定是低端的小玩意儿。你敢说一个竞技水平很差的玩家有一个极品鼠标就可以在DOTA中超神么？

另一个方面，既然大家都在用，那么相关的文档多、开发社区比较活跃、解决问题的途径多、自己试错的可能性低，能够降低开发的风险。这个恐怕是在团队开发过程中值得重视和仔细考量的一个问题。

还有一种就是某项技术被知名公司和项目组使用或者大力推广，给人造成大气的印象。比如google 的groovy。遗憾的是，groovy我就听说过两次，第一次是google推出它的时候，第二次是在去年架构师大会上某个团队讲解他们如何基于openstack做私有云的时候。对待新技术、新框架，个人单枪匹马可以随便玩儿，但是在团队开发的规划中，恐怕就得按捺下自己的冲动，选择中规中矩的适合团队的工具——哪怕它的功能、性能比起新技术差了一大截。

 

关于“上档次”的理解，请参看上文发的图。

专用吐槽格，可以跳过，不影响阅读。

如果还是不好理解，我友情提示一下，这个是一个动词+名词的组合。

 

Asp系统刚出生（也就是1.0版本）的时候，可以用丑小鸭来形容，尤其是在有第三方公司的产品参与竞争的压力下。一方面，用现在的眼光看来，当时的产品确实简陋到可怜，另一方面，由于是对一个空白领域的摸索，自己在心理上就会有很大的不自信。一个简单的例子，我在技术交流的时候，如果听到其他公司的产品实现有和自己的思路吻合的地方，就会觉得开心，心里会踏实很多。

当其时，asp能站住脚，跟公司各级领导和同事的支持是分不开的。而跟第三方商业产品的PK恐怕还停留在一个自己会觉得比较心虚的层面上。

等到asp在一个季度后发展到第2版直到现在的3.2版本，我们有足够的信心认为asp完成了“上档次”的跨越。理由很简单——在同样的硬件条件下，asp有把握比其他的第三方商业产品运行得更好。

现在，我们敢于骄傲的宣称，asp 上档次，asp和其他同类产品比，上了档次——这里，我坚持把“上”字标注为用动词，也坚持认为“档次”这个词等同于“其他同类产品”。

敢于宣称不怕PK不是因为自满和狂妄，而是因为我们得到了结论、摸对了路子。为了形象的说明这一点，我想先展示三件现代工业的杰作：

参见http://www.guancha.cn/history/2011_10_17_60664.shtml

这是一架米格25，围绕这个飞行器的设计任务从一开始就超过了其诞生时代的技术能力。她是一件超越时代、充满苏式的“粗暴想象力”的杰作——即，用匪夷所思的简单粗暴实现方式，完成一项不可能的任务，甚至这架飞机从里到外就是由各种粗暴的部件组成，从机体材料到电子设备无一不是如此，根本不符合一架敏捷的战斗机要求，但却丝毫不影响他完成帝国赋予的任务，甚至一度让不明就里的北约对其充满恐惧，实现了战略欺骗式的威慑。围绕这架跨时代的飞行器，有着许多传奇：它至今仍是人类仅有的两种闯过热障的大气层内飞行器、创造了无数飞行记录。

这里想说的是：不要被其他产品的设计和实现思路带着走。具体点说，就是第三方商业产品的先期优势过于巨大（研发团队、技术、产品积累和开发时间），在产品初期试图在它的优势领域PK无异于自找麻烦。我们需要跳出洋框框，走自己的路。

左图是国产J20，右图是美帝的F22。

J20的弱点在于心脏病——发动机推重比不高；反观美国，略带调侃意味的评价是：美帝的发动机彪悍到飞机设计不需要考虑外形问题，上去个砖头形状的也能玩儿超机动。虽然动力差距较大，但是J20的整体性能达到（超过）了F22的水平，原因在于J20改玩儿自己最强的东西——飞控。全动的鸭翼、尾翼、边条翼、DSI进气道加上开发出的顶尖的飞控软件，保证了J20在动力不足的情况下仍然能够在机动性上比F22更高一筹。

回到asp的问题，也是从asp刚开始立项我就反复问自己的问题：你凭什么说服别人用你的产品？

三架飞机已经明示，对一个系统工程来说，木桶效应永远有效。当某家国外软件服务商在推销自己的一体化解决方案的时候，他们的意图是说服用户扔掉旧的桶、换一个新桶，而这个桶的长期成本恐怕高的吓人；当我问另一家国内厂商怎么解决获取视频数据和文件的问题的时候，对方的回答含糊其辞，这让我意识到，他们更愿意去强调：他们把自己的那块木板做的很长。

好吧，解决问题的真正关键是搞定最短的那几块板，而不是和别人去比他们所长的那块板。仅此而已。

在这里，我引用我在《ASP技术白皮书》的结语中的一段文字来描述我得到的答案：

 

ASP生存的土壤在于体系，在于系统整合。深刻理解视频网站运行流程，平滑切入传统服务的生产链条，高效联合和延伸上下游相关系统，及时的处理新问题、针对性的调优整个“生态圈”，是ASP逐步发展至今的基本保证，也是ASP保持竞争力的根本来源。

 

由是引申的另一个问题是：如何说服其他系统配合整个生态圈的建设？方针也只有一个：除非是不可避免的情况，不要给别人添麻烦。

什么是添麻烦？就是你通过行政手段去要求其他系统修改流程、提供接口，以满足自己系统的需要。

尤其需要尽量避免的是，为了自己的实现简单、清晰、漂亮——哪怕是正确的考虑，而去要求其他系统进行额外的改造；反之，我们应该多想多做，尽量的调整自己的系统、让自己的系统去适配其他的系统，减少其他系统负责人员的工作量，这样，实施的阻力才会减少，时间才有保障，事情才能按照自己的规划进行。这样做，同时提供的一个好处是，降低了系统间的耦合性和依赖程度，带给自己更大的自由空间。

这种情况，在存在第三方的产品竞争的时候尤其明显。第三方在这层意义上，就是一个给别人“添大麻烦”的人，因为他们无法深入，而他们在和其他系统的整合——尤其是开发时间和执行性能上——弱点极其明显。