Xiaohui Deng's blog

前些天在微博上看到这么一句话：

@霍泰稳：和同事今天聊到一个很有意思的话题：技术人员通常都会追求完美，然后时间就在追求的过程中蹉跎了，生意人讲究够用就好。所以Facebook的那句Done is better than perfect，应该不是哪个CTO或者架构师想出来的，而是某个投资人或者管理层人员说的。

这个真心赞同，写个程序，写个方案，写个ppt，时间就在追求中蹉跎了。这就和架构设计一样吧。事情不可能做到完美，总是要trade-off。认清关键风险才是真所在。后来昨晚睡得时候还在想这个问题。中午就想明白了，这完全就是瀑布式开发和敏捷开发优劣啊，都想想预先定义所有需求，做好所有准备，后续就可以按照定义好的需求实施。而瀑布式流程开发这早就被证明是不可行了。当然敏捷开发先原型，再快速迭代会成功。程序猿学艺不精毁一生啊！

 

以前沉迷技术的时候总是沉迷于一个误区，看到一个很新，很NB的技术，就恨不得在所有项目里面都用上，当然现在大家知道，基于成本，进度，稳定性，甚至是厂商支持的因素，实际在项目中大家还是相对保守，但是技术从来都是需求驱动的，当旧有系统出现瓶颈，甚至已经到了原有架构无法维续的地步的时候，刚才那些困难马上就都不存在。moore的这个图真挺好，算是第二摩尔定律？

 

一个技术产品的生命周期，作为呃 innovators和early adopters使用一个不成熟的技术需要冒相当的的风险，但是为了解决迫在眉睫的问题两者都必须冒这个风险，没有创新，很可能决定了企业的生死存亡。early majority 对此项技术采用的急迫性相对降低，但是对技术上的采用相对大胆。成熟之后到了main street，变成大路货了，保守派们也终于跟上。

技术的方向在哪里，不是看目前发展到什么阶段，而是读懂它将会往什么方向发展，还是那句老话，技术完全是业务需求驱动的。一些由于当前技术限制现在看来大胆，狂妄，不切实际的想法，只要是人的自然需求，那必然最终会实现。

最近在琢磨云计算和大数据，sharding也好，cluster也是，核心都是‘divide and conquer’ 这个经典理念。’services oriented’ 这个就不用说了，也是很早就在提了。既然大数据发展到今天是互联网，移动通信迅速发展的自然演进。那下一步技术方向？我觉得是目前还不十分成熟的实时流计算。I Want it now! ，这才是人的自然需求，为什么要等，我现在就像看到结果，知道现在正在发生什么。以前看到新技术，但是那时候都是看到别人实现了，开始眼红，就想跟风做，但这种最后只是想想，其实很难落地，最后就变成空谈。但是这次不一样了，先从基础开始，也是是不太先进，但是Done is better than perfect不是吗？小步快跑。。

 

最近在琢磨大数据，让我有机会参加#全球架构师峰会#，当然这个名字是有点夸大啦，如果改成全国那还是更贴切一下。今天有两个意外。一是发现男厕所要排队了，女厕所很空闲。第二技术大牛们的标准装扮是T恤，短裤，凉鞋。

现在想想，工作这几年来，我其实一直以成为一个架构师为目标，虽然之前一直没想透着点。但我是以一个架构师的所需素质，懂应用，懂硬件，操作系统，网络，存储来进行自我学习。我做开发的时候，就主动想做一点运维，希望更了解一些系统方面的知识。后来如愿了，现在想想我在ODSB的运维经历真是一段宝贵的经历。

上午讨论架构师必须的素质的时候，说到架构师需要深度，还是广度，哪个更重要？这看来是个永恒的话题。一个比较万金油的回答的是两个都要，都很重要。架构是一种手段，架构师是用来解决问题，漂亮的解决问题的。

一个好的架构师我觉得应该还要有以下几点。

1.深刻理解需求，更重要的是能预见需求

2.能够了解一些实现细节，在一些关键点上要有足够深度。

3.懂得如何权衡，trade-off，设计架构遇到的一些问题其实是互相矛盾的，不可能有一个完美的方案，如何权衡，这是架构师的智慧。

3.技术创新在加快，有时候过去的经验反而会成为一种瓶颈，一种限制。需要时刻保持好奇心，时刻在学习。

4.能够自主思考提出解决的方案。而不是说这方法好，因为google，facebook都是这个干的，别人用过说明是一个经过验证的可行方案，但并不一定是最优，最适合自己所要面对的问题的方案，永远要探索、寻找第三种可能。

架构师其实是个挺苦B的职业，不断面对着问题的挑战，今天听百度，腾讯，淘宝等的架构师演讲，感受颇深，架构师就要在系统遇到瓶颈的时候给出一个漂亮的解决方案，其中有尝试，有失败，有经验，有教训。马化腾之前有说过，研发中最容易犯的一个错误是：研发者往往对自己挖空心思创造出来的产品像对孩子一样珍惜、呵护，认为这是他的心血结晶。好的产品是有灵魂的，优美的设计、技术、运营都能体现背后的理念。有时候开发者设计产品时总觉得越厉害越好，但好产品其实不需要所谓特别厉害的设计或者什么，因为觉得自己特别厉害的人就会故意搞一些体现自己厉害，但用户不需要的东西，那就是舍本逐末了。

在查阅云计算相关资料的时候，发现云计算中有部分内容与我们目前开发的批量调度总线十分相关，例如作业调度也是云计算的关键软件，云计算的作业调度软件一般有以下功能：排队，调度，监控，资源管理以及计费。目前比较流行的开源作业管理有PBS(Portable Batch System), Condor ，商业的比较常见的有IBM的Loadleveler，以及LSF（Load Sharing Facility）。Hadoop的的调度功能，也只是做批量的调度，借鉴了Condor的经验

 

Condor是一个专门用于计算密集型作业的负载管理系统。像其他功能齐全的批处理系统一样，Condor提供了作业排队机制，调度策略，优先计划，资源监测和资源管理。用户提交他们的串行或并行工作给Condor，Condor把他们放到一个队列中，根据某种策略选择时间和地点来执行作业，仔细监测其进展情况，并最终通知用户完成。

 

PBS目前已经变成商业产品，condor目前仍然开源并在持续开发（http://research.cs.wisc.edu/condor/），可以作为我们调度产品的参考。

 

目前Condor等调度系统的调度算法，如常见的FCFS, Backfilling, Gang scheduling 等，大多延续自DQS（Distributed Queung System） ，解决了我们讨论的吞吐量，优先级，分布式排队等问题。其中Backfilling 算法 由于解决了资源碎片问题，显著提高了系统的性能，因此在集群系统中得到了广泛应用。

 

 

另外目前云计算调度规范，比如OGF-OGSA的作业描述语言（JSDL Job Submission and Dscription Language)和作业提交规范（BES Basic Execution Service），对于作业的描述，定义及提交有很好的的标准，其中的很多思路对我们的调度产品参考借鉴意义很大，如果产品最终能支持JDSL以及BES 等开放标准也是后续产品的一个亮点。JDSL和bes可参考附件。

两年前在LFT的时候对公司的线业务部门很纳闷，因为感觉完全与主业不搭边，后来在一个VP的提问时间我提出了这个问题。原来最初创建在线业务部门是想进入SaaS领域。现在想想SaaS很难与现有部署的系统集成，客户定制，数据安全性，性能等都成为发展绕不开的坎。现在它的风头已经完全被云计算盖过了呢。

最近在测试公司研发的调度产品，谈到调度产品变离不开调度，条件管理，排队，资源管理，监控这几个核心功能。调度算法是个难题，如果保证系统有最大的吞吐率，以及保证作业优先级的情况下避免‘饥饿’情况发生。目前我们的调度算法还很不完善，最近在看云计算相关材料的时候才知道有很多开源的像PBS，condor等调度产品，FCFS, Backfilling, Gang scheduling等调度算法，在网上一阵搜索，希望能对现在的产品有点帮助。