在介绍架构之前，为了防止局部读者对架构设计中的一些概念不理解，上面对几个最根底的概念进行介绍。

1）什么是分布式？

零碎中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库别离部署在不同的服务器上，或两个雷同性能的Tomcat别离部署在不同服务器上。

2）什么是高可用？

零碎中局部节点生效时，其余节点可能接替它持续提供服务，则可认为零碎具备高可用性。

3）什么是集群？

一个特定畛域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。

如Zookeeper中的Master和Slave别离部署在多台服务器上，独特组成一个整体提供集中配置服务。

在常见的集群中，客户端往往可能连贯任意一个节点取得服务，并且当集群中一个节点掉线时，其余节点往往可能主动的接替它持续提供服务，这时候阐明集群具备高可用性。

4）什么是负载平衡？

申请发送到零碎时，通过某些形式把申请平均散发到多个节点上，使零碎中每个节点可能平均的解决申请负载，则可认为零碎是负载平衡的。

5）什么是正向代理和反向代理？

零碎外部要拜访内部网络时，对立通过一个代理服务器把申请转发进来，在内部网络看来就是代理服务器发动的拜访，此时代理服务器实现的是正向代理；

当内部申请进入零碎时，代理服务器把该申请转发到零碎中的某台服务器上，对外部申请来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。

简略来说，正向代理是代理服务器代替零碎外部来拜访内部网络的过程，反向代理是内部申请拜访零碎时通过代理服务器转发到外部服务器的过程。

以淘宝作为例子：在网站最后时，利用数量与用户数都较少，能够把Tomcat和数据库部署在同一台服务器上。浏览器往发动申请时，首先通过DNS服务器（域名零碎）把域名转换为理论IP地址10.102.4.1，浏览器转而拜访该IP对应的Tomcat。

架构瓶颈：随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以撑持业务。

第一次演进：Tomcat与数据库离开部署

Tomcat和数据库别离独占服务器资源，显著进步两者各自性能。

架构瓶颈：随着用户数的增长，并发读写数据库成为瓶颈。

第二次演进：引入本地缓存和分布式缓存

在Tomcat同服务器上或同JVM中减少本地缓存，并在内部减少分布式缓存，缓存热门商品信息或热门商品的html页面等。通过缓存能把绝大多数申请在读写数据库前拦挡掉，大大降低数据库压力。其中波及的技术包含：应用memcached作为本地缓存，应用Redis作为分布式缓存，还会波及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中生效等问题。

架构瓶颈：缓存抗住了大部分的拜访申请，随着用户数的增长，并发压力次要落在单机的Tomcat上，响应逐步变慢。

第三次演进：引入反向代理实现负载平衡

在多台服务器上别离部署Tomcat，应用反向代理软件（Nginx）把申请平均散发到每个Tomcat中。此处假如Tomcat最多反对100个并发，Nginx最多反对50000个并发，那么实践上Nginx把申请散发到500个Tomcat上，就能抗住50000个并发。

其中波及的技术包含：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，次要反对http协定，还会波及session共享、文件上传下载的问题。

架构瓶颈：反向代理使应用服务器可反对的并发量大大增加，但并发量的增长也意味着更多申请穿透到数据库，单机的数据库最终成为瓶颈。

第四次演进：数据库读写拆散

把数据库划分为读库和写库，读库能够有多个，通过同步机制把写库的数据同步到读库，对于须要查问最新写入数据场景，可通过在缓存中多写一份，通过缓存取得最新数据。其中波及的技术包含：Mycat，它是数据库中间件，可通过它来组织数据库的拆散读写和分库分表，客户端通过它来拜访上层数据库，还会波及数据同步，数据一致性的问题。即时通讯聊天软件开发能够征询蔚可云开发。

架构瓶颈：业务逐步变多，不同业务之间的访问量差距较大，不同业务间接竞争数据库，相互影响性能。

第五次演进：数据库按业务分库

把不同业务的数据保留到不同的数据库中，使业务之间的资源竞争升高，对于访问量大的业务，能够部署更多的服务器来撑持。这样同时导致跨业务的表无奈间接做关联剖析，须要通过其余路径来解决，但这不是本文探讨的重点，有趣味的能够自行搜寻解决方案。

架构瓶颈：随着用户数的增长，单机的写库会逐步会达到性能瓶颈。

第六次演进：把大表拆分为小表

比方针对评论数据，可依照商品ID进行hash，路由到对应的表中存储；针对领取记录，可依照小时创立表，每个小时表持续拆分为小表，应用用户ID或记录编号来路由数据。只有实时操作的表数据量足够小，申请可能足够平均的散发到多台服务器上的小表，那数据库就能通过程度扩大的形式来进步性能。其中后面提到的Mycat也反对在大表拆分为小表状况下的访问控制。

这种做法显著的减少了数据库运维的难度，对DBA的要求较高。数据库设计到这种构造时，曾经能够称为分布式数据库，然而这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件独自来实现的，如分库分表的治理和申请散发，由Mycat实现，SQL的解析由单机的数据库实现，读写拆散可能由网关和音讯队列来实现，查问后果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。

目前开源和商用都曾经有不少MPP数据库，开源中比拟风行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、华为的LibrA等等，不同的MPP数据库的侧重点也不一样，如TiDB更侧重于分布式OLTP场景，Greenplum更侧重于分布式OLAP场景，这些MPP数据库根本都提供了相似Postgresql、Oracle、MySQL那样的SQL规范反对能力，能把一个查问解析为分布式的执行打算散发到每台机器上并行执行，最终由数据库自身汇总数据进行返回，也提供了诸如权限治理、分库分表、事务、数据正本等能力，并且大多可能反对100个节点以上的集群，大大降低了数据库运维的老本，并且使数据库也可能实现程度扩大。

架构瓶颈：数据库和Tomcat都可能程度扩大，可撑持的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈。

第七次演进：应用LVS或F5来使多个Nginx负载平衡

因为瓶颈在Nginx，因而无奈通过两层的Nginx来实现多个Nginx的负载平衡。图中的LVS和F5是工作在网络第四层的负载平衡解决方案，其中LVS是软件，运行在操作系统内核态，可对TCP申请或更高层级的网络协议进行转发，因而反对的协定更丰盛，并且性能也远高于Nginx，可假如单机的LVS可反对几十万个并发的申请转发；F5是一种负载平衡硬件，与LVS提供的能力相似，性能比LVS更高，但价格昂贵。因为LVS是单机版的软件，若LVS所在服务器宕机则会导致整个后端系统都无法访问，因而须要有备用节点。可应用keepalived软件模拟出虚构IP，而后把虚构IP绑定到多台LVS服务器上，浏览器拜访虚构IP时，会被路由器重定向到实在的LVS服务器，当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，把虚构IP重定向到另外一台失常的LVS服务器，从而达到LVS服务器高可用的成果。

此处须要留神的是，上图中从Nginx层到Tomcat层这样画并不代表全副Nginx都转发申请到全副的Tomcat，在理论应用时，可能会是几个Nginx上面接一部分的Tomcat，这些Nginx之间通过keepalived实现高可用，其余的Nginx接另外的Tomcat，这样可接入的Tomcat数量就能成倍的减少。

架构瓶颈：因为LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户散布在不同的地区，与服务器机房间隔不同，导致了拜访的提早会显著不同。