• Feeds

  • Archive for January, 2013


    谈分享、创新与开源

    2013来了,又过了一年,以下是元旦假期的一些随想

    分享

    2012写的东西偏少。一方面由于关注的问题相对宏观问题多一点,导致在细节方面能分享的并不多;而大部分宏观问题也跟具体工作相关,不适合分享。宏观领域的粗浅理解容易导致对具体领域的忽视。比如“互联网系统架构近五年技术缺少实质性变化”的断定,会让所有对细节的关注趣味索然,进而也加剧了减少在具体问题上的分享。另外一方面由于工作岗位的原因,需要在管理方面消耗一些精力(当然这些精力投入有它另外的价值),导致专注一个领域研究及阅读时间减少。同时作为一个管理者,需要顾虑未经深思熟虑的表态可能会造成误解,尽管博客只是个人随想的表达,但无法避免被当做一种管理者或者官方的声音去解读。

    以上种种,对于一个习惯写一些东西的人并不是一个非常好的状态,但是这些是未来需要克服的困难。并且在新的一年,也打算关注及分享一些新的技术领域,先留个记号。

    创新

    技术人员创新体现在运用技术来为产品产生更大的价值。比如在大部分开放平台中,用oauth2代替oauth1是一种创新,它在提升安全性的同时,也极大降低了开放平台使用门槛,并间接促使了开放平台领域的进一步繁荣。

    但是,技术人员的大部分群体还是工作仅局限在本职工作上,即怎么样按时按质的完成所分配上的任务,技术上的挑战并不算大。尽管如此,但是在大部分企业中,技术团队往往被视为整体瓶颈之一,比如对产品的质量及细节(包括稳定性、速度、体验等)的把控不足、团队的开发效率不够理想(体现到产品的迭代速度)、技术团队对于行业关键技术的掌握能力偏弱等。比如以上情况目前在移动开发领域比较普遍。而且由于行业由于更新迭代速度快,一些技术团队未能有效掌握所需最新核心技术,而导致产品开发效率变低(对于宏观管理者而言,这些信息通常被掩盖),极端情况下,这些缺乏更新技术方法的人员也可能成为阻碍产品创新的力量。

    对关键技术的把握及是否具备创新思维能力,是衡量当前创新型企业技术团队成熟度的标志。

    谈到团队创新能力,常规的金字塔型团队(即少数能力强的带领一群普通的)未必创新能力很强,也许倒金字塔的更好,一群能力突出的人在一起碰撞会更利于创新。

    今天看到南方周末2012/12/27期一篇文章《城市:创新的天堂》,部分摘录如下

    但是,West最有趣的发现来自那些不遵从“Kleiber定律”的数据。West及其团队发现大量的城市统计背后隐藏着另一个指数法则:所有与创造力和创新能力相关的数据,比如专利产生数、研发预算、超级多产的发明家数量等都遵从同一个指数法则。与“Kleiber定律”不同的是,跟创新有关的指数法则是正相关,而不是负相关。一个城市如果是另外一个城市规模的10倍,那么它的创新能力不只是另外一个城市的10倍,而是17倍。一个城市的规模如果是另外一个城市规模的50倍,那么它的创新能力就将会是另外一个城市的130倍。West的数学模型表明认为创造的城市打破了生物学意义上的生命模式:城市越大,产生思想的能力越强,速度越快,人均产生的专利和发明数量也越多。这就是所谓的“超线性缩放”现象。

    (此文应译自New York Times,A Physicist Solves the City

    开源

    开源社区已经运作多年,行业对于开源运动也都有各自深入的理解。补充一点看法,目前的业界环境下,技术转化为产品再经过运营得到用户认可,是一件门槛相对较高的活,因此对于一个小型团队,如果拥有一些对用户有所帮助的技术,这些技术直接创造价值还是存在一些机会问题,因此通过开源的方式或许可获得另外一种技术产生更大价值的方式。

    微观架构及宏观架构

    大部分工程师包括架构师都是从微观架构起步的。微观架构指在一个局部的领域达到设计及实现的合理性,比如写一个排序的程序,达到时间空间复杂性的合理性,同时在代码的易读性、扩展性及可维护性方面也达到一个合理的标准。但一个系统中不仅只是存在微观问题,宏观架构指一个更高层级的,全局领域的策略及架构设计,通过架构来最终达到对产品或系统在效率、成本上的收益。当系统变大之后,宏观架构的问题更突出,也更能取得收益。比如在一个互联网Web应用中,从微观角度来看,cache命中率自然越高越好,从设计上尽量让访问落在内存上。但是从宏观角度,只要SLA能得到保证,比如让70%的最近数据(可能只占1%容量)能够通过cache访问,而30%长尾数据(可能需要占用99%容量)是通过存储返回,整体开销可能会下降一个数量级,而整体性能也基本有没有大的变化。

    Coding出身的工程师刚脱离微观问题的时候,可能会觉得不习惯。微观的问题容易看到成效,比如将一个程序的QPS性能提升了30%,这是一个容易度量的成绩,而宏观架构看起来很“虚”,也不容易快速产生成效,比如将一个大型传统的系统改造成一个SOA的架构。辛苦花力气改造完成,也不容易看到及度量成效,而且一些隐性的收益需要更长时间才能体现。

    尽管如此,微观架构及宏观架构如同战略及战术一样,是相辅相成的。而且双方都有其重要性,无法判断一个比另外一个重要。微观方面,一个平庸工程师组成的团队,即使一个优秀的架构师从天而降,短期内也无法改变团队的成绩。同样如果技术领导只关注宏观层面问题,忽视代码细节及基本功培养,团队的产品始终难尽人满意。由于宏观架构的设计者通常在组织中拥有更大的话语权,如果对微观的问题缺少一个基本的理解,对微观的出现的矛盾不能做出正确的判断,系统的开发效率及运行效率都会出现问题。宏观方面,一群优秀的工程师,如果能聚集到一个优秀设计架构的平台上,肯定如虎添翼。在一个团队中,宏观架构及微观架构的人员需要达到一个合理的比例。

    以下是以前思考的一些断言,你判断是这些是宏观还是微观架构?

    • The C10k problem refers to the problem of optimising server software to handle a large number of clients at the same time (hence the name C10k – concurrent ten thousand connections). The problem of web server optimisation has been studied because a number of factors must be considered to allow a web server to support many clients. This can involve a combination of operating system constraints and web server software limitations.
    • The goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. Transmission headers are gzip-or DEFLATE-compressed by design. Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page. SPDY可以用作HTTP RPC一个高效替代
    • 普通硬盘的访问延时是SSD的5-500倍
    • 使用event方式事件模型的编程模型可以极大降低线程之间context switch的开销
    • Code review is systematic examination of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase.
    • 在大型系统中,模块之间组合的架构可以看出整体架构的优良及团队效率
    • 移动app方向,未来一段时间仍然主要以产品模式及运营方向主导,技术驱动领域主要集中在快速迭代能力
    • 虽然大数据是以后的一个发展趋势,但是数据挖掘的大部分场景还只是浅层次的应用,系统瓶颈不在挖掘能力,而是在应用能力上