产品之路的随想(完整图文版)


产品之路的随想 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 者的涉众和要求有很大的差别。 z 企业应用:包括电子商务系统、企业资源规划、客户关系管理、供应链管理,办公自动化,数据 库系统,数据仓库等;需要实现用户交互界面,业务逻辑,外部系统的集成,数据库;涵盖到 J2EE 的各个方面,包括 JSP/Servlet/Java/JMS/Transaction/WebService/XML/ESB/EJB 等技术。 可以细分 为小企业应用和大中企业应用 1. 小企业应用:主要表征是表不多(0~100 张表),业务逻辑不复杂,用到的技术也就是页面展 现和数据库的方面 2. 大中型企业应用:主要表征是表多(200 张表以上),业务逻辑复杂,而且涉及到和遗留系统 的集成,开发时间长,投入人日多,因为开发费用高,当然也是各软件开发公司的必争项目。 z 互联网应用:包括应用系统: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 行业 领域 区分行业,各自领域业务背景不一样, 并形成了一定的门槛。 跨行业,按应用类型区分,比如 blog,wiki, 个人门店等。 2 业务 逻辑 业务逻辑复杂,涉及大量的数据和多人 协同处理。 业务逻辑简单,大部分是通过页面进行数据 的增删改查。 3 数据 一致性 强调数据一致性,需要通过事务,交易 中间件,数据库锁,java 同步机制来保 证数据的一致性。 要求有事务,但和高并发博弈中,让位给高 并发。 4 数据 复杂度 数据复杂,有大量的表,表之间有复杂 的牵涉关系,在某些行业维护这些表之 间的关系和数据就需要一个团队。 数据不复杂,表之间的关联不多 5 并发量 不是特别大,比如通用应用为 100~200 并发,重度并发 500 的系统就能满足国 内大部分的系统要求。 强调高并发,支持用户数量多,采取特殊的 技术,比如 web 反向代理,memcache,表 的垂直分隔、水平分隔,强调高速读低速写。 支持百万用户。 6 系统 集成 关键系统需要和很多外部系统集成,集 成的方式可能采取 esb,jms,web service, socket。 弱。极少需要和其他系统集成 7 用户 交互 强调界面交互和数据表达,需要支持多 种数据展现方式,需要众多数据在页面 上的展现,传输 弱。交互不多,表现方式简单,更多的是数 据的增删改查。 8 开发 过程 强调软件过程,讲究行业经验,需要撰 写大量的文档和多人协同,需要版本控 制和问题跟踪。 强调敏捷,快速开发,基本不需要版本控制。 总体来说软件开发的方法论有 2 种 z 敏捷方式:针对互联网应用,强调快速开发,简略一些中间过程,推崇界面(界面原型)即需求。 提供界面生成工具,通过代码自动生成工具生成部分逻辑,并提供一些管理工具和管理途径。在 项目中使用到了动量(ODE),也接触了天翎(teamlink,myApps),感受了到互联网应用对传统 开发模式的冲击,对传统开发模式有了触动。 动量和天翎都强调界面即需求,简化了传统软件工程中的概要设计和详细设计,并通过一部 分的代码自动生成简化了编码工作,但 2 者的实现方式有所不同。 9 动量平台提供了基于 web 的在线编辑页面的方式,并把界面元素生成表结构,因为在动量内 部有专门的表来维护用户设计的表结构和关系,所以我们在 PD 设计的表结构是不能直接导 入动量平台,只能通过 ODE 的界面来生成,并生成标准的增删改查代码,如果有自己特定 的逻辑,则需要在 ODE 中的规则进行扩展,编写一些 java 代码片断,并提供了一些后台组 件和方法和数据库进行交互,部署后由 ODE 进行编译生成 java 类代码。因为生成的代码是 普通的 java 代码,并和前台页面有直接的调用关系,所以不支持后台逻辑的分布式部署,在 大并发量的情况下只能通过借助应用服务器的集群能力。动量平台架构在很多开源的工具包 上,并提供一些企业应用的关键能力,包括事务,包括流程引擎,定时调度,报表展现等, 开发人员只要关注界面原型和业务逻辑,提高了生产力。 9 天翎同样提供了界面设计的工具,而且他的扩展是通过所谓宏语言(从技术调度分析可能是 设计了一些 JS 的 Lib 库),在界面设计方面支持拖拽等更灵活方式,表单设计是天翎平台的 强项,并提供了基于手机的任务处理途径。通过天翎平台创建表单,最终是生成的 jsp,所 以不存在 ODE 有个打包编译部署的过程,发布后刷新既可用,通过这种方式生成的页面, 大部分的逻辑写在页面中,同样不能做到后台逻辑分布式部署,也只能通过应用服务器的集 群能力来实现大并发的访问。 在大项目不容易接,小项目利润薄的情况下,通过敏捷平台能快速开发一批类似的项目,在广种 薄收的季节里,也能聚沙成塔,集腋成裘。另外还有一种方式就是把各种小企业应用抽象出来搭建在 云应用(在线支撑运营)上,通过某种租赁方式与众多小企业用户达成使用协议,也就是 Saas 的理念, 在后面的章节会详细讨论。 z 重型方法:针对企业应用,以 CMM/CMMI 为代表,强调过程受控和里程碑,并通过很多文档和 流程来支持。典型的如 RUP,4 大阶段,9 条流程,以及大量的文档模板和在里程碑需要出具的 物件,通过这些保证软件过程的可靠有序的执行。 9 联创移动事业部的开发方式代表了这种模式,提倡了表驱动的设计理念和前后端分离的开发 体系,前端是使用 tapestry 实现的 web 展现,中间层应用逻辑搭建在 tuxedo 服务器之上,并 能多台部署,后端是 Oracle。Web 只能通过调用中间层的服务访问数据,不能直接访问数据 库,这样有几个特点: 1. 中间服务器层可均衡访问,并通过 tuxedo 把并发访问削峰填谷,提高系统的健壮性。 2. 前端开发和后端开发分离,开发速度快,行业经验能有效固化。在特定的行业应用中, 后台服务大体是稳定的,变化的只是前端展现,通过后端服务的编排/编制(提供了可视 化工具),能快速提供前端展现所需要的服务,前端人员不需要了解后端逻辑,只需要 知道是哪个 Api,仅此而已。如果不是这种开发模式,每个省的 boss 系统不可能在 3~6 个月内实现(最近 2 年上的是 ngboss,整个后台都发生了变化,云南 boss 作为试点,前 后用了将近 1 年) 3. 数据的安全,所有的数据访问,被限定在有限的通道中,非后台人员无法知道后端表结 构和数据。 9 另外一个平台是 EOS。普元 eos 从 5.0 我认为才开始成熟,6.0 之后已经更上了一层楼,而且 在 6.0 加入了 SCA 的体系架构,号称是银弹工具。抛开华丽的包装不说,以程序员的眼光来 看,eos 提供了一个开发框架和管理平台:开发平台包括了一个 web 框架,一个流程引擎, 并通过可视化工具(涵盖 web 开发,流程建模,数据库表设计),包括了表设计,详细设计, 编码,测试,上线运营,监控管理等软件过程等一系列关键活动,在国内算得上比较成熟的 软件平台工具。EOS 也是表驱动的设计理念,但界面和业务逻辑没有分离(一般来说,基于 SCA 能支持后台逻辑的分离部署,但在公司的手机支付平台项目中,没有体现这个特性)。 9 从软件开发的角度来说,使用了 EOS,多了一套 IDE 和流程引擎以及类似 struts 的 web 开发 工具,还有一些底层的工具包。当年 eos 6.0 端着通用平台的架子来到联创移动事业部,打算 能替换就有系统,但据说没有成功。Eos 的 web 如果调用后端的 tuxedo 服务,自身就退化成 了一个 web 开发工具;eos 工作流引擎是本身在管理数据库的流程状态,并和页面的构件有 着千丝万缕的调用关系,要符合联创现有的体系,除非重构。就像 2 位都有思想的人,结合 在一起就是有些别扭,要不就要联创移动事业部迁就 eos,要不就是 eos 重构。(eos 在联创 的其他事业部有应用,比如联通)。 9 另外有个例子,amdocs china(朗新),承接湖北电信 boss 时候,当时没有现有的平台,采用 的框架是 struts1+spring1.+hibernate2/jdbc ,工作流引擎是用存储过程写的,从 05 年到 07 年,人最多的时候达到了 200 多人,开发和上线时间比较长。 根据对企业应用和互联网应用的特点进行分析,以及在理解和把握国内业界先进的平台思想体系,我 们开发部也提出了自有的业务基础平台,业务基础平台包括业务开发工具和软件开发框架,其中业务开发 平台提供了流程建模器,FlexUI 的界面设计器,以及将来提供的规则设计器;软件开发框架分为 5 层,自 下而上分别是数据访问层,基础业务层,领域业务层,编程接口层,界面交互层。 OBPI / UDBIUNetI UDAO WEB WAP Eclipse Myeclipse boss vgop CP URCI http/jms/mina/webservice/esb/ejb/wtc/rmi/ftp API 图 5 业务基础平台总体框架 开发方法论和联创的大体类似,并借鉴了动量的 Web 界面快速生成的思想以及管理模块的概念,提出 了我们特有的方法论。开发团队分为前后端,前端 web 开发人员调用后端服务设计人员编写的开放业务编 程接口(OBPI);在需要多台后台逻辑服务器的情况下,采取通用远程调用接口(URCI)的方式部署。前 端界面采取 FlexUI 快速设计界面;后端逻辑采取表驱动方式设计,并依托工具生成基本的增删改查代码, 前端展现和后台通过接口(OBPI)的方式进行绑定,这种方式即有利于行业软件的自身积累,也能在互联 网应用中快速开发。该部分内容在《拓维业务基础平台可行性研究报告》中有详细说明,这里不详细阐述。 图 6 基于软件开发框架的开发步骤 由此可见,要在国内的软件行业站稳脚跟,要有自己所占据的行业领域,以及对行业领域的独有了解。 正如鲁迅所倡导,不但要拿来,还要改造,打造出符合公司需要、公司理念的平台。自此才深刻了解为什 么这几年在不断的引进上海普元,上海动量,广州天翎,以及到上海博科去学习。师夷长技以制夷,通过 走出去,请进来的方式,学习业界先进的思想和理念,并加以山寨、改进、超越,符合公司独有文化,特 定领域的需求,才能立于不败之地,否则我们就只能在项目的泥泞中挣扎彷徨。与其在项目泥潭中怨天尤 人、放逐自我还是奋发雄起、积极进取,在学习借鉴把握业界先进平台的同时打造自有的公司级的平台, 则是我们拓维人对待软件的一种态度和追求。 4、云应用 互联网应用和企业应用虽然都属于 web 应用,但面向的涉众不一致导致设计思想和开发模式有很大的 区别。就像我们在描述大自然的现象,宏观层面使用广义相对论,但在微观层面使用哥本哈根的量子学说。 本来是井水不犯河水,大家都相安无事,但如果要解释宇宙起源的那一刻,是用相对论还是用量子学说? 当企业应用发布到互联网,为广大的普通涉众提供服务,我们是采用什么方法论呢?再往前推进一步,如 果推广公司的大规模的在线应用,我们打算如何构造呢?我们的组件,我们的框架,我们的平台能承担这 个重担吗? z 需要在线运营平台吗 其实在线运营平台的应用和我们息息相关:google,能在浩如烟海的资料中能快速定位我需要的 内容;QQ,能让我找到老婆;淘宝,能买到物美价廉的物品;上 amazon 买几本原装进口的书;上 sourceforge.net/google code 下载开源的软件。。。我们的工作和生活已经离不开这些平台应用,国内一 些类似的在线运营公司,比如百度,腾讯,淘宝,都在各自的领域中称霸一方。腾讯 QQ 在前不久已 经超过了 1 亿的在线用户数,这是十分惊人的数量,这么大的用户数保证了腾讯山寨后就能把对手远 远的抛在后面。比如 QQ 农场,1 个月有 5 千万的进账。 z 在线运营平台能带来变化 如果观察这些在线应用,愿意支付费用的大概有 3 种类型的人,商家,玩家,买家。企业用户愿 意购买竞价排序的关键字;玩家愿意买狗粮买化肥;买家愿意通过支付宝购买物品。有了众多网友的 鼎力支持,这些企业也赚的盆满钵满。 潮涨潮落,花开花谢,Borland 消失了;sun/weblogic 投靠了 oracle;novell 不做 netware,转而 支撑 linux 了;IBM 不纯卖软件了,推崇服务了;微软不单单只卖 office,windows 了,也开始推 bing, Azure 等在线应用了;google 的界面还是一如既往的这样清纯淡雅。。。纷纷扰扰,当年辉煌的产品成 了明日黄花,传奇的故事已经烟消云散,但能从中把握一个这样的讯息,辉煌了一时,不会长久一世, 只有贴近广大用户的需要,即用户所想,提供用户所需,才能永葆青春。 如何贴近用户?如何把应用推送到用户手上?通过互联网,把应用搭建在互联网上。“衣不如新, 人不如故”,人总是有惰性的,用户使用习惯后自然就产生一种黏性效应,比如我从来只上 google 不 上 baidu;只在 QQ 农场偷菜,从不去开心农场。当然了,我从不购买狗粮,QQ 农场中的 5 千万的收 入收入中没有我的贡献。 z 如何设计在线运营平台 微软认为,未来的互联网世界将会是“云+端”的组合,在这个以“云”为中心的世界里,用户 可以便捷地使用各种终端设备访问云中的数据和应用,这些设备可以是电脑和手机,甚至是电视等大 家熟悉的各种电子产品,同时用户在使用各种设备访问云中的服务时,得到的是相同的无缝体验。云 计算这种全新的 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 应用的未来。产品的 成长之路悠远而漫长,有时又可能泥泞难以前行,但我们既然找到方向,就朝着这方向努力,既然找到了 目标,就朝这目标前进,因为我们坚信:没有比脚更长的路,没有比人更高的山。
还剩8页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

timeson

贡献于2011-10-22

下载需要 15 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf