vlambda博客
学习文章列表

前面已经介绍过使用单台服务器，安装apache+mysql或者tomcat+mysql构建网站服务。但是单台服务器承载服务，存在性能瓶颈，而且业务连续性无法得到保障，一旦单台服务器故障，业务就会瘫痪，可靠性与可用性不足。

为此，从性能角度，必须把不同的服务拆分到不同的服务器进行部署。从业务可用性、可靠性、连续性角度，必须为服务器构建高可用集群或者负载均衡集群。

关于网站服务的基础架构是如何演进的，可以参考《淘宝技术这十年》这本书。

另外网上也有一篇文章，也是讲述淘宝服务端的架构演进之路的，与上面书籍有讲述同样的内容。（但是文章的首发人不太清楚是不是这位，仅供参考，侵权删除）

单台服务器通过lamp或者tomcat+数据库等方式（还有很多，例如windows server的IIS+SQL Server，python+django/flask+mariadb等都是可以的）构建网站服务器，与之前的文章已经介绍过的方式无异。

考虑性能问题，可以在上述基础上，将Mysql找单独的服务器进行安装。WEB服务器仅用于用户的网页请求响应，由WEB服务器向数据库服务器发起后台数据库的增删改查请求，数据库进行完相关操作之后将结果返回给WEB服务器，WEB服务器再将结果返回给用户。

服务分离仅解决了少量的性能问题，但是无论是WEB还是Mysql服务器单机故障，都会导致整个网站无法访问。为了提高网站的可用性，避免单点故障，还需要对WEB服务器与数据库服务器进行高可用/负载均衡改造。

注意高可用与负载均衡不是一个概念，而集群是另外一个泛指的概念，集群可以是高可用集群，也可以是负载均衡集群。

高可用（HA-High Availability）：指双机/多机热备。业务正常情况下，仅有单台机器对外提供服务。如果是双机热备，那么平常就只有1台主机对外提供服务。仅当该主机故障，业务会自动切换到由备机对外提供服务，因此主机的利用率是50%。

注意，HA为什么只做双机呢，因为HA正常情况下仅能一台机器对外提供服务，就算你100台主机组成一个HA集群，同时也仅能一台对外提供服务，主机越多，利用率就越低（100台就是一百分之一）。因此如果有100台主机，又非要做HA，正确的做法是做50个双机集群，每个HA集群利用率都是50%。

负载均衡（Load Balance）：指双机/多机通过一个统一的虚拟IP，同时对外提供服务。在用户侧永远都是通过统一的入口访问（同一个虚拟IP/域名），但是用户访问的请求会自动分摊到负载均衡集群内的每台主机。负载均衡的方式可能是基于负载、基于当前服务器的资源利用率，会话连接数等。负载均衡软件会根据设定好的策略自动平衡。

根据上述分析，要提高网站的可用性，首先起码WEB服务器最低限度要做到HA高可用。

Linux可以通过安装Keepalived软件，编写httpd服务的检测脚本，并且配置虚拟IP（VIP），来做WEB服务器的HA。

注意，用户通过VIP访问业务，正常情况下，仅有Apache01对外提供服务，仅当Apache01故障，业务才会自动切换到Apache02。用户侧依然通过VIP访问，对故障切换没有感知。

为把两台Apache的资源都利用起来，HA肯定是无法满足的，因此一般不会对WEB服务器做HA，而是将两台Apache配置为负载均衡的。

通过服务器额外安装LVS或者Nginx或者使用专门的负载均衡硬件（如F5、A10、Radware的硬件负载均衡器），以及配置VIP，可以实现WEB服务器的负载均衡。

用户通过VIP访问业务，流量会自动分摊到Apche01与Apache02，任何一台主机故障，都不会中断业务。

LVS仅能做4层的负载均衡，也就是基本上只能针对IP五元组，端口号等进行流量的负载均衡转发。而Nginx可以做到7层的负载均衡，即可以连应用层的流量都做负载均衡，例如针对访问视频、图片等流量的负载均衡转发。

然而采用x86服务器+软件的方式，最大的BUG是，又带来了负载均衡服务器的单点故障问题。因此Nginx/LVS服务器又要按照高可用/负载均衡的方式配置。前面已经说过，对于单个应用可以采用keepalive进行高可用配置，但是无法做到负载均衡。

因此Nginx服务器的高可用通过keepalived来保障，然后Nginx服务器的负载均衡通过LVS来保障，架构如下：

而LVS服务器，可以通过keepalived进行高可用配置，而负载均衡，则不再在已有的LVS服务器前面，再增加LVS服务器了。而是可以对2台LVS服务器，配置为互为主备。

VIP1-->LVS01（主）-->LVS02（备）

VIP2-->LVS02（主）-->LVS01（备）

然后通过DNS设置域名轮询多个VIP，用户通过域名访问业务，而DNS对两个VIP进行负载均衡分发，从而实现LVS服务器的HA+负载均衡。

数据库服务器与WEB服务器不一样。WEB服务器用户的访问相当于无状态的，访问失败大不了就重新发起一次请求，而数据库要严格保障数据的一致性的，不能简单做负载均衡。否则例用户到银行存款，第一次访问分配的是Mysql01，存款时写入了数据。用户发起余额查询，第二次访问分配的是Mysql02，但是由于Mysql02没有这个数据，用户查询余额的时候提示存款没有了。用户再次发起余额查询，第三次访问分配的是Mysql01，又说余额有了，这样是会让人崩溃的。

因此，数据库采用其他的机制，进行高可用/负载均衡配置。

Mysql自带主从复制的功能，可以配置主库向备库复制。对Mysql01的写入数据全部会同步到Mysql02。但是主从复制只是复制，仅仅是保障了数据没有丢失，并没有VIP配置的。

因此WEB服务器连接数据库的配置文件，都是连接Mysql01的，一旦Mysql01故障，还需要手动修改连接数据库配置文件连接到Mysql02，才能恢复业务。这就相当于要人工7*24小时on call，随时准备做手工切换，是非常不科学的。

并且主从复制，业务正常状态下也是仅有一台mysql服务器对外提供服务，性能存在瓶颈。

为解决单台mysql性能瓶颈与手工切换的问题，可以启用Mysql的主主复制功能，双向配置主从复制。

Mysql01（主）-->Mysql02（从）

Mysql01（从）<--Mysql02（主）

然后Apache01连接Mysql01，Apache02连接Mysql02。

这样用户访问WEB，负载均衡到Apache01的用户，会访问Mysql01数据库，负载均衡到Apache02的用户，会访问Mysql02数据库，所有机器正常运行的情况下，资源全部利用起来了。

而一旦Mysql01、02其中一台故障，分摊到Apache01的用户访问业务会失败，但是起码保障了50%访问Apache02的用户，业务不受影响，因此数据库服务器单机故障，仅有50%用户无法访问业务，减少了故障影响范围，但是仍然有一半的用户受影响。

而单台数据库故障后，需要修改连接该数据库的WEB服务器配置文件，重新连接到存活的数据库服务器。

综合考虑，可以采用Mysql自带的主主复制，加上安装keepalived软件，配置VIP，编写脚本检测mysql服务是否正常。一旦检测到mysql服务停止，则将VIP切换到备用数据库服务器。

而WEB服务器因为是通过VIP连接数据库的，因此主、备数据库切换，并不需要手动修改配置文件，业务自动恢复。

注意是要使用主主复制，不是主从复制，否则一旦主备切换之后，有任何的写入数据，当主节点恢复，VIP重新从备节点重新切换回主节点的时候，就会丢失主节点故障期间的写入数据。

缺点是数据库服务器仅是HA，业务正常情况下，仅有单台对外提供服务，性能存在瓶颈。优点是提高了数据库的可用性，并且解决了手动切换的问题。

为了解决上面遗留的性能瓶颈问题，可以对Mysql配置读写分离。读写分离需要使用第三方软件，例如MyCat。

通过安装Mycat，配置VIP，并且配置读写分离，WEB服务器通过VIP连接数据库，写数据库的操作都会自动分发到Mysql01，读的操作根据设定的规则，负载均衡到Mysql01、02。因为大部分网站的读写操作基本上都是80:20分配的，用户的读操作远大于写操作。因此一旦读性能不足，可以在集群里面添加Mysql服务器，即可扩容读数据库的性能，实现ScaleOut的横向平滑扩展。

读写分离能够解决读性能不足，但是写性能还是有单机来承载的。除了Oracle Rac能够集群多读读写，Mysql、SQL Server等数据库技术上是做不到的，需要通过折衷的方法来解决，就是分表分库。

如上图，就是将一张表格分片，然后将表格的第一部分放进节点1的数据库来承载，第二部分放进节点2的数据库来承载。

用户查询或者插入表格的时候，Mycat会自动打散这些操作到节点1与节点2的数据库，变相进行了写入节点的增加。

通过上述的手段，基本上解决了可用性的问题（web也能负载均衡，数据库也能负载均衡了），性能也得以极大程度上的加强。但是如果性能还是无法满足业务的需求，那么其实应该从业务层面，进行业务的垂直拆分。例如将电商的系统拆分为支付业务子系统、商品业务子系统等，然后对每个子系统内进行高可用/负载均衡架构构建。

通过公网DNS，对多个数据中心的VIP设置轮询，实现多个数据中心的负载均衡。并且智能DNS能够对VIP的存活进行检测，一旦VIP不可达，则认为数据中心故障，不再将流量分发。而且还能够做到对用户终端的IP识别后，将域名解析为用户所在电信运营商且离用户最近的数据中心的VIP返回给用户，实现用户的就近访问。