BAT解密：互联网技术发展之路1
BAT解密：互联网技术发展之路（1） - 技术发展的驱动力
互联网行业是一个快速发展、快速变化的行业，新的业务、新的机会层出不穷，新的技术如雨后春笋般冒出，NoSQL、大数据、云、Node.js、Docker等，无时不刻都在轰炸程序员们的脑袋，难怪中国的程序员都流传一个说法：过了30岁不能做技术工作了，因为技术发展太快了！
快节奏带来机会，但对于技术人员来说，更多的是带来挑战，甚至有时候是困惑。例如：
1）Docker很火哦，咱们要不要用呢 ？
2）Node.js好牛逼啊，我们用上就更牛逼了......
3）大数据和云是业界发展趋势，我觉得我们也应该跟上技术发展的趋势......
......
还有很多类似的问题和想法，其实归根结底可以归纳为一个统一的问题：是什么推动了一个互联网企业的技术发展？
关于这个问题的回答，基本上可以分为几个典型的派别：
1）潮流派
潮流派的典型特征就是对于新技术特别热衷，紧跟技术潮流，当有新的技术出现时，迫切的想将新的技术应用到自己的产品中。
例如：
NoSQL很火，咱们要大规模的切换为NoSQL；
大数据好牛逼呀，将我们的MySQL切换为Hadoop吧；
Node.js是的javascript统一前后端，这样非常有助于我们工作的开展；
......等等
2）保守派
保守派的典型特征和潮流派正好相反，对于新技术抱有很强的戒备心，稳定压倒一切，已经掌握了某种技术，就一直用这种技术打天下。就像那句俗语说的，“如果你手里有一把锤子，那么所有的问题都变成了钉子”，保守派就是拿着一把锤子解决所有的问题。
例如：
MySQL咱们用了这么久了，很熟悉了，业务也用MySQL、数据分析也用MySQL、报表也用MySQL吧；
Java语言我们都很熟，业务用java、工具用java，平台也用java；
......等等
3）跟风派
跟风派与潮流派不同，这里的跟风派不是指跟着技术潮流，而是指跟着竞争对手的步子走。
简单来说，判断技术的发展就看竞争对手，竞争对手用了咱们就用，竞争对手没用咱们就等等看。
例如：
这项技术腾讯用了么？ 腾讯用了我们就用；
阿里用了Hadoop，他们都在用，肯定是好东西，咱们也要尽快用起来，以提高咱们的竞争力；
Google都用了Docker，咱们也用吧；
......等等
相信不用多说，大家都能看出这几个典型派别存在的问题：
1）潮流派
首先，新技术既需要时间成熟，如果刚出来就赶紧用，此时新技术还不怎么成熟，实际应用很可能遇到各种“坑”；
其次，新技术需要学习，需要花费一定的时间去掌握，这个也是较大的成本；如果等到掌握了结果技术又不适用，就是一种较大的人力浪费了
2）保守派
保守派的主要问题是不能享受新技术带来的收益，因为新技术很多都是为了解决以前技术存在的固有缺陷。就像汽车取代马车一样，不是量变而是质变，带来的收益不是线性变化的，而是爆发式变化的。
如果无视技术的发展，形象一点说有了拖拉机，你还偏偏要用牛车。
3）跟风派
可能很多人都会认为，跟风派与“潮流派”和“保守派”相比，是最有效的策略，既不会承担“潮流派”的风险，也不会遭受“保守派”的损失，花费的资源也少，简直就是一举多得。
看起来很美妙，但跟风派最大的问题在于如果没有风可跟的时候怎么办。一种情况就是如果你是领头羊怎么办，其他人都准备跟你的风呢；
另外一种情况就是竞争对手的这些信息并不那么容易获取，即使获取到了一些信息，大部分也是不全面的，一不小心可能就变成邯郸学步了。
即使有风可跟，其实也还是存在问题的。俗话说：橘生淮南则为橘，生于淮北则为枳，叶徒相似，其实味不同。适用于竞争对手的技术，并不一定适用于自己，盲目模仿可能带来相反的效果。
既然这几个典型派别都存在问题，那么互联网技术发展的驱动力究竟是什么 ？
这个问题之所以让人困惑，我觉得关键的原因还是在于不管是潮流派、保守派，还是跟风派，都是站在技术本身的角度来考虑问题的，正所谓“不识庐山真面，只缘身在此山中”。
因此，要想看到庐山真面目，只有跳出技术的角度，从一个更广更高的角度来考虑这个问题，这个角度就是互联网企业的发展。
互联网企业的业务基本上可以大概分为两类：一类是提供“产品”，一类是提供“服务”。
提供产品：360的杀毒软件、苹果的iphone、UC的浏览器。。。。。。等都属于这个范畴，这些产品本质上和传统的制造业产品类似，都是具备了某种“功能”，能够完成某些任务；
提供服务：百度的搜索、淘宝的购物、微博的资讯、腾讯的IM。。。。。。都属于这个范畴，和“提供产品”的业务不同是，提供服务的业务更加符合互联网的特征和本质：“互联” +“ 网”。所以后续的文章谈论的“互联网技术”，就是指“提供服务的互联网业务的技术”。
“互联”是指这些业务将原本分散的个体连结成了一个庞大的整体，可以将人连接，也可以将信息连接，也可以将数据连接，连接在一起的群体的价值比群体中单个个体的价值之和要大得多；“网”有两种含义：一个是指通过数据网络连接（与传统的电话网络等相比）、一个是指个体互联成“网状”的结构。
一个互联网企业的发展，归根结底就是业务的发展，而影响一个互联网企业的业务发展的主要有3个因素：市场、技术、管理。我称之为业务发展铁三角，任何一个因素的不足都将导致企业业务的发展停滞不前。
如上图，在这个铁三角中，业务是处于三角形的中心，毫不夸张的说，市场、技术、管理的动作都是为了支撑企业业务的发展。市场和管理对业务的影响不在本文的探讨范畴之内，我们主要来探讨一下“技术”和“业务”之间的关系和互相如何影响。
对于“产品”类的业务，答案其实很明显：技术创新不断推动业务的发展。
这个道理和传统的制造行业的产品创新是一样的：产品上的技术创新 -> 带来更强大的功能 -> 推动产品的市场不断扩大 -> 市场扩大竞争更加激烈 -> 反过来又对技术创新提出了更高的要求，如此循环往复，技术创新不断的推动产品的提升、业务的扩展。
对于“产品”类业务，为了追求不断的创新，即使“潮流派”或者“跟风派”存在风险或者问题，但为了能够取得领先，也必须不遗余力的去尝试，否则等到技术没有风险的时候再去用，自己可能已经落后对手一大截了。而且不但要做“潮流派”，还要做“跟风派”，更要做“领头羊”，这样才能在激烈的竞争市场环境下不断的保持领先的优势。
例如：
1）苹果开发智能手机，将诺基亚推下王座，自己成为全球手机行业的新王者，就是技术创新驱动产品的典型例子；
2） 2G时代，UC浏览器独创的云端架构，很好的解决了上网慢的问题；智能机时代，UC浏览器又自主研发全新的U3内核，兼顾高速、安全、智能及可扩展性，这些技术创新是UC浏览器成为了全球最大的第三方手机浏览器最强有力的推动力。
而对于“服务”类的业务，答案和产品类业务正好相反：业务发展推动技术的发展。
为什么会出现截然相反的差别呢？这还需要从“产品”和“服务”的本质差别来看。用户选择一个产品的根本驱动力是其“功能”，例如功能是否强大，外观是否漂亮，用户体验是否良好；而用户选择一个服务的根本驱动力不是功能，而是“规模”。
例如：选择UC浏览器还是选择QQ浏览器，更多的人是根据个人喜好和体验来决定的；而选择微信还是whatsapp，就不是根据它们之间的功能差异来选择的，而是根据其规模来选择的。就像我更喜欢whatsapp的简洁，但我的的朋友和周边的人都用微信，那我也不得不用微信。
当“规模”成为业务的决定因素后，服务模式的创新成为了业务发展的核心驱动力，而产品只是为了完成服务而提供给用户。以淘宝为例：淘宝提供的“网络购物”是一种新的服务，这种业务与传统的到实体店购物是完全不同的，而为了完成这种业务，需要“淘宝网”、“支付宝”、“一淘”、“菜鸟物流”等多个产品。
比如说假如我技术创新，开发一个耗电量只有微信的1/10，用户体验比微信好10倍的产品，你觉得现在的微信用户都会抛弃微信，而转投我的这个产品么？我相信绝大部分人都不会，因为微信不是一个互联网产品，而是一个互联网服务，你一个人换到其它类微信类产品是没有意义的。
因此，服务类的业务发展路径是这样的：提出一种创新的服务模式 -> 吸引了一批用户 -> 业务开始发展 -> 吸引了更多用户 -> 服务模式不断完善和创新 -> 吸引越来越多的用户，如此循环往复。在这个发展路径中，技术并没有成为业务发展的驱动力，反过来由于用户规模的不断扩展，业务的不断创新和改进，对技术会提出越来越高的要求，因此是业务驱动了技术发展。
对于“服务”类业务，业务成为了技术发展的驱动力。因此“潮流派”、“跟风派”、“保守派”都是不可取的，什么时候采取什么技术是由业务的规模决定的。
对于“产品”类业务来说，技术的发展和具体的产品有很强的关系，比如说UC浏览器的技术优化和苹果手机的技术优化差别会非常大，因此难以形成一套技术发展的模式；而对于“服务”类业务来说，虽然业务千差万别，但“规模”的发展对技术的影响和推动效果是基本一致的，可以归纳出一套成熟的技术发展体系，本文就试图在这个方向上分几个主题进行一番探索。
前面讲了那么一大堆理论，听起来有点道理，但实践是检验真理的唯一标准，究竟事实是否就是这样呢？我们可以回顾一下几个典型互联网企业的技术发展历程。这里挑选了两个最典型的企业：淘宝、腾讯。之所以挑选这两个，一个是因为大家耳熟能详，另外一个也是因为资料好找。
【淘宝】
注：以下内容主要摘自《淘宝技术发展》，原文链接：http://kb.cnblogs.com/page/132724/
淘宝技术发展主要经历了“个人网站”、“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同时在线人数过亿
第三代架构此时也不适应了，主要问题有：
1）灵活性很菜：“昵称”长度增加一半，需要两个月、增加“故乡”字段，需要两个月、最大好友数从500变成1000，需要三个月
2）无法支撑这些关键功能：上万好友、隐私权限控制、PC QQ与手机QQ别互踢、微信与QQ互通、异地容灾
除了不适应外，还有一个更严重的问题：
“IM后台从1.0到3.5都是在原来基础上做改造升级，但是：持续打补丁已经难以支撑亿级在线，IM后台4.0必须从头开始，重新设计实现！”
决定重新打造一个这么复杂的系统，不得不佩服当时决策人的勇气和魄力！！
重新设计的IM4.0架构如下，和之前的架构相比，架构本身都拆分为两个主要的架构：存储架构和通信架构：
通过上面对淘宝技术发展和手机QQ的架构发展，我们可以看到，这两个实例证明了我们之前的推断：对于提供互联网服务的企业来说，互联网技术的发展，背后的驱动力是业务的发展。
了解到互联网技术发展的根本驱动力是业务的发展后，接下来我们就需要继续分析：业务如何驱动技术的发展、技术体系会按照什么样的路径发展。欲知后事如何，且听下回分解
==================================================
转载注明出处：http://blog.csdn.net/yunhua_lee/article/details/44938671
BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展
在《互联网技术发展之路（1） - 技术发展的驱动力》一文中，我们详细阐述了对于服务类的业务来说，业务发展是技术发展的驱动力。那接下来我们就看看业务究竟是如何驱动技术发展的。
互联网业务千差万别，但由于他们具有“规模决定一切”的相同点，其发展路径也基本上是一致的。互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成熟期。
不同时期的差别主要体现在两个方面：复杂性、用户规模。
复杂性
业务的发展第一个主要方向就是“业务越来越复杂”，我们来看看不同时期业务的复杂性的表现。
【初创期】
互联网业务刚开始一般都是一个创新的业务点，这个业务点的重点不在于“完善”，而在于“创新”，只有创新才能吸引用户；而且因为其“新”的特点，其实一开始是不可能很完善的。只有随着越来越多的用户的使用，通过快速迭代试错、用户的反馈等手段，不断的在实践中去完善，去继续创新。
初创期的业务对技术就1个要求：“快”，但这个时候却又是创业团队最弱小的时候，可能就那么几个技术人员，所以这个时候十八般武艺都需要用上：能买就买，有开源的就用开源的，能模仿的就模仿，甚至可能是能偷就偷。
继续以淘宝和QQ为例：
第一版的淘宝（http://www.yixieshi.com/it/20770.html ）：
第一版QQ（http://www.yixieshi.com/it/20770.html ）：
可以看到最开始的淘宝和QQ与现在的淘宝和QQ相比，几乎看不出是同一个业务了。
【发展期】
当业务推出后经过市场验证如果是可行的，吸引的用户就会越来越多，此时原来不完善的业务就进入了一个快速发展的时期。业务快速发展时期的主要目的是将原来不完善的业务逐渐完善，因此会有越来越多的新功能不断的加入到系统里面。对于绝大部分技术团队来说，这个阶段技术的核心工作是快速的实现各种需求，只有这样才能满足业务发展的需要。
如何做到“快”，一般会经历如下几个阶段：
1. 堆功能
业务进入快速发展期的初期，此时团队规模也不大，业务需求又很紧，最快实现业务需求的方式是继续在原有的系统里面不断的增加新的功能，重构、优化、架构等方面的工作即使想做，也会受制于人力和业务发展的压力而放在一边。
2. 优化期
“堆功能”的方式在刚开始的时候好用，因为系统还比较简单，但随着功能越来越多，系统开始变得越来越复杂，后面继续堆功能会感到越来越吃力，速度越来越慢。一种典型的场景是做一个需求要改好多的地方，一不小心就改出了问题。直到终于有一天，技术团队或者产品人员再也受不了这种慢速的方式，终于下定决定要解决这个问题了。
如何解决这个问题，一般会分为两派：一派是优化派，一派是架构派。
优化派其主张主要是将现有的系统优化，例如采用重构、分层、优化某个MySQL查询语句，将机械硬盘换成SSD，将数据库从MySQL换成Oracle，增加Memcache缓存。。。。。。等等。优化派的优势是对系统改动较小，可以比较快速的实施；缺点就是可能过不了多久，系统又撑不住了。
架构派其主张主要是将系统架构调整，主要是将原来的大系统拆分为多个互相配合的小系统。例如将购物系统拆分为登录认证子系统、订单系统、查询系统、分析系统等。架构派的优势是一次调整可以支撑比较长期的业务发展，缺点是动作较大，耗时较长，对业务的发展影响也比较大。
相信在很多公司都遇到这种情况，而我敢打赌大部分情况下都是“优化派”会赢，主要的原因还是因为此时“优化”是最快的方式，至于说“优化派”支撑不了多久这个问题，其实也不用考虑太多，因为业务能否发展到那个阶段，还是个未知数，保证当下的竞争力是最主要的问题。
3. 架构期
经过优化期后，如果业务能够继续发展，慢慢的就会发现优化也顶不住了，毕竟再怎么优化，系统的能力总是有极限的，Oracle再牛，也不可能一台Oracle顶住1亿的交易量；小型机再好，也不可能一台机器支持100万在线。此时已经没有别的选择，只能进行架构调整，在优化期被压制的架构派开始扬眉吐气了，甚至会骄傲的说“看看吧，早就说要进行架构调整，你们偏要优化，现在还是顶不住了吧，哼。。。。。。”
架构期可以用的手段很多，但归根结底可以总结为一个字“拆”，什么地方都可以拆，例如：
拆功能：例如将购物系统拆分为登录认证子系统、订单系统、查询系统、分析系统等
拆数据库：MySQL一台变两台，2台变4台，增加DBProxy、分库分表等
拆服务器：服务器一台变两台，2台变4台，增加负载均衡的系统，例如Nginx、HAProxy等
3个不同时期的对比如下：
时期 | 优点 | 缺点 |
堆功能期 | 方便快捷，系统改动很小 | 开始较快，但越来越慢 |
优化期 | 方便快捷，系统改动较小 | 开始较快，但越来越慢 |
架构期 | 长效作用明显，做一次可以顶几年 | 改动大，实施的过程较长，短则半年，长则1 ~ 2年 |
【竞争期】
当业务继续发展，已经形成一定规模后，一定会有竞争对手开始加入行业来竞争（“一直在模仿、从未被超越”的腾讯、财大气粗的阿里巴巴），毕竟大家都想分一块蛋糕，甚至有可能一不小心还会成为下一个阿里巴巴。当竞争对手加入后，大家互相学习和模仿，业务更加完善，也不断的有新的业务创新出来，而且由于竞争的压力，对技术的要求是更上一层楼的“快”了。
新业务的创新，给技术带来的典型压力就是新的系统会更多，同时，原有的系统也会拆的越来越多。两者合力的一个典型后果就是系统数量在原来的基础上又增加了很多。架构拆分后带来的美好的时光又开始慢慢消逝，技术工作又开始进入了“慢”的的状态，这又是怎么回事呢？
原来系统数量越来越多，到了一个临界点后就产生了质变，即：系统数量的量变带来了技术工作的质变。主要体现在如下几个方面：
1）重复造轮子：系统越来越多，各系统相似的工作越来越多。例如：每个系统都有存储、都要用缓存、都要用数据库，新建一个系统，这些工作又要都搞一遍，即使其他系统已经做过了一遍，这样怎么快的起来？
2）系统交互一团乱麻：系统越来越多，各系统的交互关系变成了网状。系统间的交互数量和系统的数量成平方比的关系，例如4个系统的交互路径是6个，10个系统的交互路径是45个。每次实现一个业务需求，都需要几个甚至10几个系统一起改，然后互相调用来调用去，联调成了研发人员的灾难、联测成了测试人员的灾难、部署成了运维的灾难。
针对这个时期业务变化带来的问题，技术工作主要的解决有段有：
1）平台化、服务化：解决“重复造轮子”的问题。例如：
存储平台化：淘宝的TFS、京东JFS
数据库平台化：百度的DBProxy、淘宝TDDL
缓存平台化：Twitter的Twemproxy，豆瓣的BeansDB、腾讯TTC
2）消息队列、服务框架：解决“系统交互”的问题。例如：
消息队列：淘宝的Notify、MetaQ、开源的Kafka、ActiveMQ等
服务框架：Facebook thrift、阿里巴巴的Dubbo、当当网Dubbox、淘宝的HSF
【成熟期】
当企业熬过竞争期，成为了行业的领头羊，或者整个行业整体上已经处于比较成熟的阶段，市场地位已经比较牢固后，业务创新的机会已经不大，竞争压力也没有那么激烈，此时求快求新已经没有很大空间，业务上开始转向为“求精”：我们的响应时间是否比竞争对手快？我们的用户体验是否比竞争对手好？我们的成本是否比竞争对手低 ？。。。。。。等等。
此时技术上其实也基本进入了成熟期，该拆的也拆了，该平台化的也平台化了，技术上能做的大动作其实也不多了，更多的是进行优化。但有时候也会出现为了满足某个优化，系统做很大的改变这种情况。例如为了将用户响应时间从200ms降低到50ms，可能就需要从很多方面进行优化：CDN、数据库、网络等。这个时候的技术优化没有固定的套路，只能按照竞争的要求，找出自己的弱项，然后逐项优化。在逐项优化的时候，可以采取之前各个时期采用的手段。
用户规模
服务类业务的发展第二个主要方向就是“用户量越来越大”。
互联网业务的发展会经历“初创期、发展期、竞争期、成熟期”几个阶段，不同阶段典型的差别就是用户量的差别，简单来说就是用户量随着业务的发展而越来越大。
用户量增大对技术的影响主要体现在2个方面：性能要求越来越高、可靠性要求越来越高。
【性能】
用户量增大对技术带来的第一个挑战就是性能要求越来越高。以互联网企业最常用的MySQL为例，再简单的查询，再高的硬件配置，单台MySQL机器支撑的TPS和QPS最高也就是万级，低的可能是几千，高的也不过几万。当用户量增长后，必然要考虑使用多台MySQL，从一台MySQL到多台MySQL不是简单的数量的增加，而是本质上的改变，即：原来集中式的存储变为了分布式的存储。
稍微有经验的工程师都会知道，分布式将会带来复杂度的大幅度上升。以MySQL为例，分布式MySQL要考虑分库分表、读写分离、复制、同步等很多问题。
【可靠性】
用户量增大对技术带来的第二个挑战就是可靠性要求越来越高。当你有1万个用户的时候，宕机1小时可能也没有很大影响；但当你有了100万用户的时候，宕机10分钟，投诉电话估计就被打爆了，这些用户再到朋友圈喷一下你的系统有多烂，很可能你就不会再有机会发展下100万用户了。
除了口碑的影响，可靠性对收入的影响也会随着用户量增大而增大。1万用户宕机1小时，你可能才损失了几千块，100万用户宕机10分钟，损失可能就是几十万了。
虽然用户量增加给性能和可靠性带来了很大的挑战，但幸运的是，应对这些挑战的方式却可以概括为1个字“拆”，简单来说就是“一台不够拆为两台，两台不够拆为4台。。。。。。以此类推”。常见的拆的方式有：
拆硬件：数据库分库分表、业务处理分开到多个机器
拆地点：双机房部署、多机房部署、数据中心
拆功能：例如将购物系统拆分为登录认证子系统、订单系统、查询系统、分析系统等
如果你还记得前面业务复杂度里面讲到的一些手段的话，你一定会对这几个手段很熟悉。是的，这几个方式在应对复杂度的时候也可以用过。
当然，“拆”只是手段，“合”起来才是关键。不管我们的系统怎么拆，站在用户的角度，他都是理解为一个统一的业务。比如说，微信内部肯定分成了很多子系统，但用户并不需要理解这些，用户只管用微信即可。
常见合起来的手段有：
客户端“合”：Memcached的一致性hash
网络“合”：DNS、F5
系统“合”：Nginx负载均衡、LVS、中间件（淘宝的TDDL等）
业务“合”：单点登录
【质变】
究竟用户规模发展到什么阶段才会由量变带来质变，虽然不同的业务有所差别，但基本上可以按照如下这个模型去衡量。
阶段 | 用户规模 | 业务阶段 | 技术影响 |
婴儿期 | 0 ~ 1万 | 初创期 | 用户规模对性能和可靠性都没有什么压力，技术人员可以安心睡好觉。 |
幼儿期 | 1万 ~ 10万 | 初创期 | 用户规模对性能和可靠性已经有一点压力了，主要体现为单台机器（服务器、数据库）可能已经撑不住了，需要开始考虑拆分机器，但这个时候拆分还比较简单，因为机器数量不会太多。 |
少年期 | 10万 ~ 100万 | 发展期 | 用户规模对性能和可靠性已经有较大压力了，除了拆分机器，已经开始需要将原来大一统的业务拆分为更多子业务了。 |
青年期 | 100万 ~ 1000万 | 竞争期 | 用户规模对性能和可靠性已经有很大压力了，集群、多机房等手段需要开始用上了。 虽然如此，技术人员还是很Happy的，毕竟到了此时公司已经发展得非常不错了。 |
壮年期 | 1000万 ~ 1亿 | 竞争期 &成熟期 | 用户规模对性能和可靠性已经有非常大压力了，可能原有的架构和方案已经难以继续扩展下去，需要推倒重来。 不过如果你真的身处这样一个公司，虽然可能有点辛苦，但肯定会充满干劲，因为这样的机会非常难得也非常锻炼人！ |
巨人期 | 1亿 + | 成熟期 | 和壮年期类似，不过如果你真的身处这样一个公司，虽然可能有点辛苦，但估计做梦都要笑醒了！因为还没有哪个互联网行业能够同时容纳两家1亿+用户的公司。 |
总结
通过前面的分析，我们可以看到业务驱动技术发展的两大主要因素是复杂性和用户规模，而这两个因素的本质原因其实都是“量变带来质变”。
应对业务质变带来的技术压力，不同时期有不同的处理方式，但不管什么样的方式，其核心目标都是为了满足业务的“快”的要求，当你发现你的业务快不起来的时候，其实就是技术的水平已经跟不上业务发展的需要了，技术变革和发展的时候就到了。更牛逼的做法是在问题还没有真正暴露出来就能够根据趋势预测下一个转折点，提前做好技术上的准备，这对技术人员的要求是非常高的。
在应对复杂性和用户规模带来的技术压力时，“拆”是一种常见的的手段，可以拆系统、拆业务、拆机器、拆地点。。。。。。等等，总之一句话：哪里不满足就拆哪里！但拆容易，如何将拆完后的东西“合”起来才是关键。
除了“拆”以外，服务化、平台化是另外一种有效的手段，将公共的东西独立出来，避免重复造轮子，既节省了重复投入的人力和资源成本，也能够快速支撑新的业务的实施。
============================================================================================
转载注明出处：互联网技术发展之路（2）- 业务如何驱动技术发展
BAT解密：互联网技术发展之路（3）- 牛逼公司的技术架构都是这个范
大部分人对于BAT的技术有一种莫名的崇拜感，觉得只有非常牛逼和天才才能做出现在的这些系统，但经过前面两篇博文的分析，我们可以看到其实并没有什么神秘的力量和魔力融合在技术里面，而是业务的不断发展推动技术的不断发展，一步一个脚印，持续几年甚至10几年的发展，才能达到当前技术复杂度、先进性、牛逼度。
抛开BAT各自差异很大的业务，站在技术的角度来看，其实BAT的技术架构基本是一样的，再将视角放大，你会发现整个互联网行业的技术发展，最后都是殊途同归。
如果你正处于一个创业公司，或者正在成为另一个BAT的路上而拼搏，那么深入理解这种技术模式（或者叫技术结构、技术架构），对于自己的发展、公司的发展都大有裨益，你将不会再迷茫，你也不再会心里打鼓，CTO将对你刮目相看，CEO将奉你为神明 ：）
闲话不多说，有图有真相，看看互联网的标准技术架构是什么样子：
上面这张图基本上一网打尽了互联网技术公司的技术点，不同的公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范畴。
接下来的博文里，我将逐一介绍每个技术点，包括为什么会有这些技术点，这些技术点的主要场景是什么，这些技术点将如何发展。
================================================================================
转载请注明出处：BAT解密：互联网技术发展之路（3）- 牛逼公司的技术架构都是这个范
1. SQL
即关系数据。前几年NoSQL火了一阵子，很多人都理解为NoSQL是完全抛弃关系数据，全部采用非关系型数据，但事实经过几年的试验后，大家发现关系数据不可能完全抛弃，NoSQL不是No SQL，而是Not Only SQL，即NoSQL是SQL的补充。
所以互联网行业也必须依赖关系数据，考虑到Oracle太贵，还需要专人维护，一般情况下互联网行业都是用MySQL、PostgreSQL这类开源数据库。这类数据库的特点是开源免费，拿来就用；但缺点是性能相比商业数据库要差较多。随着互联网业务的发展，性能要求越来越高，必然要面对一个问题：将数据拆分到多个数据库实例才能满足业务的性能需求（其实Oracle也一样，只是时间早晚的问题）。
数据库拆分满足了性能的要求，但带来了复杂度的问题：数据如何拆分、数据如何组合。这个复杂度的问题解决起来并不是那么容易，如果每个业务都去实现一遍，重复造轮子将导致投入浪费、效率降低，业务开发想快都快不起来。
所以互联网公司流行的做法是发展到一定阶段后，就会将这部分功能独立成中间件，例如百度的DBProxy、淘宝的TDDL。不过这部分的要求很高，将分库分表做到自动化和平台化，不是一件容易的事情，所以一般是很牛逼的公司才会做。典型的有：百度的DBProxy、淘宝TDDL
如下是淘宝TDDL的结构图：
2. NoSQL
NoSQL首先体现在数据结构上与传统的SQL的不同，例如典型的memcache的Key-value结构、Redis的复杂数据结构、MongoDB的文档数据结构；其次NoSQL无一例外的都会将性能作为自己的一大买点。
NoSQL的这两个特点很好的弥补了关系数据库的不足，因此在互联网行业NoSQL的应用基本上是基础要求，要是你听到一个号称自己是互联网公司却连NoSQL都没用，那基本上可以判断是挂羊头卖狗肉类型的。
由于NoSQL方案一般都会自己本身就提供集群的功能，例如memcache的一致性hash集群、Redis 3.0的集群，因此NoSQL在刚开始应用的时候很方便，不像SQL分库分表那么复杂。一般公司也不会在开始的时候就考虑将NoSQL包装成存储平台，但如果公司发展很大，例如memcache的节点有上千甚至几千的时候，NoSQL集群就很有意义了：首先是集中管理能够大大提升运维效率；其次是集中管理可以大大提升资源利用效率，2000台机器，如果利用率能提升10%，就是减少200台机器，一年几十万就节省出来了。
所以，NoSQL发展到一定规模后，一般都是走集群路线，当然要发展到这个阶段，一般也是很牛逼的公司才会这么做。
典型的有：Twitter的Twemproxy，豆瓣的BeansDB、腾讯TTC
如下是Twemproxy的结构图：
3. 小文件存储
除了关系型的业务数据外，互联网行业还有很多用于展示的数据，例如淘宝的商品图片、商品描述；Facebook的用户图片，新浪微博的一条微博内容等等。这些数据具有3个典型特征：一是数据小，一般在1M一下；二是数量巨大，Facebook 2013年就达到了每天上传3.5亿张的照片；三是访问量巨大，Facebook每天的访问量超过10亿。
由于互联网行业基本上每个业务都会有大量的小数据，如果每个业务都自己去考虑如何设计海量存储和海量访问，效率自然会低，重复造轮子，投入浪费，自然而然的想法就是将小文件存储做成统一的和业务无关的平台。
和SQL和NoSQL不同的是，小文件存储不一定需要公司或者业务规模很大，基本上可以认为业务在起步阶段就可以考虑做小文件统一存储。得益于开源运动的发展和最近几年大数据的火爆，在开源方案的基础上封装一个小文件存储平台并不是太难的事情。例如HBase、Hadoop、Hypertable、FastDFS等都可以作为小文件存储的底层平台，只需要在这些开源方案三再包装一下基本上就可以用了。
典型的有：淘宝的TFS、京东JFS、Facebook的Haystack
如下是淘宝TFS的架构：
4. 大文件存储
互联网行业的大文件主要分为两类：一类是业务上的大数据，例如Youtube的视频，电影网站的电影；一类是海量的日志数据，例如各种访问日志、操作日志、用户轨迹日志等。和小文件的特点正好相反，大文件的数量没有小文件那么多，但每个文件都很大，几百M几G都是常见的，几十G，几T也是有可能的，因此在存储上和小文件有较大差别，不能直接将小文件存储系统拿来存储大文件。
说道大文件，不得不特别要提到Google和Yahoo，Google的3篇大数据论文（Bigtable/Map-Reduce/GFS）开启了一个大数据的时代，而Yahoo开源的Hadoop系列（HDFS、HBase。。。。。。），基本上垄断了开源界的大数据处理，当然，江山代有人才出，长江后浪推前浪，Hadoop后又有更多优秀的开源方案贡献出来，现在随便走到大街上拉住一个程序员，如果他不知道大数据，那基本上可以确定是火星程序员 ：）
对照Google的论文构建一套完整的大数据处理方案难度和成本实在太高，而且开源方案现在也很成熟了，所以大数据存储和处理这块反而是最简单的，因为你别无选择，只能用这几个流行的开源方案。例如：Hadoop、HBase、Storm、Hive等。
如下是Hadoop的生态圈：
========================================================================
转载请注明出处：BAT解密：互联网技术发展之路（4）- 存储层技术剖析
BAT解密：互联网技术发展之路（5）- 开发层技术剖析
1. 开发框架
在系列文章的第2篇“BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术，将会带来很多问题，典型的问题有：
1）技术人员之间没有共同的技术语言，交流合作少
2）每类技术都需要投入大量的人力和资源和熟练精通
3）不同团队之间人员无法快速流动，人力资源不能高效的利用
所以，互联网公司都会指定一个大的技术方向，然后使用统一的开发框架，例如Java相关的开发框架SSH、SpringMVC、Play，Ruby的Ruby on Rails，PHP的ThinkPHP，Python的Django等等。使用统一的开发框架能够解决上面提到的各种问题，大大提升组织和团队的开发效率。
对于框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术！为什么呢？
首先，成熟的框架资料文档齐备，各种坑基本上都有人踩过了，遇到问题很容易通过搜索解决
其次，成熟的框架受众更广，招聘时更加容易招聘到合适的人才
第三，成熟的框架更加稳定，不会出现大的变动，适合长期发展
以我亲身经历的一个反例为例：我们使用了Play 1作为Java开发框架，因为它是轻量级的Java开发框架，但没想到Play 2直接改为scala语言开发，Play 1的架构演进停滞，而我们又不能切换为Play 2，结果就导致只能一直用Play 1，有新的需求只能自己开发。
2. 服务器
开发框架只是负责完成业务功能的开发，真正能够运行起来，给用户提供服务，还需要服务器配合。
独立开发一个成熟的web服务器，成本非常高；且业界又有那么多成熟的开源web服务器，所以互联网行业基本上都是拿来主义，挑选一个流行的开源服务器即可。牛逼一点的公司，可能会在开源服务器的基础上，结合自己的业务特点做二次开发，例如淘宝的Tengine，但一般公司基本上只需要将开源服务器摸透，优化一下参数，调整一下配置就差不多了。
选择一个服务器主要和开发语言相关，例如：java的有Tomcat、Jboss、Resin等，php/python的用nginx，当然最保险的就是用apache了，什么语言都支持。
有的人可能担心apache的性能之类的问题，其实不用过早担心这个，等到你的业务真的发展到apache撑不住的时候再考虑切换也可以，那时候你有的是钱，有的是人，有的是时间。
3. 容器
容器是最近2年才开始火起来的，其中以docker为代表，在BAT级别的公司已经有较多的应用，例如腾讯：腾讯万台规模的Docker应用实践；新浪微博：微博红包：大规模Docker集群实践经验分享 等等。
传统的虚拟化技术是虚拟机，解决了跨平台的问题，但由于虚拟机太庞大，启动慢，运行时太占资源，在互联网行业并没有大规模的应用；而docker的容器技术，虽然没有跨平台，但启动快，几乎不占资源，推出后立刻就火起来了，预计docker类的容器技术将是技术发展的主流方向。
千万不要以为docker只是一个虚拟化或者容器技术，它将在很大程度上改变我们目前的技术形势：
1）运维方式会发生革命性的变化：docker启动快，几乎不占资源，随时启动和停止，基于docker打造自动化运维、智能化运维将成为主流方式
2）设计模式会发生本质化的变化：启动一个新的容器实例代价如此低，将鼓励设计思路朝“微服务”的方向发展。
例如一个传统的网站包括登录注册、页面访问、搜索等功能，没有用容器的情况下，除非有特别大的访问量，否则这些功能开始时都是集成在一个系统里面的；有了容器技术后，一开始设计就可以将这些功能按照服务的方式设计，避免后续访问量增大时又要重构系统。
转载请注明出处：BAT解密：互联网技术发展之路（5）- 开发层技术剖析