合肥企业网站seo,网站环境配置,wordpress产品页面静态化,福州网站建设福州站建设本文是《淘宝网的技术发展史》系列连载文的第三篇。在系统发展的过程中#xff0c;架构师的眼光至关重要#xff0c;作为程序员#xff0c;把功能实现即可#xff1b;但作为架构师#xff0c;要考虑系统的扩展性、复用性#xff0c;这种敏锐的感觉#xff0c;有人说是一… 本文是《淘宝网的技术发展史》系列连载文的第三篇。在系统发展的过程中架构师的眼光至关重要作为程序员把功能实现即可但作为架构师要考虑系统的扩展性、复用性这种敏锐的感觉有人说是一种代码洁癖。 文/淘宝技术大学培训专家 子柳 在做淘宝机票、彩票系统的时候页面端也有很多东西需要复用最直观的是页头和页脚。一开始我们每个系统里面复制了一份过去但奇妙的是那段时间页脚要经常修改例如把“雅虎中国”改成“中国雅虎”过一段时间又加了一个“口碑网”再过一段时间变成了“雅虎口碑”最后又变成了“中国雅虎”。后来我就把这部分velocity模板单独拿出来了做成了公用的模块。 类目属性服务化 上面这些都是比较小的复用模块到2006年我们做了一个商品类目属性的改造在类目里面引入属性的概念。项目的代号叫做“泰山”。如同它的名字这是一个举足轻重的项目这个改变是一个划时代的创新。 在这之前的三年时间内商品的分类都是按照树状的一级一级的节点来分的随着商品数量的增长类目也变得越来越深、越来越复杂这使得买家找一件商品要逐级类目点开找商品之前要懂商品的分类。 而淘宝运营部门管理类目的小二也发现一个很严重的问题——例如男装里面有T恤、T恤下面有耐克、耐克有纯棉的女装里面也有T恤、T恤下面还是有耐克、耐克下面依然有纯棉的那是先分男女装再分款式再分品牌再分材质还是先分品牌再分款式再分材质再分男女呢 这时候一位大侠——一灯出来了他说品牌、款式、材质这种东东可以叫做“属性”属性是类似tag的一个概念与类目相比更加离散更加灵活这样也缩减了类目的深度。这个思想的提出一举解决了分类的难题从系统的角度来看我们建立了“属性”这样一个数据结构由于除了类目的子节点有属性父节点也可能有属性于是类目属性合起来也是一个结构化的数据对象。这个做出来之后我们把它独立出来作为一个服务叫做catservercategory server。跟类目属性密切关联的商品搜索功能也独立出来叫做hesper金星。catserver和hesper供淘宝的前后台系统调用。 现在几乎没有什么类目的商品在淘宝上找不到除了违禁的但最初类目属性改造完之后我们很缺属性数据尤其是数码类的数据最缺。那从哪里弄这些数据呢我们跟“中关村在线”合作拿到了很多数据那个时候很多商品属性信息的后边都标注着“来自中关村在线”。有了类目属性给运营的工作带来很大的便利。我们知道淘宝的运营主要就是类目的运营什么季节推什么商品都要在类目属性上做调整让买家更容易找到。例如夏天我要用户在女装一级类目下就标出来材质是不是蕾丝的、是不是纯棉的而冬天就要把羽绒衣调到女装一级类目下流行什么就要把什么商品往更高级的类目调整。 这样类目和属性要经常调整问题就随之而来了——调整到哪个类目那类商品的卖家就要编辑一次自己的商品随着商品量的增长卖家的工作量越来越大然后我们就发现卖家受不了了。 到了2008年我们研究了超市前后台商品的分类发现超市前台商品可以随季节和关联度来调整摆放场景例如著名的啤酒和尿布的关联后台仓库要按照自然类目来存储二者密切关联却又相互分开。然后我们就也把前后台类目分开了这样卖家发布商品选择的是自然类目和属性淘宝前台展示的是根据运营需要而摆放的商品的类目和属性。改造后的类目属性服务取名叫做forest森林跟类目属性有点神似。catserver还在提供卖家授权、品牌服务、关键词等相关的服务。类目属性的服务化是淘宝在系统服务化方面做的第一个探索。 虽然个别架构师具备了代码洁癖但淘宝前台系统的业务量和代码量还是爆炸式地增长了起来。业务方总在后面催开发人员不够了就继续招人招来的人根本看不懂原来的业务只好摸索着在“合适的地方”加一些“合适的代码”看看运行起来像那么回事就发布上线了。在这样的恶性循环中系统越来越臃肿业务的耦合性越来越高开发的效率越来越低。在这种情况下系统出错的概率也逐步增长常常是你改了商品相关的某些代码发现交易出问题了甚至你改了论坛上的某些代码旺旺出问题了。这让开发人员苦不堪言而业务方还认为这帮人干活越来越慢了。 以稳定为中心 大概是在2007年底的时候研发部空降了一位从硅谷来的高管——空闻大师。他告诉我们一切要以稳定为中心所有影响系统稳定的因素都要解决掉。例如每做一个日常修改都必须整个系统回归测试一遍多个日常修改如果放在一个版本里面要是一个功能没有测试通过整个系统都不能发布。我们把这个叫做“火车模型”任何一个乘客没有上车都不许发车。这样做的最直接后果就是火车一直晚点新功能上线更慢了我们能明显地感觉到业务方的不满空闻的压力肯定非常大。当时我都不理解这种一刀切的做法为了稳定牺牲了发展的速度。 但是到现在回过头来看看其实我们并没有理解背后的思路。正是在这种要求下我们不得不开始改变一些东西例如把回归测试日常化每天晚上都跑一遍整个系统的回归。还有就是在这种要求下我们不得不对这个超级复杂的系统做肢解和重构其中复用性最高的一个模块——用户信息模块开始拆分出来了我们叫它UICuser information center。在UIC里面它只处理最基础的用户信息操作例如getUserById、getUserByName等等。 另外一方面还有两个新兴的业务也对系统基础功能的拆分提出了要求。在那个时候我们做了淘宝旅行trip.taobao.com和淘宝彩票caipiao.taobao.com两个新业务这两个新业务在商品的展示和交易的流程上都跟主站的业务不一样机票是按照航班的信息展示的彩票是按照双色球、数字和足球的赛程来展示的。但用到的会员的功能和交易的功能是跟主站差不多的当时做的时候就很纠结在主站里面做的话会有一大半跟主站无关的东西重新做一个的话会有很多重复建设。 最终我们决定不再给主站添乱了就另起炉灶做了两个新的业务系统。从查询商品、购买商品到 评价反馈、查看订单这一整个流程都重新写了一套出来。现在在“我的淘宝”里面查看交易记录的时候还能发现“已买到的宝贝”里面把机票和彩票另外列出来了它们没有加入到普通的订单里面去。在当时如果已经把会员、交易、商品、评价这些模块拆分出来就不用什么都重做一遍了。 拆分核心模块 到2008年初整个主站系统有了机票、彩票系统之后把原来的系统叫做主站的容量已经到了瓶颈商品数在一亿以上PV在2.5亿以上会员数超过了五千万。这个时候Oracle的连接池数量都不够用了数据库的容量到了极限上层系统再增加机器也无法继续扩容了我们只有把底层的基础服务继续拆分从底层开始扩容上层才能扩展这才能容纳以后三五年的增长。 于是那一年我们专门启动了一个更大的项目把交易这个核心业务模块也拆分出来了。原来的淘宝交易除了跟商品管理耦合在一起也在支付宝和淘宝之间跳来跳去跟支付宝耦合在一起系统复杂用户体验也很不好。我们把交易的底层业务拆出来叫交易中心TCtrade center所谓底层业务是例如创建订单、减库存、修改订单状态等原子型的操作交易的上层业务叫交易管理TMtrade manager例如拍下一件普通商品要对订单、库存、物流进行操作拍下虚拟商品不需要对物流进行操作这些在TM里面完成。这个项目取了一个很没有创意的名字——“千岛湖”这帮开发人员取这个名字的目的是想在开发完毕之后去千岛湖玩一圈后来他们如愿以偿了。这个时候还有一个项目也在搞就是淘宝商城之前拆分出来的那些基础服务给商城的快速构建提供了良好的基础。 类目属性、用户中心、交易中心随着这些模块逐步地拆分和服务化改造我们在系统架构方面也积累了不少的经验。到2008年底干脆做了一个更大的项目把淘宝所有的业务都模块化这是继2004年从LAMP架构到Java架构之后的第二次脱胎换骨。这个项目取了一个很霸气的名字叫“五彩石”女娲炼石补天用的石头。这个系统重构的工作非常惊险有人称之为“给一架高速飞行的飞机换发动机”。 “五彩石”项目发布之后这帮工程师去三亚玩了几天。他们把淘宝的系统拆分成了如下架构 其中UIC和forest上文说过TC、IC、SC分别是交易中心trade center、商品中心item center、店铺中心shop center这些中心级别的服务只提供原子级的业务逻辑如根据ID查找商品、创建交易、减少库存等操作。再往上一层是业务系统TMtrade manager交易业务、IMitem manager商品业务、SMshop manager因为不好听所以后来改名叫SS即shop system店铺业务、Detail商品详情。 拆分之后系统之间的交互关系变得非常复杂如图2所示。 拆分之后每个系统可以单独部署业务简单方便扩容有大量可重用的模块以便于开发新的业务能够做到专人专事让技术人员更加专注于某一个领域。这样要解决的问题也很明显分拆之后系统之间还是必须要打交道的越往底层的系统调用它的客户方越多这就要求底层的系统必须具有超大规模的容量和非常高的可用性。 另外拆分之后的系统如何通讯这里需要两种中间件系统一种是实时调用的中间件淘宝的HSF高性能服务框架、一种是异步消息通知的中间件淘宝的Notify。另外还有一个需要解决的问题是用户在A系统登录了到B系统的时候用户的登录信息怎么保存这又涉及一个session框架。再者还有一个软件工程方面的问题这么多层的一套系统怎么去测试它这些问题在后来的发展中都进行了解决。 http://i.wshang.com/?p22930
