基于负载均衡的服务端设计

最近在忙后台的搭建，用户量在10W左右，时间比较赶，决定采用负载均衡、服务器集群的方式。原理图如下：

当然这只是一个简单的第一代版本。完整的架构还包括， 负载均衡集群、数据库集群、业务服务器与 数据库之间还有一层缓存、负载均衡与业务服务器之间有个中间层， 以及覆盖整个系统的日志管理、权限管理、容灾管理、安全管理等等。系统的复杂度是随着用户量而动态改变的。在目前先采取 一台负载均衡服务器 + 两台业务服务器 + 一台数据库服务器的架构。

准备条件：
负载均衡服务器/业务服务器 ： 8核 16G 50M ubuntu16.04
数据库服务器: 16核 16G 50M ubuntu16.04

跨多个应用程序实例的负载平衡是优化资源利用率、最大化吞吐量、减少延迟和确保容错配置的常用技术。
可以使用nginx作为一个非常有效的HTTP负载平衡器来将流量分布到多个应用程序服务器，并通过nginx改进web应用程序的性能、可伸缩性和可靠性。如下图所示：

Nginx的作用尤为重要，做为负载均衡的核心！看看Nginx负载平衡方法

在nginx中支持以下负载平衡机制:
对应用程序服务器的请求以循环方式进行分发，
最不连接的下一个请求被分配给服务器的活动连接最少，
一个hash- function用于确定应该为下一个请求选择什么服务器(基于客户机的IP地址)。

默认的负载平衡配置
与nginx的负载平衡最简单的配置如下:

http {    upstream myapp1 {        server srv1.example.com;        server srv2.example.com;        server srv3.example.com;    }    server {        listen 80;        location / {            proxy_pass http://myapp1;        }    }}

在上面的示例中，在srv1 - srv3上运行的相同应用程序有3个实例。当没有特别配置负载平衡方法时，它默认为循环。所有请求都被发送到服务器组myapp1,nginx应用HTTP负载平衡来分发请求。nginx中的反向代理实现包括HTTP、HTTPS、FastCGI、uwsgi、SCGI和memcached的负载平衡。为了将负载均衡配置为HTTPS而不是HTTP，只需使用“HTTPS”作为协议。在为FastCGI、uwsgi、SCGI或memcached设置负载平衡时，分别使用fastcgi_pass、uwsgi_pass、scgi_pass和memcached_pass指令。

至少连接负载均衡

另一个负载平衡规则是最小连接的。在某些请求需要更长的时间完成时，最不相关的允许在应用程序实例上更公平地控制负载。使用最少连接的负载平衡，nginx将尽量不让繁忙的应用服务器超载，而将新请求分发给更少的服务器。nginx中最小连接的负载平衡是在最小_conn指令被用作服务器组配置的一部分时被激活的:

 upstream myapp1 {        least_conn;        server srv1.example.com;        server srv2.example.com;        server srv3.example.com;    }

会话持久性

对于循环或最小连接的负载均衡，每个后续客户机的请求可能会被分配到不同的服务器。不能保证同一客户端将总是指向同一服务器。如果需要将客户端绑定到某个特定的应用程序服务器——换句话说，就是让客户机的会话“粘”或“持久”，就总是试图选择某个特定的服务器——可以使用ip- hash负载平衡机制。使用ip- hash，客户机的IP地址用作散列键，以确定应该为客户机的请求选择服务器组中的哪个服务器。此方法确保来自同一客户端的请求将始终指向相同的服务器，除非此服务器不可用。
要配置ip- hash负载平衡，只需将ip_hash指令添加到服务器组配置，这也是我才用的方式:

upstream myapp1 {    ip_hash;    server srv1.example.com;    server srv2.example.com;    server srv3.example.com;}

加权负载平衡

通过使用服务器权重来进一步影响nginx负载平衡算法。在上面的示例中，没有配置服务器权重，这意味着所有指定的服务器都被视为相同的负载均衡方法。特别是循环，它还意味着在服务器上的请求的分布更均匀——只要有足够的请求，并且当请求以统一的方式处理和完成的速度足够快。当为服务器指定权重参数时，权重作为负载平衡决策的一部分。

 upstream myapp1 {        server srv1.example.com weight=3;        server srv2.example.com;        server srv3.example.com;    }

有了这个配置，每5个新请求将会被分发到应用程序实例中，如下:3个请求将被定向到srv1，一个请求将发送到srv2，另一个请求将发送到srv3。
同样，在nginx的最新版本中，使用最小连接和ip- hash负载平衡的权重也是可能的。

健康检查
nginx中的反向代理实现包括了in - band(或被动)服务器健康检查。如果某个特定服务器的响应失败，nginx将标记此服务器为失败，并将尝试避免在随后的入站请求中选择此服务器。
max_失效指令设置了与在故障超时期间应该发生的服务器通信的连续失败的次数。默认情况下，max_失败设置为1。当它被设置为0时，该服务器将禁用健康检查。故障超时参数还定义了服务器被标记为失败的时间。在发生服务器故障后的故障超时间隔之后，nginx将开始优雅地向服务器发送live客户机的请求。如果探测成功，服务器将被标记为live one。

业务服务器的配置

我这里才用Java web（ssm），安装好jdk和tomcat后，还要对tomcat优化下，充分利用服务器的资源。在tomcat的bin目录下，对catalina.sh文件进行修改，在
echo "Using CATALINA_BASE: $CATALINA_BASE";下，添加：JAVA_OPTS="$JAVA_OPTS -server -Xms2048m -Xmx2048m -XX:MaxNewSize=1024m"

数据库服务器的配置

这里只有一个mysql，同样的，安装后，对mysql做一些优化，充分利用服务器的资源，打开my.cnf

max_connections=3000
mySql的最大连接数，当服务器的并发连接请求量比较大时，可以调高该值。

thread_concurrency=64
理论为cpu的两倍。

其他的像read_buffer_size/sort_buffer_size/read_rnd_buffer_size根据程序的特点调整。