产品之路的随想(社区版) zz

转载于：http://www.iteye.com/topic/651601

   98年从14.4k的modem拨号上网，看到的是网易，邮箱，蓝波BBS，以及痞子蔡的《第一次亲密接触》，这些让我印象非常深刻。当时没能想到web对我的生活和工作产生了这么大的影响。99年开始接触搜索引擎，有位老鸟的话让我记忆犹新：“要把google.com写在手背上，天天能看见”。2000年开始接触php，mysql，linux，apache，一个企业网站能卖5000元，那个时候是个产生泡沫的时代，对我们来说也是个幸福的时光。
在那个年代里，操作系统是windows98，linux还只是勇敢者的工具，广大程序员还热衷于钻研pb、dephi、vb；Web上的开发感觉上还是玩具；仍旧津津乐道于ms的发家史，回味着ms和broland的激烈竞争，至于google，面孔总是一成不变，但它总能返回你检索需要的东西，仿佛是从遥远的地方传来的天籁之音，一切很神秘。

            如果把基于web开发看作一段历史，我和web也逶迤拍拖了10年。如果把Java出生名门的语言叫做大家闺秀，那开源社区推出来的语言就可以称呼为小家碧玉了。大家闺秀和小家碧玉各有风姿，在早期的开发中是各有千秋，一般来说企业应用采取的是java/jsp/ejb等；互联网应用是php/mysql/apache/linux；大家井水不犯河水，各自在自己的领域中用着不同的开发语言。不过随着小家碧玉这几年越发出落得玲珑绰约，大家也争相使用，象spring，hibernate，tomcat都是其中的佼佼者；开发模式也有了极大的改进，从早期model1演变成了随后的model2，再到目前基于框架的快速开发，乃至现在推崇平台开发；工具也从当年的editplus/ ultraedit到后来的jbuilder，直到现在的eclipse一统天下。



图1 model 1模式



图2 model 2模式


        仿佛是一夜春风来，千树万树梨花开，在java诞生15年后，我们处在一个前所未有的面临选择的境地：各种各样的软件工具，框架，平台纷至沓来；银弹/非银弹争论不休，开发方法论孰是孰非皆无定论，此时此刻只有windows net气定神闲，整体解决方案，全套开发工具，所见即所得界面，开发就这么容易，可惜我选择的是Java路线，结果在选型，搭配上花不少的时间，也走了不少的弯路。
一路走来，项目之中的苦与乐在内心中酝酿发酵，如何抽象组件，如何提炼成平台，如何包装产品，也渐渐有了一点感悟和体会。作项目苦，作项目累，留给自己的只有满身的疲惫；在上线的倒计时中，程序员们在疲惫不堪的编写代码调试bug，项目经理们殚精竭虑计算如何上线，不同的部门之间相互扯皮推诿。几年下来，项目还是手工作坊方式，自己没有什么长进。疲惫啊疲惫，不在项目中锤炼，就要在项目中颓废。如何跳出项目的怪圈呢？

            国内的软件公司大体可以分为3类：1作项目；2做作平台/产品，有的公司是兼而有之，以项目养产品；3、做运营。项目导向的公司要做好做强做长久，以下几个步骤是不可缺少的，只是不同的阶段深入的程度有所差异：

1、业务逻辑组件化
2、基础代码框架化
3、开箱即用平台化


1、组件化：
   公司在项目中已经沉淀了这么多年，已经积累了很多可用的业务组件，包括报表展现、ExtJs图形开发，flex页面设计工具，规则引擎，流程引擎等。应用这些组件，在项目实施中减少了开发时间，提高了工作效率。但这些组件分布在不同的部门，大家各用各，甚至还有些敝帚自珍的想法；有的基础组件是你有我有大家有，重复开发。对于这些组件如何甄别和挑选，不浪费本来就很珍贵的人力资源，则在部门之间应该有个通盘考虑。
就算各个组件都汇聚了，如何互联互通，以及在同一个项目内发挥预期作用，这就考验组件的设计方式了。我们的组件基本上都是围绕数据/表来的，涉及一些增删改查以及前端展现，着重要考虑是事务以及组件之间的关联，因为我们的组件是需要被上层更大的组件，或者模块所调用，如果组件对外暴露的是api接口，就不能假设上层应用对组件之间的调用逻辑顺序。

如何设计一个比较通用的组件？有些地方可能需要注意：

1、事务的调用，组件内部不能发起事务的开始，这个权利交给了用户，用户或在client显示申明，或是在spring内部声明。
2、组件可能要使用充血模式而不是贫血模式，即在组件内部中维护自身的数据和状态，并同上层的业务系统的数据同时提交或者同步回滚。
3、组件内部的各个类需要自身来维系，比如工厂模式，多例单例，而不能依靠AOP的能力，否则每集成一个组件，都尾大不掉的带一个spring，彼此之间有影响，项目内部可以使用spring，但在组件级别，类与类的关系得在组件内部考虑。
4、组件要支持多线程环境，要不给方法加入同步，要不给属性加入threadlocal支持
5、组件之间如果都有对数据的持久化处理，建议给表加上锁的方式。比如加上乐观锁，虽然有时候用户提交后会弹出一个窗口提示重新刷新数据，但总比数据不一致的后果要好。



2、框架化：           
   有了这么多的组件，如何把这些组件组装起来，形成有生命力的总体框架呢？组件之间的相互调用如何处理？组件之间的数据交互如何定义？彼此的事务如何传递？
在开源社区提供了一种不错的搭建项目框架的方法：struts+spring+hibernate。当然也有不少其他的方式，不过总体为前端采取mvc模式展现，中间逻辑采取spring的bean装配方式，以及事务申明，后台采取hibernate/ ibatis /jdbc作为持久层，加上其他一些辅助支撑组件，组成了service+dao+orm的方式，前后台通过POJO传递数据（现在也与时俱进了，有用xml和json方式传递数据的）。Serivce采取的是贫血模式，把组件提供的功能当作dao的功能来使用，所以在组件这层面就得考虑组件自身的数据如何与上层业务数据的集成，当只有组件是充血模型方式，才能保证上层业务数据的提交一致性；否则自身组件不维护信息状态，全部持久化到表中，在事务回滚的时刻，就不能保证组件的信息数据也能同步回滚。



         图3传统项目构架方式


     对于多人协同软件，比如大型的OA系统，BOSS系统，有很多业务逻辑是需要多人协同的，前后关联的，并还有些条件分支和判断。当然可以在逻辑中使用硬编码的方式，但做成组件，整个框架会更加灵活，多人协同的逻辑抽象出来，演变成了流程引擎；把条件判断抽象出来，演变成了规则引擎。
      这样在业务逻辑这块再细分为业务逻辑块和流程逻辑层，整个体系架构演化成：表示逻辑、流程逻辑、业务逻辑、数据管理逻辑四种基本逻辑。表示逻辑还是先前的MVC方式；业务逻辑仍然是service+dao，数据管理逻辑依然由ORM负责，或者直接使用JDBC，流程逻辑则有workkfow engine来处理。通过这样的分解，使其中任何一层逻辑的修改都不会影响其它三层，与传统的三层结构相比，将流程逻辑从业务逻辑中显示的抽取出来，形成了相互分离的流程逻辑层和业务逻辑层。从而最大限度的降低系统内部的耦合性，提高系统适应变化的能力。这就是所谓的基于工作流的系统架构。

   

               
                  图4 基于工作流的软件架构

     再加上一些基础设施，比如日志，异常体系，定时调度，远程调用的通用方法，这个框架的羽翼也逐渐丰满，假以时日就能展翅高飞了。
   

      有了组件和框架，其实施的层次还是很低，要编写的代码还是很多，在需求变化的时候，开发人员照样叫苦不迭。而且我们的框架还不灵活，无法应付不同的项目需求。那我们先看看要面对的是哪些项目需求，在摸清对方的要求和套路后，也许就能找到化解的招数。
WEB应用从目前的角度来区分大体分为互联网应用，企业应用，2者的涉众和要求有很大的差别。

 企业应用：包括电子商务系统、企业资源规划、客户关系管理、供应链管理，办公自动化，数据库系统，数据仓库等；需要实现用户交互界面，业务逻辑，外部系统的集成，数据库；涵盖到J2EE的各个方面，包括JSP/Servlet/Java/JMS/Transaction/WebService/XML/ESB/EJB等技术。 可以细分为小企业应用和大中企业应用

1.小企业应用：主要表征是表不多（0~100张表），业务逻辑不复杂，用到的技术也就是页面展现和数据库的方面
2.大中型企业应用：主要表征是表多（200张表以上），业务逻辑复杂，而且涉及到和遗留系统的集成，开发时间长，投入人日多，因为开发费用高，当然也是各软件开发公司的必争项目。


互联网应用：
    包括应用系统：Blog，wiki；网络服务：在线存储，网络磁盘，比较购物； 传统服务：Email,IM，个人主页，新闻信息，门户，论坛，支付网关，商城  ；传统行业：彩票，保险，电子客票，商旅定餐，订票，定杂志，定花；技术上多半采用脚本语言，早期多半用php，现在也有部分应用是在rails上实现。数据库基本采用mysql，架构在linux上，用apache服务器。

1.普通互联网应用：比如有javaeye，itpub，我经常上去逛逛的。它们属于论坛逐渐发展起来的。分别以java为主和以数据库为主的社区，分别是用Rails，php来设计的。目前都从早期简单的论坛发展成了社区，集成了圈子，博客，招聘等应用，并都有了各自的盈利模式。
2.大型互联网应用：典型的有sina，豆瓣网，采取了很多技术来提高页面访问并发量，比如页面静态化，读写分离，分布式缓存系统。但这种技术在企业应用中用的很少，主要是企业用户更加关心的是数据的正确性和一致性。
3.在线运营类型：在线运营只是技术实现方式，还要看上面承载的业务。Google是老大，什么都有，从搜索引擎到gmail、google docs，都是在线应用的典型应用。淘宝专注与电子商务和第3方支付；Amazon.com，专营网上书店；salesforce.com则是最早提出云计算和软件即服务 (SaaS) 的理念（1999年），国内八百客（800APP-PaaS平台），山寨了一把salesforce，目前在国内也算占据了一个山头。SAAS盈利的一种模式就是：用户每个月需要支付类似租金的费用来使用网站上的各种服务，按次或者按时间均可。在后续的章节会继续讨论在线应用。


     现在互联网应用和企业应用有相互渗透的趋势，一些企业把业务系统的一部分搬到互联网上（比如现在淘宝就把电子商务搬到互联网并获得了成功）。

3、平台化
            平台不是框架的简单丰富，给骨架穿上衣服，它也终究是骨骼，没有生命力，只有赋予框架以思想，赋予方法论，框架才有了自己的思想，才有血有肉，有了灵与肉的结合，框架才能跃升为平台，真正指导程序员去开发项目。
            根据平时的接触，能称为平台的包括有：上海普元，上海动量，广州天翎，南京联创（无线部的boss平台，其他事业部的不清楚）。根据这些平台的定位，大致可以分为2类：上海动量和广州天翎面向互联网的；上海普元和南京联创作企业应用的。根据前面对2者的应用分析，下面的表格能大致反映其差异性。

企业应用（表1）：

1	行业领域	区分行业，各自领域业务背景不一样，并形成了一定的门槛。
2	业务逻辑	业务逻辑复杂，涉及大量的数据和多人协同处理。
3	数据一致性	强调数据一致性，需要通过事务，交易中间件，数据库锁，java同步机制来保证数据的一致性。
4	数据复杂度	数据复杂，有大量的表，表之间有复杂的牵涉关系，在某些行业维护这些表之间的关系和数据就需要一个团队。
5	并发量	不是特别大，比如通用应用为100~200并发，重度并发500的系统就能满足国内大部分的系统要求。
6	系统集成	关键系统需要和很多外部系统集成，集成的方式可能采取esb，jms，web service，socket。
7	用户交互	强调界面交互和数据表达，需要支持多种数据展现方式，需要众多数据在页面上的展现，传输
8	开发过程	强调软件过程，讲究行业经验，需要撰写大量的文档和多人的协同，需要版本控制和问题跟踪回溯。

互联网应用（表2）：

1	行业领域	跨行业，按应用类型区分，比如blog，wiki，个人门店等。
2	业务逻辑	业务逻辑简单，大部分是通过页面进行数据的增删改查。
3	数据一致性	要求有事务，但和高并发博弈中，让位给高并发。
4	数据复杂度	数据不复杂，表之间的关联不多
5	并发量	强调高并发，支持用户数量多，强调高速读低速写。
6	系统集成	弱。极少需要和其他系统集成
7	用户交互	弱。交互不多，表现方式简单，更多的是数据的增删改查。
8	开发过程	强调敏捷，快速开发，基本不需要版本控制。

总体来说软件开发的方法论有2种
 敏捷方式：针对互联网应用，强调快速开发，简略一些中间过程，推崇界面（界面原型）即需求。提供界面生成工具，通过代码自动生成工具生成部分逻辑，并提供一些管理工具和管理途径。在项目中使用到了动量（ODE），也接触了天翎（teamlink，myApps），感受了到互联网应用对传统开发模式的冲击，对传统开发模式有了触动。

            动量和天翎都强调界面即需求，简化了传统软件工程中的概要设计和详细设计，并通过一部分的代码自动生成简化了编码工作，但2者的实现方式有所不同。

动量平台提供了基于web的在线编辑页面的方式，并把界面元素生成表结构，因为在动量内部有专门的表来维护用户设计的表结构和关系，所以我们在PD设计的表结构是不能直接导入动量平台，只能通过ODE的界面来生成，并生成标准的增删改查代码，如果有自己特定的逻辑，则需要在ODE中的规则进行扩展，编写一些java代码片断，并提供了一些后台组件和方法和数据库进行交互，部署后由ODE进行编译生成java类代码。因为生成的代码是普通的java代码，并和前台页面有直接的调用关系，所以不支持后台逻辑的分布式部署，在大并发量的情况下只能通过借助应用服务器的集群能力。动量平台架构在很多开源的工具包上，并提供一些企业应用的关键能力，包括事务，包括流程引擎，定时调度，报表展现等，开发人员只要关注界面原型和业务逻辑，提高了生产力。
 天翎同样提供了界面设计的工具，而且他的扩展是通过所谓宏语言（从技术调度分析可能是设计了一些JS的Lib库），在界面设计方面支持拖拽等更灵活方式，表单设计是天翎平台的强项，并提供了基于手机的任务处理途径。通过天翎平台创建表单，最终是生成的jsp，所以不存在ODE有个打包编译部署的过程，发布后刷新既可用，通过这种方式生成的页面，大部分的逻辑写在页面中，同样不能做到后台逻辑分布式部署，也只能通过应用服务器的集群能力来实现大并发的访问。

在大项目不容易接，小项目利润薄的情况下，通过敏捷平台能快速开发一批类似的项目，在广种薄收的季节里，也能聚沙成塔，集腋成裘。另外还有一种方式就是把各种小企业应用抽象出来搭建在云应用（在线支撑运营）上，通过某种租赁方式与众多小企业用户达成使用协议，也就是Saas的理念，在后面的章节会详细讨论。

 重型方法：针对企业应用，以CMM/CMMI 为代表，强调过程受控和里程碑，并通过很多文档和流程来支持。典型的如RUP，4大阶段，9条流程，以及大量的文档模板和在里程碑需要出具的物件，通过这些保证软件过程的可靠有序的执行。
 联创移动事业部的开发方式代表了这种模式，提倡了表驱动的设计理念和前后端分离的开发体系，前端是使用tapestry实现的web展现，中间层应用逻辑搭建在tuxedo服务器之上，并能多台部署，后端是Oracle。Web只能通过调用中间层的服务访问数据，不能直接访问数据库，这样有几个特点：

1.中间服务器层可均衡访问，并通过tuxedo把并发访问削峰填谷，提高系统的健壮性。
2.前端开发和后端开发分离，开发速度快，行业经验能有效固化。在特定的行业应用中，后台服务大体是稳定的，变化的只是前端展现，通过后端服务的编排/编制（提供了可视化工具），能快速提供前端展现所需要的服务，前端人员不需要了解后端逻辑，只需要知道是哪个Api，仅此而已。如果不是这种开发模式，每个省的boss系统不可能在3～6个月内实现（最近2年上的是ngboss，整个后台都发生了变化，云南boss作为试点，前后用了将近1年）
3.数据的安全，所有的数据访问，被限定在有限的通道中，非后台人员无法知道后端表结构和数据。


 另外一个平台是EOS。普元eos从5.0我认为才开始成熟，6.0之后已经更上了一层楼，而且在6.0加入了SCA的体系架构，号称是银弹工具。抛开华丽的包装不说，以程序员的眼光来看，eos提供了一个开发框架和管理平台：开发平台包括了一个web框架，一个流程引擎，并通过可视化工具（涵盖web开发，流程建模，数据库表设计），包括了表设计，详细设计，编码，测试，上线运营，监控管理等软件过程等一系列关键活动，在国内算得上比较成熟的软件平台工具。EOS也是表驱动的设计理念，但界面和业务逻辑没有分离（一般来说，基于SCA能支持后台逻辑的分离部署，但在公司的手机支付平台项目中，没有体现这个特性）。
 从软件开发的角度来说，使用了EOS，多了一套IDE和流程引擎以及类似struts的web开发工具，还有一些底层的工具包。当年eos 6.0端着通用平台的架子来到联创移动事业部，打算能替换就有系统，但据说没有成功。Eos的web如果调用后端的tuxedo服务，自身就退化成了一个web开发工具；eos工作流引擎是本身在管理数据库的流程状态，并和页面的构件有着千丝万缕的调用关系，要符合联创现有的体系，除非重构。就像2位都有思想的人，结合在一起就是有些别扭，要不就要联创移动事业部迁就eos，要不就是eos重构。（eos在联创的其他事业部有应用，比如联通）。
 另外有个例子，amdocs china（朗新），承接湖北电信boss时候，当时没有现有的平台，采用的框架是struts1＋spring1.＋hibernate2/jdbc ，工作流引擎是用存储过程写的，从05年到07年，人最多的时候达到了200多人，开发和上线时间比较长。


      根据对企业应用和互联网应用的特点进行分析，以及在理解和把握国内业界先进的平台思想体系，我们开发部也提出了自有的业务基础平台，业务基础平台包括业务开发工具和软件开发框架，其中业务开发平台提供了流程建模器，FlexUI的界面设计器，以及将来提供的规则设计器；软件开发框架分为5层，自下而上分别是数据访问层，基础业务层，领域业务层，编程接口层，界面交互层。



                    图5 业务基础平台总体框架


    开发方法论和联创的大体类似，并借鉴了动量的Web界面快速生成的思想以及管理模块的概念，提出了我们特有的方法论。开发团队分为前后端，前端web开发人员调用后端服务设计人员编写的开放业务编程接口（OBPI）；在需要多台后台逻辑服务器的情况下，采取通用远程调用接口（URCI）的方式部署。前端界面采取FlexUI快速设计界面；后端逻辑采取表驱动方式设计，并依托工具生成基本的增删改查代码，前端展现和后台通过接口（OBPI）的方式进行绑定，这种方式即有利于行业软件的自身积累，也能在互联网应用中快速开发。该部分内容在《xx业务基础平台可行性研究报告》中有详细说明，这里不详细阐述。


           图6 基于软件开发框架的开发步骤

    由此可见，要在国内的软件行业站稳脚跟，要有自己所占据的行业领域，以及对行业领域的独有了解。正如鲁迅所倡导，不但要拿来，还要改造，打造出符合公司需要、公司理念的平台。自此才深刻了解为什么这几年在不断的引进上海普元，上海动量，广州天翎，以及到上海博科去学习。师夷长技以制夷，通过走出去，请进来的方式，学习业界先进的思想和理念，并加以山寨、改进、超越，符合公司独有文化，特定领域的需求，才能立于不败之地，否则我们就只能在项目的泥泞中挣扎彷徨。与其在项目泥潭中怨天尤人、放逐自我还是奋发雄起、积极进取，在学习借鉴把握业界先进平台的同时打造自有的公司级的平台，则是我们程序员对待软件的一种态度和追求。




4、云应用           
     互联网应用和企业应用虽然都属于web应用，但面向的涉众不一致导致设计思想和开发模式有很大的区别。就像我们在描述大自然的现象，宏观层面使用广义相对论，但在微观层面使用哥本哈根的量子学说。本来是井水不犯河水，大家都相安无事，但如果要解释宇宙起源的那一刻，是用相对论还是用量子学说？当企业应用发布到互联网，为广大的普通涉众提供服务，我们是采用什么方法论呢？再往前推进一步，如果推广公司的大规模的在线应用，我们打算如何构造呢？我们的组件，我们的框架，我们的平台能承担这个重担吗？

需要在线运营平台吗
      其实在线运营平台的应用和我们息息相关：google，能在浩如烟海的资料中能快速定位我需要的内容；QQ，能让我找到老婆；淘宝，能买到物美价廉的物品；上amazon买几本原装进口的书；上sourceforge.net/google code下载开源的软件。。。我们的工作和生活已经离不开这些平台应用，国内一些类似的在线运营公司，比如百度，腾讯，淘宝，都在各自的领域中称霸一方。腾讯QQ在前不久已经超过了1亿的在线用户数，这是十分惊人的数量，这么大的用户数保证了腾讯山寨后就能把对手远远的抛在后面。比如QQ农场，1个月有5千万的进账。

 在线运营平台能带来变化
     如果观察这些在线应用，愿意支付费用的大概有3种类型的人，商家，玩家，买家。企业用户愿意购买竞价排序的关键字；玩家愿意买狗粮买化肥；买家愿意通过支付宝购买物品。有了众多网友的鼎力支持，这些企业也赚的盆满钵满。
   潮涨潮落，花开花谢，Borland 消失了；sun/weblogic 投靠了oracle；novell不做netware，转而支撑linux了；IBM不纯卖软件了，推崇服务了；微软不单单只卖office，windows了，也开始推bing，Azure等在线应用了；google的界面还是一如既往的这样清纯淡雅。。。纷纷扰扰，当年辉煌的产品成了明日黄花，传奇的故事已经烟消云散，但能从中把握一个这样的讯息，辉煌了一时，不会长久一世，只有贴近广大用户的需要，即用户所想，提供用户所需，才能永葆青春。
            如何贴近用户？如何把应用推送到用户手上？通过互联网，把应用搭建在互联网上。“衣不如新，人不如故”，人总是有惰性的，用户使用习惯后自然就产生一种黏性效应，比如我从来只上google不上baidu；只在QQ农场偷菜，从不去开心农场。当然了，我从不购买狗粮，QQ农场中的5千万的收入收入中没有我的贡献。
 如何设计在线运营平台       
     微软认为，未来的互联网世界将会是“云+端”的组合，在这个以“云”为中心的世界里，用户可以便捷地使用各种终端设备访问云中的数据和应用，这些设备可以是电脑和手机，甚至是电视等大家熟悉的各种电子产品，同时用户在使用各种设备访问云中的服务时，得到的是相同的无缝体验。云计算这种全新的IT即服务模式可以提供无可比拟的经济效益。而从技术因素来看，主要得益于多种关键技术的驱动，如互联网技术、廉价硬件的普及和提升、分布式计算技术的进步、技术标准的统一、虚拟化技术等等。
    淘宝在08年就达到在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户八千万的大型电子商务网站，淘宝用的是JBoss，框架是iBATIS，缓存服务器是自己开发的，基本遵循SNA架构，水平扩展，数据库是Oracle，阿里集团的DBA几乎是国内最强悍的，整个淘宝系统是建立在2万台服务器之上（具体数目应该有变化）。目前系统已经达到了当前体系架构的极限，据说淘宝的系统架构正在重构，计划用两到三年时间重写，目标有两个：1、水平扩展已经不满足需求了，还需要水平加垂直扩展 2、开放API，让店家可以把外部网站资源集成到淘宝，不必直接在淘宝开店。如果是这样的话，淘宝不单单想把自己做成saas，占据国内电子商务的nunber one，还要打造成PAAS，为各种应用提供支撑。
虽然我很喜欢老婆在淘宝上给我买的衣服，但我对淘宝的下一代系统架构更感兴趣。如果说淘宝的下一代架构体系的秘密装在一个盒子里，当打开这个盒子，我们能看到什么呢？――我猜是“大象”；）
            大象是《hadoop The Definitive Guide》这本书的封面照片，同时也意味着我们将来构造的在线运营系统是搭建在“大象”之上，庄重，沉稳，健壮，鲁棒。从网上有限的资源中，能看到淘宝有个技术团队在研究hadoop，hive，CloudBASE，而且他们最近写的文章是2010-04-14日，描述的是《hive优化》的内容，相应的某些岗位在招聘熟悉hadoop+hive的程序员。历史的车轮在飞速前进，IT行业是日新月异，国内先进的互联网应用公司已经是磨刀霍霍准备大举进入，而我们也在枕戈待旦，蓄势待发。
            Hadoop是Apache开源组织的一个分布式计算开源框架，在很多大型网站上都已经得到了应用，如亚马逊、Facebook和Yahoo等，有资料说百度和腾讯，网易也在部分的项目中使用了hadoop。说道hadoop，不得不提google，正是google无私的提供了几篇论文，google整体庞大的体系才解开冰山一角，才有机会从google冰清玉洁的外表去感触她的具有深邃内涵的精神世界。Google数据中心使用廉价的Linux PC机组成集群，在上面运行各种应用。核心组件是3个：1、GFS：分布式文件系统，2、MapReduce，运算处理机制3、BigTable，大型分布式数据库。同样，Hadoop框架中最核心的设计就是：MapReduce和HDFS，并可以选择使用hive或者是hbaes作分布式数据库。

            前面所叙的小企业应用，可以采用类似动量或者天翎的敏捷平台去各个用户现场快速开发部署，但我认为更好的方式是创建公司的云应用，数据统一维护，统一升级和管理。
            玩家被腾讯宠着，买家被淘宝拢着，商家大家都争破脑袋去抢夺着，剩下的就是口袋里没有多少银子的小企业用户，大家都不搭理着。从公司的长久发展考虑，他们应该是我们最要去关心的人，一个可行的方式是在云上搭建“非关键企业数据的应用”，这种应用不涉及企业的核心应用，属于企业应用的外围应用，比如在线日历，在线记账，在线工作周报等，这些小企业用户容易接受并有可能愿意在互联网的方式下进行尝试，而且这种需求应该比较大，因为很多企业都或多或少的会用到类似的产品，而且在用户数量达到了一定的规模，通过云的基础设施提供某些服务能力，把各个不同用户的页面，数据按照一定的业务逻辑进行关联，并能以合适的时间、合适的方式给用户呈现，形成一种所谓的在线企业用户生态链。如果公司能和众多的在线企业用户形成休戚与共的关系，那就在互联网的浪潮中完成了华丽的转变，并在某个特定的应用领域走在这个时代的前列。


            滴水可映日，一叶可知秋。当我们在回顾web的开发历史，其实也就是展望web应用的未来。产品的成长之路悠远而漫长，有时又可能泥泞难以前行，但我们既然找到方向，就朝着这方向努力，既然找到了目标，就朝这目标前进，因为我们坚信：没有比脚更长的路，没有比人更高的山。