电子商务的

提要：跨国B2C链接中国工厂和西方家庭，打通全球零售的全链条

原发自 FT中文网

分两部分说吧，先说事，后说人。

事情是这样的。

12月10日，阿里巴巴发放了互联网史上最大的一次性分红：11亿港币。但名博Keso立刻在微博里批注：“微软首次分红是08年，这时微软已上市22年，股价几乎不再增长。”其实阿里的股票至今未涨。07年上市发行价13.5港元，目前是13.3。这三年收入和利润一直涨，但股价和市值不增反跌。意思是：收入不会一直涨下去。快到头了吧。

资本市场和江湖上都在说同一个法：阿里模式过时了。B2B阿里是中国供应商和海外采购商的中间信息桥梁，但也仅仅是一个信息桥梁。马云常说的电子商务三个流：信息流、资金流、物流，只占了一个。05年敦煌网起步，信息和资金流一起做，不仅管撮合还管收钱，要围猎革阿里。后来阿里做AliExpress也管收钱，有力的反击敦煌。

但信息流和资金流都“轻”，也就是都可以线上解决，这对阿里没有伤筋动骨的影响。只有当把物流这个“重”的一环也纳入，才会令老的B2B有窒息般的失重感。更关键一点是，B2B链接供应商和采购商，它们都是B，有大者更大、大者衡大的趋势。中间商容易被绕开。但若直接链接多如牛毛的工厂和消费者做跨国B2C，高枕无忧。

10月底参加在无锡举办的中国物联网大会，德同资本的邵俊在饭桌上不断给我灌输一个理念：别老看着国内B2C火红，跨国B2C，那可是利润相当的厚、猫腻相当的多！邵大哥一连推介了好几个风生水起的跨国B2C的名字，都没听说过。后面一阵研究，记住了两个最大的：LightInTheBox（兰亭序，缩写LT）和DinoDirect（大龙网，缩写DD）。

做跨国B2C的同学都相当的低调。原因有五：第一，瞄的是海外消费者，在中国高调没啥实际用处。第二，利润相当的厚，别把狼群招来。第三，要打通从中国工厂到西方家庭的整个链条，供应链相当复杂、流程相当繁复、西方百姓相当难搞定等等，没三五年难成气候。第四，这事明摆着是冲着革B2B命去的。第五，牵涉到绕开关税等等大问题。

所以，都是“小心为上”。

只看见LT的同学在微博上说圣诞前夕忙得那叫一个痛快，我却始终没能敲开LT的门。创始人郭去疾同学过于深居浅出、讳莫如深。不见客！不过所幸还是婉转搞定了DD的创始人冯剑峰。这位爷把公司开在远离北上广的重庆，一年前拿了阿里巴巴前CTO吴炯的天使投资和北极光1000万美金A轮融资。感恩节+圣诞节，订单暴涨。

冯剑峰同学一口气把跨国零售的商业逻辑补全了。请仔细听题：

传统外贸有6个环节：1中国的工厂——2中国的出口商——3外国的进口商——4外国的批发商——5外国的零售商——6家庭消费者。阿里巴巴B2B链接了从2到3的两个环节，也链接了一部分从1到4个的四个环节。但跨国B2C直接链接了从1和6的整个环节。

传统B2B无法改变中国制造以量大价廉取胜、所获利润却非常之低的一贯悲剧。高利润都被外国批发和零售商赚取，低物价造福于外国消费者。中国越制造，欧美越富裕。而如果中国工厂直接把商品卖给西方消费者，他们会赚得更多，西方家庭得的实惠也更多。举个例子，深圳产的平板电脑成本300块，取200%利润才900块约145美金。美国人当这是白捡。

问题是：为什么阿里巴巴不做？这也是两年前冯剑峰问阿里巴巴一个副总裁的问题。他对得到的回答并不惊讶：因为流程太长了。那下一个问题是：为什么是这两年开始有公司能把这一套做出来了？冯剑峰的回答是：天时和地利都成熟了。我们来看一下2009到2010两年间发生的事情：

物流是跨国B2C最难的部分。尤其零售，把一个个包裹递送到家庭里去，不是传统大宗物流所能实现的，专业术语是最近几年才兴起的“社会化物流”。但随着Ebay、Amazon、淘宝们的不懈努力，海外代购的摸索，物流成本大幅降低，据说目前EMS等快递公司的递送成本是之前几年的1/3到1/2。现在，物流成本只占到跨国B2C售价的18%。

下一个是跨国在线支付。这归因于PayPal的兴起。不用多说。

接下来是两个宏观环境。西方的金融危机让老百姓更加重视价廉物美的商品，我们都听到了美国感恩节购物时居然发生踩踏伤人的新闻了，老外为了抢便宜货也照样瞎来。同时中国的出口压力无法消化多余的产能，中国的工厂找不到买家。海关的数据，去年我国制造业出口比前年下降16%，出口价格下跌近6%。这就对了，一边是西方家庭要便宜货，一边是中国工厂卖不出去。

上面的问题都准备好了。但如何找到西方消费者？倒回去三五年，到CNN、沃尔玛超市或者雅虎上打广告？这似乎太贵。阿里巴巴就砸钱在西方电视上打过广告，不过那是在它上市圈钱之后，也是为了抵御敦煌等新军进攻的权宜之计。好在现在的中国B2C们有了两样低廉而精准的武器：Google和Facebook。

LT创始人郭去疾之前是Google中国的战略总监，所以不难理解LT主要通过Google和搜索引擎优化寻找西方消费者。花几毛钱就能找到几个买家，这是一个持续的稳当的推广方式。DD的冯剑峰则相当不屑于这一套，因为满大街的人都懂这个，竞价排名和搜索引擎优化已经是红海一片。可用，但不划算。

冯同学瞄的是Facebook。他认为今年是做社交网络广告的最佳时机。Facebook超Google成最大网站，但广告很少，没几个人懂。就像03年是做搜索广告最佳时机，那时Google崛起但也没人懂，大家都在瞄雅虎的门户广告。在地球人都搞懂社交网络广告之前，就是先驱们可以利用的时间窗口。社交广告的优点：好的内容本身就是广告。一个搜索广告只带来一次销售，但一个社交广告还能带来口碑。

用数字说话。DD的流量转化为订单的比率是4%，而据说行业的一般转化率不到1%。DD搞定一个新订单的成本是10美金，而据说，行业的一般成本是20-30美金。这带来强大的扩充优势：只有价高的商品才能支撑30美金的成本，而10美金的成本就可以覆盖到价低的商品，而大量价低的商品运作又进一步加速选品的能力、数据库的扩充、需求的分析、物流的打磨、质检的流程等等环节。是的，知道你会问下一个问题：这些数据怎么实现的？到底怎么在Facebook上做广告？是不是也需要在其它社交网站配合？这个嘛，还是给冯同学留点秘密。

至于剩下的其它问题都似乎不算问题了。如何找到优质生产商？防止盗版等法律风险？寻找到西方百姓喜欢的商品？一句话解释：站在巨人的肩膀上。淘宝、阿里、eBay、亚马逊积累的太多优质数据，做了太多基础工作，看它们公开的那些数据就够了。所以，谢谢它们。没有爷们苦哈哈的八年抗战，2010年的LT和DD都不存在。

所以，当物流、支付、推广、消费者、生产商都准备好了。有什么理由跨国B2C不做起来呢？请记住，这里面的利润相当之高，LT做婚纱的，一个女人一生买一次，用脚指头想都知道里面多少油水。也请记住，这是中国制造在海外打出品牌的一个好机会。DD已经帮助一个做户外运动手电筒的制造商在美国注册了FireDragon商标，它们打算大干一票了。

事说得差不多了。接下来，我们到下半部分：说说人。

当冯剑峰回答了第一个问题“跨国B2C为什么是这两年起来”之后，轮到我最感兴趣的下一个问题：“这个事情为什么是你来做？”天才冒出灵感火花这种事，我不信。而唯一的正解应该是：什么样的经历、积累以及秉性让你正巧站在那个冒油的地方。请注意，跨国B2C跟阿里B2B的最大不同是：它伸向了西方家庭，并涉足供应链。这是个节点。

郭去疾同学和冯剑峰同学。不巧都有相似的两点：绝对的海归，老早就与B2C有染。是的，无巧不成书。姻缘天注定。

郭去疾是从Google中国战略总监任上离职创办LT的。他是94级中国科技大学少年班毕业生，之后赴美获得伊利诺大学电子工程硕士学位及斯坦福大学MBA学位。去Google前供职于微软和Amazon。请注意，Amazon，全球B2C的龙头老大。所以郭去疾干这个事情基本是水到渠成：知道西方家庭要什么，熟悉Amazon的供应链，再精通Google的广告系统和搜索引擎优化。

冯剑峰大学毕业后依次去了四个国家生活、工作、和创业：日本、新加坡、加拿大、美国。中国的东西在4个国家卖4个价钱，他印象深刻。02年做了DigitalRiver和GlobalShareWare两个网站，把俄罗斯人写的软件卖给欧美人。那几年，此类网站排前三的头两个都是冯同学做的，第三是雅虎。顶峰时每月的成交金额是300万美金；至于利润，自己去想。是的，这就是冯同学所第一次经历的跨国B2C，只不过没物流罢了。

问题是，冯同学的软件网站为什么那么火？02年，Google刚起来但没几个人懂。可惜冯同学很懂，当时的搜索引擎高手。把3万种软件拆成60万个页面，结果Google排名前几位的都是他的网页。今天的冯同学不再认为做搜索是一个好的推广，因为过时了。前面提过，今天的Facebook就像是02年的Google。可惜，冯同学不准我把他的社交网络推广秘籍写出来。

之后冯同学做过两件事，一是在淘宝上做代购，帮美国人在淘宝上买东西然后快递到旧金山的家里再分包。为了搞懂国际物流的门道，甚至跟着一个包裹从香港一路到了美国。第二是在上海做软件外包，但败给了印度人，这使他认识到做成一个事情需要一个产业体系和一个畅通的链条。最后，做起了跨国的实物B2C，并且一开始就铁了心要打通整个的链条。

乔布斯说，所谓创新，就是找到不同的体验之间的关联。这句话又一次在郭去疾和冯剑峰身上应验了。海外经历+B2C，这使得他们想到并且做成一个能围猎阿里B2B的新模式。

一直没能见到郭同学，不过，我对见到真人的冯同学确实比较喜欢。他打动我的几个地方：

选址在重庆。其实冯剑峰不是重庆人，跟这个地方没有一毛钱的关系。他选这里的原因有2个：重庆人是南方人里的北方人，干活勤快而且直爽。其次，重庆跟北上广隔得远，没有所谓的专家。冯剑峰说：在北上广，随时可能被那些云里雾里的专家带到沟里去。但在重庆没人比我更懂，只可能我把别人带到沟里去。我们要干的是创新，专家都是误导，是创新的敌敌畏。

做的是高科技企业，冯剑峰去问政府要支持。办事员在郊区一处给他安排免费办公楼。冯同学问：为什么要到这么偏的地方？办事员说：这是专门给高科技企业的，政府给资助。冯反问：如果要靠政府资助才能活，那干的还是高科技？结果冯剑峰扭头就走，DD的第一个办公楼选在了重庆核心地段解放牌旁边的最高的楼的最高层。要看得远得站得高。

73年生。冯同学说这个年代的人具有60和80年代的双面性。60年代的自律、观念的束缚+80年代的快乐工作和自我。后者意味着闯劲，前者意味着使命。软银也想投DD，阎焱跟他说：唐朝时中国是强国，对外输出文化；现在是西方对我们输出文化。他跟阎焱说：经济基础决定上层建筑。我们先输出商品，借商品建立渠道；总有一天，我们的渠道也能输出文化。攻城略地，水到渠成。

冯的信条是：激情创新，坚韧自傲。是的，不是自信，是自傲。因为创新这个事情太难，人类对未知的领域总有莫名的恐惧，若没有自傲这股偏执，创新肯定扯淡。所以DD的文化是谁都不要信，只信数据和用户。数据推导出来的逻辑，就去贯彻，用户发出的呼声，就去满足。旧的流程不灵了，就打烂重做。旧的人不适应了，干掉再说。

最后，讲讲跨国B2C所能到达的高度吧。这些人之所以有趣，是因为他们被一件事激励着。

跨国B2C其实就是地球人的网上沃尔玛。LT或者DD之所以能做成这个的背后势力是：中国制造。而在打造网上沃尔玛的过程中，需要培养出一票中国的产品品牌，掌握定价权，攫取高利润。这个事情是阿里没能也很难做到的。同时LT和DD们也要成为沃尔玛那样的销售品牌。由于是直达消费者，所以跨国B2C还能规避掉目前中国制造所遭遇的反倾销调查。

这当中还有很多机会。比如，外国消费者都是直接打电话给DD的客服人员询问商品的信息并且抱怨或者投诉，这导致DD掌握了大量的一手的用户数据，这些珍贵的资料可以反向卖给中国的工厂，帮它们了解西方人并打磨产品。同样，这也是阿里们所不能做到的。由于销量越来越大，DD感觉到有建成一个大规模的全球Call Center的机会。而目前的全球Call Center产业基本握在印度人手里。

有趣的是，当冯剑峰向印度人的公司买一本叫《Telephone Doctor》的关于Call Center的培训用书时，却遭到拒绝。他怀疑，印度人不卖这个东西给中国人。当然，冯还是买到了这本书。对于想打通跨国B2C链条的人来说，这个困难实在是小意思。

这一系列的最后一篇写给普通编程人员，如果不感兴趣可直接看本文最后几段。开始设计代码结构之前，先回顾一下之前准备过的事情：我们有负载均衡的 WEB服务器，有主从DB服务器并可能分片，有缓存，有可扩展的存储。在组织代码的各个方面，跟这些准备息息相关，我一二三的列出来分别说，并且每一条都 以“前面讲到”这个经典句式开头，为了方便对照。 别着急看经典句式，我思维跳跃了，插一段。实际开发中，我们总会在性能和代码优雅性上作折中。对于当今的计算机和语言解释器，多 几层少几层对象调 用、声明变量为Map还是HashMap这种问题是最后才需要考虑的问题，永远要考虑系统最慢的部分，从最慢的部分解决。例如看看你用的ORM是不是做了 很多你用不到的事情，是不是有重复的数据调用。我们做的是web应用开发，不是底层框架API，代码易读易懂是保证质量很重要的一方面，你的程序是为了什 么而设计，有不同的方法……算了，这个话题另起一篇文章来说，扯远了，想交流可关注我的微博 http://t.sina.com.cn/liuzhiyi，咱继续……

前面讲到，WEB服务器是要做负载均衡的，图片服务器是要分开的。对于这点，代码在处理客户端状态时，不要把状态放到单机上，举例，不要用文件session，嗯，常识。 如果有可能，最好在一开始就做好用户单点认证的统一接口，包括跨域如何判断状态、静态页面如何判断状态，需要登录时的跳转和返回参数定义，底层给好接口， 应用层直接就用（可参考GAE的 user服务）。登录方面的设计要考虑移动设备的特性，比如电脑可以用浮动层窗口，但NOKIA自带的浏览器或UCWEB就无法处理这种表现形式，程序一 定既能处理AJAX请求又能直接通过URL来处理请求。图片服务器分开，资源文件最好也布局到图片服务器，也就是WEB服务器只服务动态程序。虽然开发测 试时稍微复杂（因为需要绝对URI才能访问），但将来页面前端优化上会轻松许多，并且你的WEB服务器IO优化也轻松许多。程序引用资源文件时，要有一个 统一的处理方法，在方法内部可以自动完成很多事情，例如将css/js根据组合，拼成一个文件，或者自动在生成的URI后面加上QUERYSTRING， 如果将来前端用了缓存服务，那生成QUERYSTRING是最简单的刷新服务端缓存和客户端缓存的办法。

前 面讲到，数据库会有复制，可能会多主多从，可能会分片。我们程序在处理数据的过程中，最好能抽象出来单独放做一层。拿现在流行的MVC模式来说，就是在M层下方再 放一个数据层，这个数据层不是通常所说的JDBC/PDO/ActiveRecord等，而是你自己的存取数据层，仅对外暴露方法，隐藏数据存取细节。这个数据层内部不要怕写的难看，但一定要提供所有的数据存储功能，其他任何层次不要看到跟数据库打交道的字眼。之所以这样做，是因为在单关系数据库的情况 下，可能会SELECT…JOIN…或直接INSERT…INTO…，可你可能会将一些表放到key-value数据库里存储，或者分片，这么做之后原来 的语句和方式要全部改变，如果过于分散，则移植时会耗费很大精力，或得到一个很大的Model。在数据层面的设计上，尽量避免JOIN查询，我们可以多做 冗余，多做缓存，每种数据尽量只需要一次查询，然后在你的程序里面进行组合。对于比较复杂的数据组合，在实时性要求不高的情况下，可采用异步处理，用户访 问时只取处理后的结果。在对于主键的处理上，避免使用自增ID，可以用一定规则生成的唯一值当做主键，这种主键是最简单的分片分布策略。即使用自增ID， 也最好用一个自增ID发生器，否则从数据库不小心被写了一下，那主键很容易冲突。

前面讲到，咱数据库前面还有某些缓存挡着。别把mysql的query cache当缓存，应用稍复杂的时候QUERYCACHE反而会成为累赘。缓存跟数据库和业务结合的很紧密，正因为跟业务关系紧密，所以这点没有放之四海而皆准的方法。但我们还是有一些规则可参照。规 则一：越接近前端，缓存的颗粒度越大。例如在WEB最前端缓存整个页面，再往后一层缓存部分页面区域，再往后缓存区域内的单条记录。因为越靠近后端，我们 的可操作性越灵活，并且变化最多的前端代码也比较方便编写。在实践中，因为产品需求变化速度非常快，迭代周期越来越短，有时很难将Controller和 Model分的那么清楚，Controller层面处理部分缓存必不可免，但要保证如果出现这种情况，Controller所操作的缓存一定不要影响其他 数据需求方，也就是要保证这个缓存数据只有这一个Controller在用。规则二：没有缓存时程序不能出错。在不考虑缓存失效引发的雪崩效应时，你的程 序要有缓存跟没缓存一个样，不能像新浪微博一样，缓存一失效，粉丝微博全空，整个应用都乱套了。在缓存必不可少的情况下，给用户出错信息都比给一个让人误 解的信息强。规则三，缓存更新要保证原子性或称作线程安全，特别是采用被动缓存的方式时，很可能两个用户访问时导致同一个缓存被更新，通常情况这不是大问 题，可缓存失效后重建时很可能是引发连锁反应的原因之一。规则四：缓存也是有成本的。不只是技术成本，还有人工时间成本。如果一个功能使用缓存和不使用， 在可预见的访问量情况下区别微小，但使用缓存会使复杂度增加，那就不用，我们可以加个TODO标注，在下次迭代的时候加上缓存处理。

前面讲到，文件存储是独立的，那么所有的文件操作就都是远程调用。可以在文件服务器上提供一个很简单的RESTful接口，也可以提供xmlrpc 或jsonserveice，WEB服务器端所生成和处理的文件，全部通过接口通知文件服务器去处理，WEB服务器本身不要提供任何文件存储。你会发现很多大网站的 上传图片跟保存文章是分两步完成的，就是基于这个原因。

以上几条“前面讲到”，其实无数人都讲过，我也只是结合前几篇文章用自己的话重复了一遍，真正分析起来精髓很简单——除了良好的功能逻辑分层，我们 还要为数据库存储、缓存、队列、文件服务等程序外层资源调用单独设计接口，你可以把你的程序想象成是运行在 Amazon EC2 上并用他的所有webservice服务，你的数据库就是它的SimpleDB， 你的队列就是他的SQS，你的存储就是他的S3，唯一不同是amazon的接口是远程调用，你的是内部调用。

将支撑服务接口化，意味着将MySQL更换到PostgreSQL不 需要更改业务处理程序，移植团队甚至不需要跟业务开发团队过多沟通；意味着业务开发团队是对接口编程而不是对数据库编程；意味着不会因为某个业务开发人员 的失误而拖垮性能。

对程序扫盲不感兴趣的直接看这里——

产品设计完了，程序框架搭完了，可能有矛盾在这个节骨眼儿产生了。不断有产品设计抱怨说他的创意没实现到预期效果，有程序员抱怨说产品设计不切实 际。这种抱怨多缘于产品人员不懂技术，技术人员不理解产品。从广义上来讲，产品包含市场策略、营销手段、功能设计，产品和技术在争论时往往把焦点放在功能 上，而实际重点是，实现这个功能所消耗的成本跟能这个功能带来的利益能否换算，能否取其轻重。若可以，争议解决。若不能，则抛硬币看运气。因为一个功能的 加强而引发指标井喷，或因项目拖延而导致贻误战机的例子比比皆是。激进的决策者注重利益，保守的决策者注重损失，聪明的决策者会考虑这个问题是否真的那么 严重。

关系到未来的事情谁都说不准，要不怎么说创业一半靠运气呢。不过总有能说的准的事情，那就得靠数据说话。

没有100%也有99.9%的网站安装了访问统计代码，连我的 http://zhiyi.us 也不例外，新闻联播也总说科学决策科学发展的。有了统计，能确定的事情就很多了。例如，可以根据来源-目标转化率来分析哪类渠道的人均获取成本低，根据来 源-内容访问猜测用户跳出率原因，根据用户点击行为判断链接位置是否合理等。将数据以不同方式组合起来，找到内在联系，分析内因外因，制定对应策略，减少拍脑门决策。靠数据支撑运营是个非常专业的事情，虽然不懂深奥的数学模型不会复杂的公式计算，渐渐学会因为A所以B，因为A和B所以C还是相对简单的。

全系列完毕。

七、数据库

几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。对于mysql，什么样的表用myisam，什么样的表用 innodb，在开发之前要确定。复制策略、分片策略，也要确定。表引擎方面，一般，更新不多、不需要事务的表可以用myisam，需要行锁定、事务支持的，用innodb。 myisam的锁表不一定是性能低下的根源，innodb也不一定全是行锁，具体细节要多看相关的文档，熟悉了引擎特性才能用的更好。现代WEB应用越来 越复杂了，我们设计表结构时常常设计很多冗余，虽然不符合传统范式，但为了速度考虑还是值得的，要求高的情况下甚至要杜绝联合查询。编程时得多注意数据一致性。

复制策略方面，多主多从结构也最好一开始就设计好，代码直接按照多主多从来编写，用一些小技巧来避免复制延时问题，并且还要解决多数据库数据是否一致，可 以自己写或者找现成的运维工具。

分片策略。总会有那么几个表数据量超大，这时分片必不可免。分片有很多策略，从简单的分区到根据热度自动调整，依照具体业务选择一个适合自己的。避 免自增ID作为主键，不利于分片。

用存储过程是比较难扩展的，这种情形多发生于传统C/S，特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务 的模式，是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。

NoSQL。这只是一个概念。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是 就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次 的写操作，内存型的甚至5万以上。例如MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。很多业务是可以用这类数据库来替代mysql的。

八、缓存。

数据库很脆弱，一定要有缓存在前面挡着，其实我们优化速度，几乎就是优化缓存，能用缓存的地方，就不要再跑到后端数据库那折腾。缓存有持久化缓存、内存缓存，生成静态页面是最容易理解的持久化缓存了，还有很多比如varnish的分块缓存、前面提到的memcachedb等，内存缓存，memcached首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单，缓存空了就自动去数据库取数据再把缓存填上，但容易引发雪 崩效应，一旦缓存大面积失效，数据库的压力直线上升很可能挂掉。主动缓存可避免这点但是可能引发程序取不到数据的问题。这两者之间如何配合，程序设计要多动脑筋。

九、队列。

用户一个操作很可能引发一系列资源和功能的调动，这些调动如果同时发生，压力无法控制，用户体验也不好，可以把这样一些操作放入队列，由另几个模块 去异步执行，例如发送邮件，发送手机短信。开源队列服务器很多，性能要求不高用数据库当做队列也可以，只要保证程序读写队列的接口不变，底层队列服务可随时更换就可以，类似Zend Framework里的Zend_Queue类，java.util.Queue接口等。

十、文件存储。

除了结构化数据，我们经常要存放其他的数据，像图片之类的。这类数据数量繁多、访问量大。典型的就是图片，从用户头像到用户上传的照片，还要生成不 同的缩略图尺寸。存储的分布几乎跟数据库扩展一样艰难。不使用专业存储的情况下，基本都是靠自己的NAS。这就涉及到结构。拿图片存储举例，图片是非常容易产生热点的，有些图片上传后就不再有人看，有些可能每天被访问数十万次，而且大量小文件的异步备份也很耗费时间。

为了将来图片走cdn做准备，一开始最好就将图片的域名分开，且不用主域名。很多网站都将cookie设置到了.domain.ltd，如果图片也 在这个域名下，很可能因为cookie而造成缓存失效，并且占多余流量，还可能因为浏览器并发线程限制造成访问缓慢。

如果用普通的文件系统存储图片，有一个简单的方法。计算文件的hash值，比如md5，以结果第一位作为第一级目录，这样第一级有16个目录。从0 到F，可以把这个字母作为域名，0.yourimg.com到f.yourimg.com（客户端dns压力会增大），还可以扩展到最多16个NAS集群上。第二级可用年月例如，201011，第三级用日，第四级可选，根据上传量，比如am/pm，甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时可以用脚本只同步某年某日某时的文件，避免计算大量文件带来的开销。当然最好是能用专门的分布式文件系统或更专业点的存储解决方案。

下面，我们要谈谈代码了。

开了自己域名的博客，第一篇就得来个重磅一点的才对得起这4美金的域名。作为一个技术从业者十年，逛了十年发现有些知识东一榔头西一棒槌的得满世界看个遍才整理出个头绪，那咱就系统点的从头一步一步的说，一个从日几千访问的小小网站，到日访问一两百万的小网站，怎么才能让它平滑的度过这个阶段，别在技术上出现先天不足，写给一些技术人员，也写给不懂技术的创业者。

对互联网有了解的人都有自己的想法，有人就把想法付诸实现，做个网站然后开始运营。其实从纯网站技术上来说，因为开源模式的发 展，现在建一个小网站已经很简单也很便宜。当访问量到达一定数量级的时候成本就开始飙升了，问题也开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最惨的就是数据丢失，辛辛苦苦好几年，一夜回到创业前。

减少成本就是增加利润。很多事情，我们在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。

假设你是一个参与创业的技术人员，当前一穷二白，什么都要自己做，自己出钱，初期几十万的资金，做一个应用不是特别复杂的网站，那么就要注意以下几 点：

一、开发语言

一般来说，技术人员（程序员）创业都是根据自己技术背景选择自己最熟悉的语言，不过考虑到不可能永远是您一个人写程序，这点还得仔细想想。无论用什 么语言，最终代码质量是看管理，所以我们还是从纯语言层面来说实际一点。现在流行的java、php、.net、python、ruby都有自己的优劣，python和ruby，现在人员还是相对难招一些，性能优化也会费些力气，.net平台买不起windows server。java、php用的还是最多。对于初期，应用几乎都是靠前端支撑的网站来说，php的优势稍大一些，入门简单、设计模式简单、写起来快、 性能足够等，不过不注重设计模式也是它的劣势，容易变得松散，隐藏bug稍多、难以维护。java的优势在于整套管理流程已经有很多成熟工具来辅助，强类 型也能避免一些弱智BUG，大多数JAVA程序员比较注重设计模式，别管实不实际，代码格式看起来还是不错的。这也是个劣势，初学者可能太注重模式而很难解决实际需求。

前端不只是html、css这类。整个负责跟用户交互的部分都是前端，包括处理程序。这类程序还是建议用php，主要原因就是开发迅速、从业人员广 泛。至于后端例如行为分析、银行接口、异步消息处理等，随便用什么程序，那个只能是根据不同业务需求来选择不同语言了。

二、代码版本管理

如果开发人员之间的网络速度差不多，就SVN；比较分散例如跨国，就hg。大多数人还是svn的.

假设选了svn，那么有几点考虑。一是采用什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能 要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。如果 喜欢把svn当做移动硬盘用，写一点就commit一次也无所谓，就是合并的时候头大一些，这些人可以自己建个分支甚至建立个本地代码仓库，随便往自己的分支提交，测试完毕后再提交到开发分支上。

部署，可以手工部署也可以自动部署。手工部署相对简单，一般是直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只要别再用ftp上传那种形式就好，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员 的版本跟线上版本不一致，导致本来想改个错字结果变成回滚的杯具。如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。

不管项目多小，养成使用版本管理的好习惯，最起码还可以当做你的备份，我的 http://zhiyi.us 虽然就是一个wordpress，可还是svn了，只改动一两句css那也是劳动成果。

三、服务器硬件

别羡慕大客户和有钱人，看看机房散户区，一台服务器孤独的支撑的网站数不清。如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid1+0。数据库至少16G内存，15k sas raid 1+0。备份服务器最好跟数据库服务器同等配置。硬件可以自己买品牌的底板，也就是机箱配主板和硬盘盒，CPU内存硬盘都自己配，也可以上整套品牌，也可以兼容机。三台机器，市场行情6、7万也就配齐了。

web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器干的活就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任 意一台出问题，把备份服务器换个ip就切换上去了。备份策略，可以drbd，可以rsync，或者其他的很多很多的 开源备份方案可选择。rsync最简单，放cron里自己跑就行。备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。

四、机房

三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。那网通机房呢？亲，网通联通N久 以前合并改叫联通了。多多寻找，实地参观，多多测试，多方打探，北京、上海、广州等各个主节点城市，还是有很多优质机房的，找个网络质量好，管理严格的机 房，特别是管理要严格，千万别网站无法访问了，打个电话过去才知道别人维护时把你网线碰掉了，这比DOS都头疼。自己扯了几根光纤就称为机房的，看您抗风 险程度和心理素质了。机房可以说是非常重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，我可以翻墙看风景，但买个网游vpn才能打开你这个还不怎么知名的网站就有难度了。或许您网站的ajax很出色，可是document怎么也不ready，一些代码永远绝缘于用户。

五、架构

初期架构一般比较简单，web负载均衡+数据库主从+缓存+分布式存储+队列。大方向上也确实就这几样东西，细节上也无数文章都重复过了，按照将来 会有N多WEB，N多主从关系，N多缓存，N多xxx设计就行，基本方案都是现成的，只是您比其他人厉害之处就在于设计上考虑到缓存失效时的雪崩效应、主 从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存总有一天会失效，数据库复制总有一天会断掉，队列总有一天会写不进去，电源总有一天会烧坏。根据墨菲定律，如果不考虑这些，网站早晚会成为茶几。

六、服务器软件

Linux、nginx、 php、mysql，几乎是标配，我们除了看名字，还得选版本。Linux发行版众多，只要没特殊要求，就选个用的人最多的，社区最活跃的，配置最方便 的，软件包最全最新的，例如debian、ubuntu。至于RHEL之类的嘛，你用只能在RHEL上才能运行的软件么？剩下的nginx、php、mysql、activemq、其他的等等，除非你改过这些软 件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。总有些道听途说的人跟你说老的版本稳定。所谓稳 定，是相对于特殊业务来说的，而就一个php写的网站，大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估一下，越早升级越好，别人家都用php6写程序了这边还php4的逛游呢。优秀的开源程序升级还是很负责任的，看好文档，别怕。

以上这六点准备完毕，现在我们有了运行环境，有了基本架构骨架，有了备份和切换方案，应该开始着手设计开发方面的事情了。开发方面的事情无数，下一 篇会先说一些重点。