1.1. 淘宝现状
高并发已经成为当前互联网企业面临的巨大挑战！例如2015年“双十一”全球狂欢节正式落下帷幕，天猫最终交易额也达到了创纪录的912.17亿元！参与交易国家和地区达到232个，双十一支付宝最高峰每秒处理的交易笔数是8.59万笔，在线人数峰值达到4500万。
淘宝的核心技术（国内乃至国际的Top，这还是2011年的数据）
拥有全国最大的分布式Hadoop集群（云梯，2000左右节点，24000核CPU，48000GB内存，40PB存储容量）
全国分布80+CDN节点，能够自动找寻最近的节点提供服务，支持流量超过800Gbps
不逊于百度的搜索引擎，对数十亿商品进行搜索，全球最大的电商平台
顶尖的负载均衡系统，顶尖的分布式系统，顶尖的互联网思想，功能多样运行极其稳定
丰富的生态产业以及先进的数据挖掘技术
……很多很多
1.2. 淘宝技术演变，摘自《淘宝技术这十年》
马总在2003年4月7日秘密叫来阿里巴巴的十位员工，来到杭州一个隐秘的毛坯房，要求他们在一个月左右的时间内做出一个C2C网站。结果当然还是直接买的快，一个基于LAMP架构的网站，原名是PHPAuction，老美开发的一个拍卖网站。当然必须要做修改才能用。
2003年底，淘宝注册用户23万，PV 31万/day，半年成交额3371万
很显然MySQL无法撑得起如此大的访问量，数据库瓶颈出现了。幸好阿里的DBA队伍足够强大，他们使用Oracle替代了MySQL。Oracle那时就已经有了强大的并发性访问设计——连接池，从连接池取连接的耗费比单独建立连接少很多。但是PHP当时并没有官方提供支持语言连接池特性，于是多隆前辈用Google（不会是Baidu）搜到了一个开源的SQL Relay，于是数据库软件方面的瓶颈暂时解决了。
随之而来的是面临硬件性能瓶颈，阿里买了EMC的SAN存储设备，加上Oracle高性能RAC，硬件容量也暂时没问题了。
因为SQL Relay的问题实在过于严重，2004年于是淘宝终于做出了跨时代的决策——使用Java重写网站。
淘宝请了Sun的高级工程师来帮忙做Java架构。那么他们是如何做到修改编程语言而不改变网站使用呢——模块化替换，今天写好了A模块，另开一个新域名，将连接指向该模块，同时别的模块不变，等到全部模块完成的时候，原域名放弃。Sun公司坚持使用EJB作为控制层，加上使用iBatis作为持久层，一个可扩展且高效的Java EE应用诞生了。
送走Sun的大牛们之后，阿里的数据存储又遇到了瓶颈，于是忍痛买了一台IBM小型机，也就有了IOE（IBM + Oracle + EMC）这样的传说
2004年底，淘宝注册用户400万，PV 4000万/day，全网成交额10个亿。
2005年Spring诞生了，早闻Spring框架在Web应用不可或缺，而在淘宝网，Spring也达到了Rod Johnson设计它的目的——替代EJB。
2005年底，淘宝注册用户1390万，PV 8931万/day，商品数目1663万个。
考虑到未来的发展，这样的设施架构只是勉强可以应付现在的要求。于是，CDN技术派上用场了，一开始使用商用的ChinaCache，后来使用章文嵩博士搭建低耗能CDN网络，淘宝网的性能越来越好了。
2006年底，淘宝注册用户3000万，PV 15000万/day，商品数目5000万，全网成交额169亿元。
淘宝在2007年之前，使用NetApp的商用存储系统，但是仍然不够应付迅速增长的趋势。同年Google公布了GFS的设计思想，参照它的思想，淘宝也开发了自己的文件系统——TFS每个用户在TFS上拥有1GB的图片存储空间，这些都得益于TFS集群的文件存储系统以及大量的图片服务器。淘宝使用实时生成缩率图，全局负载均衡以及一级和二级缓存来保证图片的访问优化与高效访问。
淘宝的服务器软件使用Tengine，一个被优化过的nginx模块。
淘宝分离出了UIC（User Information Center），供所有模块调用。多隆前辈再次为其编写出了TDBM，完全是基于内存的数据缓存（参考了memcached）。再然后，淘宝将TBstore和TDBM合并，写出了Tair，一个基于Key-Value的分布式缓存数据系统。然后升级了自己的iSearch系统。
2007年底，淘宝注册用户5000万，PV 25000万/day，商品数目1个亿，全网成交额433亿元。
...
Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架，每天为2000+ 个服务提供3,000,000,000+ 次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用。
2. 技术发展历程总结2.1. 单节点架构
2.2. 集群架构
2.3. 集群+分布式架构
一、正向代理(Forward Proxy) （图1.1） 从上面的概念中，我们看出，文中所谓的正向代理就是代理服务器替代访问方【用户A】去访问目标服务器【服务器B】 这就是正向代理的意义所在。而为什么要用代理服务器去代替访问方【用户A】去访问服务器B呢？这就要从代理服务器使用的意义说起。
使用正向代理服务器作用主要有以下几点： 1、访问本无法访问的服务器B，如下图1.2
（图1.2） 我们抛除复杂的网络路由情节来看图1.2，假设图中路由器从左到右命名为R1,R2假 设最初用户A要访问服务器B需要经过R1和R2路由器这样一个路由节点，如果路由器R1或者路由器R2发生故障，那么就无法访问服务器B了。但是如果用户 A让代理服务器Z去代替自己访问服务器B，由于代理服务器Z没有在路由器R1或R2节点中，而是通过其它的路由节点访问服务器B，那么用户A就可以得到服 务器B的数据了。现实中的例子就是“FQ”。不过自从VPN技术被广泛应用外，“FQ”不但使用了传统的正向代理技术，有的还使用了VPN技术。
（图1.3）图 1.3防火墙作为网关，用来过滤外网对其的访问。假设用户A和用户B都设置了代理服务器，用户A允许访问互联网，而用户B不允许访问互联网（这个在代理服 务器Z上做限制）这样用户A因为授权，可以通过代理服务器访问到服务器B，而用户B因为没有被代理服务器Z授权，所以访问服务器B时，数据包会被直接丢 弃。
（图1.4） 我 们总结一下 正向代理是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内 容返回给客户端。客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。 （图2.1）
用户A始终认为它访问的是原始服务器B而不是代理服务器Z，但实用际上反向代理服务器接受用户A的应答，从原始资源服务器B中取得用户A的需求资源，然后发送给用户A。由于防火墙的作用，只允许代理服务器Z访问原始资源服务器B。尽管在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器B，但用户A并不知情。 2、负载均衡如下图2.2 （图2.2） 当反向代理服务器不止一个的时候，我们甚至可以把它们做成集群，当更多的用户访问资源服务器B的时候，让不同的代理服务器Z（x）去应答不同的用户，然后发送不同用户需要的资源。 当然反向代理服务器像正向代理服务器一样拥有CACHE的作用，它可以缓存原始资源服务器B的资源，而不是每次都要向原始资源服务器B请求数据，特别是一些静态的数据，比如图片和文件，如果这些反向代理服务器能够做到和用户X来自同一个网络，那么用户X访问反向代理服务器X，就会得到很高质量的速度。这正是CDN技术的核心。如下图2.3 （图2.3） 我们并不是讲解CDN，所以去掉了CDN最关键的核心技术智能DNS。只是展示CDN技术实际上利用的正是反向代理原理这块。
反向代理结论与正向代理正好相反，对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间(name-space)中的内容发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端，就像这些内容原本就是它自己的一样。 基本上，网上做正反向代理的程序很多，能做正向代理的软件大部分也可以做反向代理。开源软件中最流行的就是squid，既可以做正向代理，也有很多人用来做反向代理的前端服务器。另外MS ISA也可以用来在WINDOWS平台下做正向代理。反向代理中最主要的实践就是WEB服务，近些年来最火的就是Nginx了。网上有人说NGINX不能做正向代理，其实是不对的。NGINX也可以做正向代理，不过用的人比较少了。
（图3.1） 用户A和用户B并不知道行为管理设备充当透明代理行为，当用户A或用户B向服务器A或服务器B提交请求的时候，透明代理设备根据自身策略拦截并修改用户A或B的报文，并作为实际的请求方，向服务器A或B发送请求，当接收信息回传，透明代理再根据自身的设置把允许的报文发回至用户A或B，如上图，如果透明代理设置不允许访问服务器B，那么用户A或者用户B就不会得到服务器B的数据。 |
|
|
1.1. 反向代理
反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
1.2. 负载均衡
负载均衡，英文名称为Load Balance，是指建立在现有网络结构之上，并提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。其原理就是数据流量分摊到多个服务器上执行，减轻每台服务器的压力，多台服务器共同完成工作任务，从而提高了数据的吞吐量。
