互联网行业是一个快速发展、快速变化的行业，新的业务、新的机会层出不穷，新的技术如雨后春笋般冒出，NoSQL、大数据、云、Node.js、Docker等，无时不刻都在轰炸程序员们的脑袋，难怪中国的程序员都流传一个说法：过了30岁不能做技术工作了，因为技术发展太快了！ 

快节奏带来机会，但对于技术人员来说，更多的是带来挑战，甚至有时候是困惑。例如：

1. Docker很火哦，咱们要不要用呢 ？

2. Node.js好牛逼啊，我们用上就更牛逼了......

3. 大数据和云是业界发展趋势，我觉得我们也应该跟上技术发展的趋势......

还有很多类似的问题和想法，其实归根结底可以归纳为一个统一的问题：是什么推动了一个互联网企业的技术发展？

关于这个问题的回答，基本上可以分为几个典型的派别：

潮流派

潮流派的典型特征就是对于新技术特别热衷，紧跟技术潮流，当有新的技术出现时，迫切的想将新的技术应用到自己的产品中。例如：

• NoSQL很火，咱们要大规模的切换为NoSQL；

• 大数据好牛逼呀，将我们的MySQL切换为Hadoop吧；

• Node.js是的JavaScript统一前后端，这样非常有助于我们工作的开展；

保守派

保守派的典型特征和潮流派正好相反，对于新技术抱有很强的戒备心，稳定压倒一切，已经掌握了某种技术，就一直用这种技术打天下。就像那句俗语说的，“如果你手里有一把锤子，那么所有的问题都变成了钉子”，保守派就是拿着一把锤子解决所有的问题。例如：

• MySQL咱们用了这么久了，很熟悉了，业务也用MySQL、数据分析也用MySQL、报表也用MySQL吧；

• Java语言我们都很熟，业务用Java、工具用Java，平台也用Java； 

跟风派

跟风派与潮流派不同，这里的跟风派不是指跟着技术潮流，而是指跟着竞争对手的步子走。

简单来说，判断技术的发展就看竞争对手，竞争对手用了咱们就用，竞争对手没用咱们就等等看。例如：

• 这项技术腾讯用了么？ 腾讯用了我们就用；

• 阿里用了Hadoop，他们都在用，肯定是好东西，咱们也要尽快用起来，以提高咱们的竞争力；

• Google都用了Docker，咱们也用吧； 

相信不用多说，大家都能看出这几个典型派别存在的问题：

潮流派

首先，新技术既需要时间成熟，如果刚出来就赶紧用，此时新技术还不怎么成熟，实际应用很可能遇到各种“坑”；

其次，新技术需要学习，需要花费一定的时间去掌握，这个也是较大的成本；如果等到掌握了结果技术又不适用，就是一种较大的人力浪费了。 

保守派

保守派的主要问题是不能享受新技术带来的收益，因为新技术很多都是为了解决以前技术存在的固有缺陷。就像汽车取代马车一样，不是量变而是质变，带来的收益不是线性变化的，而是爆发式变化的。

如果无视技术的发展，形象一点说有了拖拉机，你还偏偏要用牛车。

跟风派

可能很多人都会认为，跟风派与“潮流派”和“保守派”相比，是最有效的策略，既不会承担“潮流派”的风险，也不会遭受“保守派”的损失，花费的资源也少，简直就是一举多得。

看起来很美妙，但跟风派最大的问题在于如果没有风可跟的时候怎么办。一种情况就是如果你是领头羊怎么办，其他人都准备跟你的风呢；

另外一种情况就是竞争对手的这些信息并不那么容易获取，即使获取到了一些信息，大部分也是不全面的，一不小心可能就变成邯郸学步了。

即使有风可跟，其实也还是存在问题的。俗话说：橘生淮南则为橘，生于淮北则为枳，叶徒相似，其实味不同。适用于竞争对手的技术，并不一定适用于自己，盲目模仿可能带来相反的效果。 

既然这几个典型派别都存在问题，那么互联网技术发展的驱动力究竟是什么 ？

这个问题之所以让人困惑，我觉得关键的原因还是在于不管是潮流派、保守派，还是跟风派，都是站在技术本身的角度来考虑问题的，正所谓“不识庐山真面，只缘身在此山中”。

因此，要想看到庐山真面目，只有跳出技术的角度，从一个更广更高的角度来考虑这个问题，这个角度就是互联网企业的发展。

互联网企业的业务基本上可以大概分为两类：一类是提供“产品”，一类是提供“服务”。

提供产品：360的杀毒软件、苹果的iPhone、UC的浏览器。等都属于这个范畴，这些产品本质上和传统的制造业产品类似，都是具备了某种“功能”，能够完成某些任务；

提供服务：百度的搜索、淘宝的购物、微博的资讯、腾讯的IM。都属于这个范畴，和“提供产品”的业务不同是，提供服务的业务更加符合互联网的特征和本质：“互联” +“ 网”。所以后续的文章谈论的“互联网技术”，就是指“提供服务的互联网业务的技术”。

“互联”是指这些业务将原本分散的个体连结成了一个庞大的整体，可以将人连接，也可以将信息连接，也可以将数据连接，连接在一起的群体的价值比群体中单个个体的价值之和要大得多；“网”有两种含义：一个是指通过数据网络连接（与传统的电话网络等相比）、一个是指个体互联成“网状”的结构。 

一个互联网企业的发展，归根结底就是业务的发展，而影响一个互联网企业的业务发展的主要有3个因素：市场、技术、管理。我称之为业务发展铁三角，任何一个因素的不足都将导致企业业务的发展停滞不前。

 如上图，在这个铁三角中，业务是处于三角形的中心，毫不夸张的说，市场、技术、管理的动作都是为了支撑企业业务的发展。市场和管理对业务的影响不在本文的探讨范畴之内，我们主要来探讨一下“技术”和“业务”之间的关系和互相如何影响。 

对于“产品”类的业务，答案其实很明显：技术创新不断推动业务的发展。

这个道理和传统的制造行业的产品创新是一样的：产品上的技术创新 -> 带来更强大的功能  -> 推动产品的市场不断扩大 -> 市场扩大竞争更加激烈 -> 反过来又对技术创新提出了更高的要求，如此循环往复，技术创新不断的推动产品的提升、业务的扩展。

对于“产品”类业务，为了追求不断的创新，即使“潮流派”或者“跟风派”存在风险或者问题，但为了能够取得领先，也必须不遗余力的去尝试，否则等到技术没有风险的时候再去用，自己可能已经落后对手一大截了。而且不但要做“潮流派”，还要做“跟风派”，更要做“领头羊”，这样才能在激烈的竞争市场环境下不断的保持领先的优势。

例如：

1. 苹果开发智能手机，将诺基亚推下王座，自己成为全球手机行业的新王者，就是技术创新驱动产品的典型例子；

2. 2G时代，UC浏览器独创的云端架构，很好的解决了上网慢的问题；智能机时代，UC浏览器又自主研发全新的U3内核，兼顾高速、安全、智能及可扩展性，这些技术创新是UC浏览器成为了全球最大的第三方手机浏览器最强有力的推动力。

而对于“服务”类的业务，答案和产品类业务正好相反：业务发展推动技术的发展。

为什么会出现截然相反的差别呢？这还需要从“产品”和“服务”的本质差别来看。用户选择一个产品的根本驱动力是其“功能”，例如功能是否强大，外观是否漂亮，用户体验是否良好；而用户选择一个服务的根本驱动力不是功能，而是“规模”。

例如：选择UC浏览器还是选择QQ浏览器，更多的人是根据个人喜好和体验来决定的；而选择微信还是WhatsApp，就不是根据它们之间的功能差异来选择的，而是根据其规模来选择的。就像我更喜欢WhatsApp的简洁，但我的的朋友和周边的人都用微信，那我也不得不用微信。 

当“规模”成为业务的决定因素后，服务模式的创新成为了业务发展的核心驱动力，而产品只是为了完成服务而提供给用户。以淘宝为例：淘宝提供的“网络购物”是一种新的服务，这种业务与传统的到实体店购物是完全不同的，而为了完成这种业务，需要“淘宝网”、“支付宝”、“一淘”、“菜鸟物流”等多个产品。

比如说假如我技术创新，开发一个耗电量只有微信的1/10，用户体验比微信好10倍的产品，你觉得现在的微信用户都会抛弃微信，而转投我的这个产品么？我相信绝大部分人都不会，因为微信不是一个互联网产品，而是一个互联网服务，你一个人换到其它类微信类产品是没有意义的。

因此，服务类的业务发展路径是这样的：提出一种创新的服务模式 -> 吸引了一批用户 -> 业务开始发展 -> 吸引了更多用户 -> 服务模式不断完善和创新 -> 吸引越来越多的用户，如此循环往复。在这个发展路径中，技术并没有成为业务发展的驱动力，反过来由于用户规模的不断扩展，业务的不断创新和改进，对技术会提出越来越高的要求，因此是业务驱动了技术发展。

对于“服务”类业务，业务成为了技术发展的驱动力。因此“潮流派”、“跟风派”、“保守派”都是不可取的，什么时候采取什么技术是由业务的规模决定的。 

对于“产品”类业务来说，技术的发展和具体的产品有很强的关系，比如说UC浏览器的技术优化和苹果手机的技术优化差别会非常大，因此难以形成一套技术发展的模式；而对于“服务”类业务来说，虽然业务千差万别，但“规模”的发展对技术的影响和推动效果是基本一致的，可以归纳出一套成熟的技术发展体系，本文就试图在这个方向上分几个主题进行一番探索。

前面讲了那么一大堆理论，听起来有点道理，但实践是检验真理的唯一标准，究竟事实是否就是这样呢？我们可以回顾一下几个典型互联网企业的技术发展历程。这里挑选了两个最典型的企业：淘宝、腾讯。之所以挑选这两个，一个是因为大家耳熟能详，另外一个也是因为资料好找。 

淘宝

注：以下内容主要摘自《淘宝技术发展》。

淘宝技术发展主要经历了“个人网站”、“Oracle/支付宝/旺旺”、“Java时代1.0”、“Java时代2.0”、“Java时代3.0”、“分布式时代”。我们看看每个阶段的主要驱动力是什么。

1. 个人网站

2003年4月7日马云提出成立淘宝，2003年5月10日淘宝就上线了，中间只有1个月，怎么办？淘宝的答案就是：买一个。

估计大部分人很难想象如今技术牛气冲天的阿里最初的淘宝竟然是买来的，我们看看当初决策的依据：

“当时对整个项目组来说压力最大的就是时间，怎么在最短的时间内把一个从来就没有的网站从零开始建立起来？了解淘宝历史的人知道淘宝是在 2003 年 5 月 10 日上线的，这之间只有一个月。要是你在这个团队里，你怎么做？我们的答案就是：买一个来。” 

大家看到没有，这个时候没有过多考虑技术是否牛逼、没有过多考虑性能是否海量、没有考虑稳定性如何，主要的考虑就是：快！

因为此时业务要求快速上线，时间不等人，等你花几个月甚至10几个月搞出1个牛逼的系统出来，可能市场机会就没有了，黄花菜都凉了。

同样，在考虑如何买的时候，淘宝的决策依据主要也是”快“： 

“买一个网站显然比做一个网站要省事一些，但是他们的梦想可不是做一个小网站而已，要做大，就不是随便买个就行的，要有比较低的维护成本，要能够方便的扩展和二次开发。

那接下来就是第二个问题：买一个什么样的网站？答案是：轻量一点的，简单一点的”。

买一个系统是为了”快速可用“，而买一个轻量级的系统是为了”快速开发“，因为系统上线后肯定有大量的需求需要做，这个时候能够快速开发就非常重要。

从这个实例我们可以看到：淘宝最开始的时候业务要求就是”快“，因此反过来要求技术同样要”快“，业务决定技术。 

第一代的技术架构如下图：

 

 2. Oracle/支付宝/旺旺

淘宝网推出后，由于正好碰到非典，网购很火爆，加上采取了成功的市场运作，流量和交易量迅速上涨，业务发展很快，在 2003 年底，MySQL 已经撑不住了。

一般人或者团队在这个时候，可能就开始优化系统、优化架构了、分拆业务了，因为这些是大家耳熟能详也很拿手的动作。那我们来看看淘宝这个时候怎么采取的措施：

“技术的替代方案非常简单，就是换成 Oracle。换 Oracle 的原因除了它容量大、稳定、安全、性能高之外，还有人才方面的原因。”

可以看出这个时候淘宝的策略主要还是”买“，买更高配置的Oracle，这个是当时情况下最快的方法。

除了购买Oracle，后来为了优化，又买了更牛逼的存储：

“后来数据量变大了，本地存储不行了。买了 NAS（Network Attached Storage：网络附属存储），NetApp 的 NAS 存储作为了数据库的存储设备，加上 Oracle RAC（Real Application Clusters，实时应用集群）来实现负载均衡。”

我们思考一下，为什么淘宝在这个时候继续采取“买”的方式来快速解决问题呢？我们可以从时间上看出端倪：此时离刚上线才半年不到，业务飞速发展，最快的方式支撑业务的发展还是去买。如果说第一阶段买的是“方案”，这个阶段买的就是“性能”。 

换上Oracle和昂贵的存储后，第二代架构如下：

 

  3. Java时代1.0 - 脱胎换骨

淘宝切换到Java的原因很有趣，主要因为找了一个PHP的开源连接池SQL Relay连接到Oracle，而这个代理经常死锁，死锁了就必须重启，而数据库又必须用Oracle，于是决定换个开发语言。最后淘宝挑选了Java，而且当时挑选Java，也是请Sun公司的人，这帮人很牛逼，先是将淘宝网站从PHP热切换到了Java，后来又做了支付宝。

这次切换的最主要原因是因为技术影响了业务的发展，你说动不动就死锁、然后就要重启，这个是对用户业务严重的影响。从业务的角度来看这是不得不解决的技术问题。 

但这次淘宝为什么没有去“买”，是有点疑惑的地方。我们看最初选择SQL Relay的原因：

“但对于 PHP 语言来说它是放在 Apache 上的，每一个请求都会对数据库产生一个连接，它没有连接池这种功能（Java 语言有 Servlet 容器，可以存放连接池）。那如何是好呢？这帮人打探到 eBay 在 PHP 下面用了一个连接池的工具，是 BEA 卖给他们的。我们知道 BEA 的东西都很贵，我们买不起，于是多隆在网上寻寻觅觅，找到一个开源的连接池代理服务 SQLRelay”

不清楚当时到底有多贵，Oracle都可以买，连接池买不起 ？所以我个人感觉这次切换语言，更多的是为以后业务发展做铺垫，毕竟当时PHP语言远远没有Java那么火，那么好招人。淘宝选择Java语言的理由可以从侧面验证这点：

“Java 是当时最成熟的网站开发语言，它有比较良好的企业开发框架，被世界上主流的大规模网站普遍采用，另外有 Java 开发经验的人才也比较多，后续维护成本会比较低。” 

从PHP改为Java后，第三代技术架构如下：

 

 4. Java时代2.0 - 坚若磐石

Java2.0时代，淘宝做了很多优化工作：数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss。为什么在这个时候要做这些动作？ 原文作者很好的概括了做这些动作的原因：

“这些杂七杂八的修改，我们对数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss，看起来没有章法可循，其实都是围绕着提高容量、提高性能、节约成本来做的”

我们思考一下，为什么在前面的阶段，淘宝考虑的都是“快”，而现在开始考虑“容量、性能、成本”了呢？而且为什么这个时候不采取“买”的方式来解决容量、性能、成本问题呢？

简单来说，就是“买”也搞不定了，此时的业务发展情况是这样的：

“随着数据量的继续增长，到了 2005 年，商品数有 1663 万，PV 有 8931 万，注册会员有 1390 万，这给数据和存储带来的压力依然山大，数据量大，性能就慢。”

原有的方案存在的固有缺陷，随着业务的继续发展，已经不是靠“买”能够解决的了，此时必须从整个架构上去进行调整和优化。比如说Oracle再牛逼，在做like类搜索的时候，也不可能做到纯粹的搜索系统如Solr、Sphinx等的性能，因为这是机制决定的。 

另外，随着规模的增大，纯粹靠买的一个典型问题开始成为重要的考虑因素，那就是成本。当买一台两台Oracle的时候，可能对成本并不怎么关心，但如果要买100台Oracle，成本就是一个关键因素了。这就是“量变带来质变”的一个典型案例。

Java 架构经过各种优化，第四代技术架构如下：

 5. Java时代3.0 和分布式时代

Java时代3.0时代我个人认为是淘宝技术飞跃的开始，简单来说就是淘宝技术从商用转为“自研”，典型的就是去IOE化。

分布式时代我认为是淘宝技术的修炼成功，到了这个阶段，自研技术已经自成一派，除了支撑本身的海量业务外，也开始影响整个互联网的技术发展。

具体的原因这里就不详细分析，留给读者按照前面的思路去分析。

手机QQ

注：以下内容主要摘自《QQ1.4亿在线背后的故事》

手机QQ的发展历程按照用户规模可以粗略划分为4个阶段：十万级、百万级、千万级、亿级，不同的用户规模，IM后台的架构也不同，而且基本上都是用户规模先上去，然后产生各种问题，倒逼技术架构升级。

1. 十万级 - IM1.X

最开始的手机QQ后台如下，可以说是简单的不能再简单，普通得不能再普通的一个架构了（是否会感叹原来神一样的公司开始也是屌丝一个呀 ）：

 

2. 百万级 - IM2.X

业务发展：2001年，QQ同时在线突破一百万

第一代架构很简单，但也很明显不可能支撑百万级的用户规模，主要的问题有：

1. 以接入服务器的内存为例，单个在线用户的存储量约为2KB，索引和在线状态 50字节，好友表 400个好友 * 5字节/好友 = 2000字节，大致来说，2G内存只能支持一百万在线用户；

2. CPU/网卡包量和流量/交换机流量等瓶颈；

3. 单台服务器支撑不下所有在线用户/注册用户；

 于是针对这些问题做架构改造，IM2.X的最终架构如下：

 

3. 千万级 - IM3.X

业务发展：2005年，QQ同时在线突破一千万。

第二代架构支撑百万级用户是OK的，但支撑千万级用户又有问题，表现如下：

1. 同步流量太大，状态同步服务器遇到单机瓶颈；

2. 所有在线用户的在线状态信息量太大，单台接入服务器存不下，如果在线数进一步增加，则甚至单台状态同步服务器也存不下；

3. 单台状态同步服务器支撑不下所有在线用户；

4. 单台接入服务器支撑不下所有在线用户的在线状态信息； 

针对这些问题，架构需要继续改造升级，IM3.X的最终架构如下：

 

4. 亿级用户 - IM1.X

业务发展：2010.03，QQ同时在线人数过亿

第三代架构此时也不适应了，主要问题有：

• 灵活性很菜：“昵称”长度增加一半，需要两个月、增加“故乡”字段，需要两个月、最大好友数从500变成1000，需要三个月。

• 无法支撑这些关键功能：上万好友、隐私权限控制、PC QQ与手机QQ别互踢、微信与QQ互通、异地容灾。

除了不适应外，还有一个更严重的问题：

“IM后台从1.0到3.5都是在原来基础上做改造升级，但是：持续打补丁已经难以支撑亿级在线，IM后台4.0必须从头开始，重新设计实现！”

决定重新打造一个这么复杂的系统，不得不佩服当时决策人的勇气和魄力！！

重新设计的IM4.0架构如下，和之前的架构相比，架构本身都拆分为两个主要的架构：存储架构和通信架构：
 

 通过上面对淘宝技术发展和手机QQ的架构发展，我们可以看到，这两个实例证明了我们之前的推断：对于提供互联网服务的企业来说，互联网技术的发展，背后的驱动力是业务的发展。