产品运营：淘宝技术发展

　　在系统发展的过程中，架构师的眼光至关重要，作为程序员，把功能实现即可，但作为架构师，要考虑系统的扩展性、重用性，这种敏锐的感觉，课课家听有人说是一种代码洁癖。淘宝早期有几个架构师具备了这种感觉。一指开发的Webx是一个扩展性很强的框架，行癫在这个框架上插入了数据分库路由的模块、session框架等等。在做淘宝后台系统的时候，同样需要这几个产品模块，行癫指导我把这些模块单独打成了jar包。另外在做淘宝机票、彩票系统的时候，页面端也有很多东西需要复用，最直观的是页头和页脚，一开始我们每个系统里面复制了一份过去，但奇妙的是，那段时间页脚要经常修改，例如把“雅虎中国”改成“中国雅虎”，过一段时间又加了一个“口碑网”，再过一段时间变成了“雅虎口碑”，最后又变成了“中国雅虎”，每个系统都改一遍，折腾啊。后来我就把这部分velocity模版单独拿出来了，做成了公用的模块。
　　上面这些都是比较小的复用模块，到2006年我们做了一个商品类目属性的改造，在类目里面引入属性的概念。项目的代号叫做“泰山”，如同它的名字，这是一个举足轻重的项目，这个改变是一个划时代的创新。在这之前的三年时间内，商品的分类都是按照树状的一级一级的节点来分的，随着商品数量的增长，类目也变得越来越深，越来越复杂，这带给买家的就是查找一件商品要逐级类目点开，找商品之前要懂商品的分类。而淘宝运营部门管理类目的小二也发现一个很严重的问题——例如男装里面有T恤、T恤下面有耐克、耐克有纯棉的，女装里面也有T恤、T恤下面还是有耐克、耐克下面依然有纯棉的，那是先分男女装再分款式再分品牌再分材质呢?还是先分品牌再分款式再分材质再分男女呢?晕倒了。这时候，一位大侠出来了——一灯，他说品牌、款式、材质这种东东可以叫做“属性”，属性是类似tag的一个概念，与类目相比更加离散，更加灵活，这样也缩减了类目的深度。这个思想的提出，一举解决了分类的难题!从系统的角度来看，我们建立了“属性”这样一个数据结构，由于除了类目的子节点有属性，父节点也有可能有属性，于是类目属性合起来也是一个结构化的数据对象。这个做出来之后我们把它独立出来作为一个服务，叫做catserver(category server)。跟类目属性密切关联的商品搜索功能，独立出来，叫做hesper(金星)，catserver和hesper供淘宝的前后台系统调用。
　　现在淘宝的商品类目属性已经是地球上最大的了，几乎没有什么类目的商品在淘宝上找不到(除了违禁的)，但最初类目属性改造完之后，我们很缺属性数据，尤其是数码类的最缺。那从哪里弄这些数据呢亲?我们跟“中关村在线”合作，拿到了很多数据，那个时候，很多商品属性信息的后边标注着：“来自中关村在线”。有了类目属性，给运营的工作带来很大的便利，我们知道淘宝的运营主要就是类目的运营，什么季节推什么商品，都要在类目属性上面做调整，让买家更容易找到。例如夏天我要用户在女装一级类目下就标出来材质是不是蕾丝的、是不是纯棉的，冬天却要把羽绒衣调到女装一级类目下，流行什么就要把什么商品往更高级的类目调整。这样类目和属性要经常调整，随之而来的问题就显现了——调整到哪个类目，那类商品的卖家就要编辑一次自己的商品，随着商品量的增长，卖家的工作量越来越大，然后我们就发现卖家受不了啦。到了2008年，我们研究了超市里面前后台商品的分类，发现超市前台商品可以随季节和关联来调整摆放场景(例如著名的啤酒和尿布的关联)，后台仓库里面要按照自然类目来存储，二者密切关联却又相互分开。然后我们就把前后台类目分开了，这样卖家发布商品选择的是自然类目和属性，淘宝前台展示的是根据运营需要而摆放的商品的类目和属性。改造后的类目属性服务取名叫做forest(森林，跟类目属性有点神似。catserver还在，提供卖家授权、品牌服务、关键词等相关的服务)。类目属性的服务化，是淘宝在系统服务化方面做的第一个探索。
　　虽然个别架构师具备了代码洁癖，但淘宝前台系统的业务量和代码量还是爆炸式的增长了起来。业务方总在后面催，开发人员不够了就继续招人，招来的人根本看不懂原来的业务，只好摸索着在“合适的地方”加一些“合适的代码”，看看运行起来像那么回事，就发布上线了。在这样的恶性循环中，系统越来越臃肿，业务的耦合性越来越高，开发的效率越来越低。借用当时比较流行的一句话“写一段代码，编译一下能通过，半个小时就过去了;编译一下没通过，半天就过去了。”在这种情况下，系统出错的概率也逐步增长，常常是你改了商品相关的某些代码，发现交易出问题了，甚至你改了论坛上的某些代码，旺旺出问题了。这让开发人员苦不堪言，而业务方还认为这帮人干活越来越慢了。
　　大概是在2007年底的时候，研发部空降了一位从硅谷来的高管，空闻大师。空闻是一位温厚的长者，他告诉我们一切要以稳定为中心，所有影响系统稳定的因素都要解决掉。例如每做一个日常修改，都必须整个系统回归测试一遍;多个日常修改如果放在一个版本里面，要是一个功能没有测试通过，整个系统都不能发布。我们把这个叫做“火车模型”，任何一个乘客没有上车，都不许发车。这样做的最直接后果就是火车一直晚点，新功能上线更慢了，我们能明显的感觉到业务方的不满，空闻的压力肯定非常大。当时我都不理解这种一刀切的做法，为了稳定牺牲了发展的速度，这跟某Party的“稳定压倒一切”有什么分别?
　　但是到现在回过头来看看，其实我们并没有理解背后的思路。正是在这种要求下，我们不得不开始改变一些东西，例如把回归测试日常化，每天晚上都跑一遍整个系统的回归。还有就是在这种要求下，我们不得不对这个超级复杂的系统做肢解和重构，其中复用性最高的一个模块——用户信息模块开始拆分出来了，我们叫它UIC(user information center)。在UIC里面，它只处理最基础的用户信息操作，例如getUserById、getUserByName等等。
　　well产品是指能够提供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。产品一般可以分为三个层次，即核心产品、形式产品、延伸产品。核心产品是指整体产品提供给购买者的直接利益和效用;形式产品是指产品在市场上出现的物质实体外形，包括产品的品质、特征、造型、商标和包装等;延伸产品是指整体产品提供给顾客的一系列附加利益，包括运送、安装、维修、保证等在消费领域给予消费者的好处。
　　产品是“一组将输入转化为输出的相互关联或相互作用的活动”的结果，即“过程”的结果。在经济领域中，通常也可理解为组织制造的任何制品或制品的组合。在现代汉语词典当中的解释为“生产出来的物品”
　　在另外一个方面，还有两个新兴的业务，也对系统基础功能的拆分提出了要求。在那个时候，我们做了淘宝开店教程视频和淘宝彩票两个新业务，这两个新业务在商品的展示和交易的流程上都跟主站的业务不一样，机票是按照航班的信息展示的，彩票是按照双色球、数字和足球的赛程来展示的。但用到的会员的功能和交易的功能是跟主站差不多的，当时做的时候就很纠结，在主站里面做的话，会有一大半跟主站无关的东西，重新做一个的话，会有很多重复建设。最终我们决定不再给主站添乱了，就另起炉灶做了两个新的业务系统。从查询商品、购买商品、评价反馈、查看订单这一整个流程都重新写了一套出来。现在在“我的淘宝”里面查看交易记录的时候，还能发现“已买到的宝贝”里面把机票和彩票另外列出来了，他们没有加入到普通的订单里面去。在当时如果已经把会员、交易、商品、评价这些模块拆分出来，就不用什么都重做一遍了。

　　其中UIC和Forest上文说过，TC、IC、SC分别是交易中心(Trade Center)、商品中心(Item Center)、店铺中心(Shop Center)，这些中心级别的服务只提供原子级的业务逻辑，如根据ID查找商品、创建交易、减少库存等操作。再往上一层是业务系统TM(Trade Manager交易业务)、IM(Item Manager商品业务)、SM(Shop Manager，因为不好听，所以后来改名叫SS：Shop System，店铺业务)、Detail(商品详情)。
　　拆分之后，系统之间的交互关系变得非常复杂，示意图如下：

　　系统这么拆分的话，好处显而易见，拆分之后每个系统可以单独部署，运营简单，方便扩容;有大量可重用的模块以便于开发新的业务;能够做到专人专事，让技术人员更加专注于某一个领域。课课家觉得这样要解决的问题也很明显，分拆之后，系统之间还是必须要打交道的，越往底层的系统，调用它的客户方越多，这就要求底层的系统必须具有超大规模的容量和非常高的可用性。另外，拆分之后的系统如何通讯?这里需要两种中间件系统，一种是实时调用的中间件(淘宝的HSF，高性能服务框架)、一种是异步消息通知的中间件(淘宝的Notify)。另外还有一个需要解决的问题是用户在A系统登录了，到B系统的时候，用户的登录信息怎么保存?这又涉及到一个Session框架。再者，还有一个软件工程方面的问题，这么多层的一套系统，怎么去测试它?