博客园_蓝色的天空，朵朵的白云

信息时代下，如何看待技术与理论

2012-05-07T01:49:00Z

12306春运时的瘫痪距离我们并不是很远，或许我们还在为京东的618的抢购页面无法打开而感到懊恼。好像突然之间电子化的信息如汪洋大海一般充斥到我们的每一个空间，考验着我们的系统。于是分布式的概念深入人心。我们在不断的引入新技术：redis，NoSql，dubbo，hadoop……。

然而我们的改变似乎很缓慢，并不是所有急需改造的系统都能借分布式的东风摇身一变轻松的脱胎换骨，这里面有很多的原因，主要的有：

l 新技术本身的问题如成熟性、学习成本等，

l 应用本身的特殊性。如为提高性能需要在分布式系统上提供本地缓存，而不是Redis。

l 多个应用在数据库层面上耦合。

l 应用内部结构复杂，在引入分布式思路后，使得原先逻辑的复杂性可能会难以接受。如，原先的事务性模型需要彻底废弃，于是开始头大！

也许我们的系统非常幸运，顺利的进入到了分布式系统行列了。然而这有可能在更大的浪费资源。因为“分布”没有从根本上脱离“集中”的内涵！它只是用“技术”的方式在内部实现了物理的分布，但对外还是以一个逻辑“整体”出现的。

举一个例子，假设有一家优秀的B2C公司，在中国市场上因业务的膨胀，现将订单进行了分布式存储，且公司决定开展国际业务。假设国际业务未来几年发展的不错，此时我们的分布式的订单库拥有了海量数据记为M。那么每个顾客的订单记为N，则每个顾客的数据占比为N/M，也就是说，每个顾客在操作自己的数据时，其实就是在大海捞针。

虽然分布式通过哈希来避免了“大海捞针”。但如果M越大，则效率会越低，且M越大，哈希表也就越大，如果哈希表足够大会不会带来问题呢？可能的方案可能是多级哈希，然而hadoop支持多级哈希吗？假设支持，所有顾客操作的叠加将会有多少资源花费在哈希上？这些花费真的是不可避免吗？

因为对外还是一个逻辑整体，是集中的，所以所有的订单业务，不管是中国还是美国的，都会像一棵树一样在接入点进行汇集。而国际业务对网络资源的耗费及用户体验将是一个疑问？但愿我是杞人忧天了。

在这个层面上分布式存储已经无能为力了。当面对这个问题时，我们很自然的想到用多棵树来解决，这需要进行某种层面的分割——系统自治。此时订单数据被封装到自治系统中，打破了逻辑上的整体性，自治系统间的订单数据交换需要通过额外的接口来完成，当然数据量及频度将非常，非常……非常的小，我估计或许平均每天小于N/M。

这里的多个功能相同的“自治”系统也是一种分布式，一种系统级的分布式，只是现有的分布式框架绝对提供不了业务系统的“自治”。其实每个“自治”系统就是类的多个实例，但这里更强调“自治”，只有“自治”的系统才能将一个大任务进行“放心”的分解，而OOP中的封装已经包含这个精神了。在前期文章中我还讲到高内聚和低耦合，如果一个系统做不到高内聚，其实也就谈不到自治了。

现在“云”计算被广为关注，说实在的我看的不太明白，对外应该也是一个逻辑整体，所以它也有接入点流量限制的问题。也就是说，以一个商家建立的“一朵云”不能解决全部问题，只有国际性组织才有这个潜力！不过可以肯定的是“云”使系统的部署变得简单。

无论外部的技术框架有多好，有多么方便，但它解决的只能是我们业务系统中的某几个点，我们可以把它当成砖块垒在我们的系统中，但不可以作为“基因”来决定系统的命运。让理论指导实践，要比技术应用于实践具有更深层次的价值！

本文链接

狼的架构暗示

2012-04-26T01:12:00Z

接前文：狼群的架构暗示

目前人类已经发明了机器人，深蓝也演绎了与人类的对决，这揭示了人类对信息的掌控的范围与能力已经非常强大。但如果我们利用现有技术制造一批机器狼，让它们参加集体围猎行动或个体捕杀活动，我并不表示乐观。

之所以有这个比较，旨在说明作为自然生物的狼在处理信息的多样性、综合性、复杂性上有着杰出的表现。如果狼是个信息处理系统，如此强劲的信息处理能力是如何架设的呢？他的架设原则又是什么呢?

大自然无所不包，无所不容。生活在其中的生物必须对纷杂的信息进行及时、准确的处理，否则将难以生存。然而面对庞大、繁杂的信息，狼却只有少数的器官进行信息的采集与处理：眼睛、耳朵、鼻子、大脑……。狼的眼睛可以看到你在用望远镜看它，狼的鼻子可以嗅到夹子及周围环境遗留下的人的气味，狼的耳朵生长在身体的最高部位。狼将自然界的信息进行了分类，使每一个感觉器官都能独当一面，而且都非常精密和专业。所有这些都彰显了狼身体构造的高内聚的特征。

生物学告诉我们，身体上的各个器官都与血液循环系统打交道，以从中获取养分并排除代谢物。神经系统则负责信息的传递。现在我们再来看狼的这些感觉器官和大脑，是否都以这两个系统为根本？这是不是一种松耦合的表示？

狼的身体器官还有很多，但概没有跑出其架构原则：高内聚，低耦合。那么为什么会有这样的原则呢？——适应环境。举个例子，如果看红、蓝、绿分别需要一只眼睛，各种气味都需要一个鼻子……，如此下去，狼的身体要大，消耗要大，捕猎能力将严重降低，所以畸形狼命运很悲惨！

我们的软件要适应环境，我们的架构思想就必须是适应环境的。我很惊叹于狼对信息的处理能力，但更震惊于人类已经生活与信息化时代！

本文链接

狼群的架构暗示

2012-04-23T01:35:00Z

接前文：基因与架构

《狼图腾》的作者吕嘉民中说狼除了美人计外《孙子兵法》上的技法基本上都会用，不但会打战术战还会打战略战。我们不管狼与狼之间使用了多么复杂的沟通技术，来实现这些难以想象的群体活动，我们来关注一下沟通的信息传输过程。在这个模型中存在３个对象：狼、信息、环境。首先狼产生信息并能够消费信息；其次狼所产出的信息可以游离于狼身体之外而存在并传输，既信息不是狼身体的一部分；最后是环境，它是信息的载体，狼的信息产生后不是直接进入对方的身体，而是先附加到大自然这个载体，然后传递给其他的狼，对方最后再从环境载体中拾取对自己“有用”的信息。

这使我想起软件设计的一条准则“高内聚、低耦合”。狼的个体是一个高度智能化、功能强劲、高度自治、独立存在的信息处理系统，这是高内聚的体现。狼与狼之间通过借助于“大自然”这个廉价、开放、通用、高可用的环境将谁都可以理解的且独立于狼身体之外的松散的“数据”进行交互，这种只和“大自然”耦合的方式是一种松耦合的典范。

狼为了自身的存活，不断强化自身的功能，并充分利用开放的环境资源，不断融入到环境中去，不断完善体外信息的沟通机制，来进一步提升狼群的整体生存能力。而这种进化行为在生物界举不胜举，这是否预示着“上天”这个架构师的第一架构法则是高内聚、低耦合呢？如果成立，那么软件的生存能力和生存空间就看高内聚、低耦合的水平了。

本文链接

基因与架构

2012-04-10T01:18:00Z

上接由“I”到“T”

树的分叉是由基因控制的，我不清楚不同树种之间的基因差别，但据资料报到人类的基因图谱与大猩猩的差别仅仅为0.03%。而就是这么小的差异却造就了截然不同的物种，无论从形态还是生存环境都大相径庭。于是我惊异于大自然的架构能力，只需要做小小的改变就能创造五彩缤纷的生物世界！

基因其实就是大自然的设计思想，这个设计思想以适应环境的生存能力为动力，在漫漫的历史长河中不断的精雕细琢，不断的变化与完善。其生命周期何其长久，其生命力何其强大！大自然的架构能力让人敬畏，让人拜服。当然这里的生命周期和生命力不是一个独立生命个体来表示的，而是整个物种不断进化的阐述。

一个业务系统是否长命，是否能够长成参天大树，能否形成“T”，就要看业务系统的基因如何了。如果只是为了当前项目需要而进行的架构，那么他的生命周期及生命力也就局限于项目范围内了。当外部环境一发生变化，其生存可能性将受到很大的挑战，很有可能会成为“恐龙”。

一个好的业务系统（尤其是具有品牌性质的产品）不是一个项目可以搞定的，得需要多个项目的迭代与完善，我们也不能期望一开始就有一个出色的架构。但如果前一个项目的精华不能得以延伸和雕琢，而只是机械的串在一起。那么这个业务系统将失去灵魂，并机械的运转着，直至遇到瓶颈或被替代。

其实精华部分按理来讲应该非常小，非常简单，非常精密，非常强大。体积的小就像DNA占细胞的体积，非常简单就像DNA的排列形式，非常精密就像DNA的生物特性的浓缩，非常强大就像DNA的控制能力。如果一个系统里找不出这样的东西，那么系统将像一个拥有多个“大脑”的生物，将产生控制混乱，其命运可想而知。

本文链接

由“I”到“T”

2012-04-09T02:19:00Z

接前产品的臃肿过程

看到过一篇有关“通才”与“专才”的文章，里面提到两个字母很有特色。通才用“T”来表示，专才用“I”来表示。“T”是由“I”转变来的，即先在某一领域内成为专家后，才能渗透到其他领域。

其实这个过程可以延伸到业务发展层面和软件开发层面。对于一个业务来讲，我们必须在一条线上打通他，做强他，这时我们可以用“I”的不断变长变粗来表示。精明的决策者，不会满足于既得利益，他会去发掘“I”的潜在支撑能力，他会思考能否利用现有资源服务于更多的领域。于是就像一个小芽觉得能够撑起两片叶子的时候，叶子和主干便形成了一个“T”。对于一个大型的复杂的业务系统来讲，也存在类似的情景。主干和侧枝便形成了一个“T”，但侧枝又会有自己的未成形的“I”和成形的T。所以一颗树的成长过程，形象的代表了一个大型应用系统的发展过程。

本文链接

产品的臃肿过程

2012-03-08T01:16:00Z

当面对一个需求时，产品人员会在完成时间与资源投入上与研发人员进行“谈判”，有时要么威胁，要么悬赏。产品人员关注的是系统可以做这事，可以做那事（以后可以做）；而研发人员则为了自身利益着想则是想先把这事做了再说，于是两者便很快达成协议。至少在这一刻，研发人员只能聚焦到一个点上，因为单纯做一件事简单，所以重实现轻设计的恶习被养成！我已经遇到好多已经快编完码才迫于形势（质量要求）来参加设计评审的事情了。

随着时间的推移，我们的产品便由这些大都是“临时”或“应急”的项目拼凑而成，于是我们的应用系统便越来越庞大而臃肿。庞大可以理解，但臃肿是我们无法接受的。臃肿发展到一定程度，会严重影响效率，制约着业务进一步发展。我们在不停的增加机器，不停的更换性能更高的服务器。然而这不是通用的解决方案，有时候我们对现有系统已经不能在做什么了，于是“架构升级”便被提到日程上来了。这是个自然规律，我们的业务系统也需要“进化”。然而就像生物界的“进化”一样，有些物种被替代了，而有些则变得更加强大。“替代”的代价是巨大的！这意味着先前的投入被历史所埋葬，遗留价值渺小甚至没有。

我不得不承认目前国内的一流的B2C公司就是以这样的方式支撑着如此巨大的业务，并且有的以每年200~300%的速度在发展。他们的业绩非常的漂亮，但有多少人知道多少研发人员度过了多少个不眠之夜？这些公司技术大都落后于业务半拍或一怕甚至是瓶颈问题！小一点的公司因为业务量的问题，可能没有那么严重，但其技术实力我是不那么乐观的。

这是不是说明我们的技术很被动的呢？技术服从于业务我很认可，但技术永远跟在业务后面跑我不认同！

本文链接

我们是在开发产品还是项目？

2012-03-03T03:35:00Z

产品是一种实物还是一种需要满足？

这里我先引用一下GB/T19000――2008《质量管理体系基础和术语》里的两个概念：

产品 product：过程的结果

项目 project：由一组有起止日期的、协调和受控的活动组成的独特过程，该过程要达到符合包括时间、成本和资源约束条件在内的规定要求的目标

由上看出，产品必定产生于项目，但项目不一定会产生产品。我本人对这个概念不是很满意；举一个例子:微软为Windows产品建立了许多个项目，即产品也会产生项目。其实上面的定义是没有错的！产品是过程的结果，指的是已经具体化的实物，如Windows98；但后面的Windows产品则指的是具有Windows血统的系列内容，既包括已经实现的，也包括未实现的，与人的“某些”需要更为贴近，而这种需要可由Windows98或Windows X来满足，是一种“长期”的需要。

我不想混淆概念，只是在这里要说明一下我们将要讨论的“产品”指的是长期满足某方面需求而不断发展完善的产品。

我们是在开发产品还是项目？

“进化”是产品的最大特点。就像自然物种的进化一样，在经过长期的历史检验所保留下来的产品必然会有着优良的基因及顽强的适应能力。项目自身是没有进化而言的，他的价值只能用产品来体现，产品的进化必须由一系列“紧密相关而优雅精巧”的项目来推动的。

所以项目开发自然而然地占据了我们绝大多数的工作内容和工作时间，我们的绩效也会直接与项目挂钩。为了效益的最大化，每个人都想多做项目且尽快实现项目。这让我们的项目有些目光短浅，只考虑当前利益，而不愿为潜在的问题多付出代价，同时也因为这些潜在的问题可能会获得下一次立项的机会，从而增加我们的收入。这种硬性的工作方式时间长了，产品会“进化”得臃肿、复杂、难以维护。更可悲的是产品人员即使知道潜在的问题，大多数情况下也不能做合理的决定，因为产品人员是发散的。

本文链接

未来电子商务，未来的超市

2011-03-14T05:05:00Z

电子商务的物流瓶颈分析

电子商务已经有10多年的历史了，尤其是近几年电子商务得到迅猛的发展，现在网购已被普通大众所接受。电商们在提供了“足不出户”的购物体验的同时，也为这种“便捷性”付出了沉重的代价。目前自提与送货上门的比率个人估计很低，因此电商需要强大的物流体系来支撑，这同时也占据了电商的大量资金投入，电商到目前还没有赢利与此是息息相关。2011年春节前的配送压力更是突显物流环节的薄弱。

为了适应这种局面，很多人认为在未来几年物流行业就大有作为。然而本人持有谨慎乐观的态度。

每个配送人员的配送能力是有限的，每人每天也就100单左右吧，这已经是很高的强度了，当订单量增加时，电商必须成比例的增加配送人员。因为劳动强度比较高，市场上目前这方面的就业人员相对偏少，致使工资普遍偏高。不难看出配送队伍的建设是电商比较头痛的事情。

就送货速度来讲，目前的物流布局也很难有质的突破，目前京东可以在部分地区做到211限时达，已经很不容易。问题在哪呢？消费者下单后，库房的生产还是比较快的，但需要批量出库，这里有等待的时间；然后送到配送点，这里有运输时间；然后再由配送员送货上门，这里有运输时间。即问题出在一个等待出库和两个运输的时间上。

传统零售给我们的启示

生活中当我们的“油盐酱醋”一有需求时，我们会在很短的时间内就可以从社区超市里买到。那么电子商务的“自提点”是否也可以像社区超市这样群星密布呢？为此我从电商和消费者两个方面做了一下分析。

首先我们以“客户为先”。

l 人不能老是蜗居在家里，当有购物需要时先在家里的电脑上下单或走在路上用手机下单，等走到“自提点”时，那里已经准备好了。既健了身，也顺便把事情给办了，比超市还方便。

l 现在的城市人生活节奏紧张，白天忙工作，周末有活动。不要紧，下班坐在车上用手机下单，下车不用绕路，到自家社区下的“自提点”把货提回家就好。

l 对于重一点，大一点的东西，老人不方便自己提回家，下单后配送员可以从社区“自提点”出发，10分钟20分钟的就送上来了。就像桶装水一样耽误不了使用。

我们再来看一下电商。

l 一个配送员一天最多100来单，再高了上不去，而“自提点”一个柜台2小时可按少了说可满足100单。

l 节省了配送的支出，配送员在路上的费用是一种非常严重的浪费。从统计的角度讲配送员重复了消费者回家的路线。

l 当然社区“自提点”也需要投资的，但我个人认为这个投资很划算

n 这种投资并没有被消费，它扩大了电商的库房面积，可以容纳更多的货物。

n 可以让供应商将常用物品直接送到社区“自提点”，不用送到“中央库房”再调拨到社区“自提点”。从而进一步节省物流成本，并提高库房周转率。这对于保质期短的商品来讲尤其重要。

n 分散“中央库房”的捡货任务量，一些订单，或一部分订单可以直接在社区“自提点”进行生产。大大提高订单生产吞吐率。

n 因为货物直接可以给消费者，可以减少因配送监管而附加的包装费及监管环节。从而少了难以监管的配送环节。

l 社区“自提点”的员工劳动强度不高。男女比例合理，对社会环境要求小（容易找到员工），工资也不高。

l 潜在的用户群体巨大，老大爷、老大妈将大量成为电商的会员。

l 电商可以放心地进行有偿配送的策略，而不用担心影响到单量。

从上面的分析来看，电商如果实现“自提点”社区化，将可甩掉“配送”这一沉重的包袱。同时能够更好的提供购物快捷性。

未来电商的社区“自提点”

要实现“自提点”的社区化，是一个很复杂的过程，不可能一朝一夕能完成的。供应链的结构形式，商品品类的丰富程度，及库存管理系统的完善程序等都会影响到社区“自提点”的运行效果。

社区“自提点”要想非常流畅的运行还需要一些配套措施，如会员卡及其附属卡的实物发放。同时还需要一些新的流程，如消费者提供就像办理银行业务一样，刷会à等待à叫号à提货。

其实现在超市里除了不规范的散货外，电商应该都可以进行操作，当社区“自提点”真的做到降低物流费用的时候，我们有理由相信，商品的价格将会进一步降低。那时电商将是超市的有力挑战者。

本文链接

创业期的软件开发管理(二)

2008-11-18T00:58:00Z

本文从多个角度分析软件开发过程在创业时期所遇到的问题及给出一些个人的解决方法。这是我的新身经历，这些方法不一定会适合读者，也一定是好的方法。作为一个创业团队的技术带头人，分析问题的角度或深度可能会有一定的局限性。写下此文权当交流。目录如下：创业环境管理层核心资金人力资源软件队伍技术主管需求文档软件设计软件资源的整合绩效

创业期的软件开发管理(一)

2008-11-17T01:21:00Z