这次笔记主写接入层，根据我们的实际项目出发，经验浅薄，可能有不对之处，还望指出。下回写逻辑层和存储层相关的笔记。
首先要知道我们的目的是什么？
- 保证系统的7*24小时可用
- 保证用户访问响应时间
- 保证系统的安全性
- 统一接入层，规范应用系统部署
一般而言，有Nginx就可以了，但当流量具有一定规模时候，这样的架构就变得不稳定了，如：用户响应时间过长、偶尔来个瘫痪什么的。所以为了提高可用性及整体的吞吐量，会引入接入层，这里使用LVS四层负载均衡，DNS解析到LVS的IP地址，然后LVS转发至Nginx，最后到后端的RS。如图：
很多公司都是从开始的单点服务，即一台服务搞定了一切->到后来服务隔离，引入Nginx，保证高可用->Nginx/LVS/F5/HAProxy 进行负载均衡，还有分流、削峰填谷、热点缓存，这些东西下个笔记会涉及颇多。
我们接着看这张：
看完这张图你或许会无语，为什么这么搞？LVS+HAProxy+Nginx 这几个好像可以做同样的事情，目前使用最广泛的三种负载均衡软件都被你们用了，有没有？其实不然，这层架构体系，也是运维部根据公司具体的业务流量迭代出来的。
先看下访问过程：
- 用户在浏览器输入域名回车
- 如果本地缓存里没有该域名对应的ip地址（浏览器缓存+本地缓存，谷歌浏览器中输入：chrome://net-internals/#dns 看到缓存页面，本地的缓存在hosts中）
- 那么到DNS进行域名解析，DNS将域名的解析权交给CNAME指向的CDN专用DNS服务器
- 为了得到实际IP，浏览器向CDN的全局负载均衡设备发起内容URL访问请求。
- 全局负载均衡DNS根据用户IP，将当时最接近的节点IP返回给用户浏览器（这里不考虑CDN中设置的URL相关策略）
- 浏览器得到IP，进行访问，然后到LVS这层。
我们知道LVS处于四层，HAProxy基于四层和七层，提供TCP和HTTP应用的负载均衡综合解决方案，这里我们使用七层。Nginx七层。基于他们各个特点可以去Google一下，这里不做详细笔记了。四层的负载是根据三层的IP地址（VIP）+四层的端口号来实现，我们实际只实现了高可用并没有进行负载均衡，真正的负载放到了HAProxy，LVS做了一件事就是分发即分流作用，访问不同的业务，走不同的服务。后期流量增大可考虑负载，也可以很方便的进行扩展，即它的伸缩性很强。需要认识的一点是请求的响应不走LVS。项目实施LVS/DR+Keepalived实现双机热备。
HAProxy实现负载均衡，策略：static-rr根据权重进行轮询，对HTTP反向代理，设置链接拒绝、虚拟主机、会话保持，还有它的监控服务，我们制定的实现当服务异常或宕机之后会向运维部发送短信和邮件，当然，业务服务也一样，不过有更健全监控系统。从实际效率来讲要比Nginx出色的多，且稳定性接近F5。
而Nginx的实现是一个Nginx对应一Tomcat服务，Nginx和Tomact在同一服务器上，每个服务都两台，进行互备，提高可用性。具体作用如下：缓存功能，增加命中率，减少回源。接口访问过滤策略，每个接口都会带有版本号及Token等信息。日志记录功能，访问日志，对于这个信息爆炸式的年代，日志重要性不言而喻；错误日志，正确的检测不仅可以发现服务性能的瓶颈，亦可及时发现问题，以及日志分割等。这里可以直接搭建ELK平台，对日志进行友好的查询和展示。
以上内容，只是我们为什么这么做，并不是应该这么做或者说我们用到的只是它们的一部分功能，可能还有的东西理解不到位。公司使用架构方案是根据网站的规模、不同阶段来使用不同的技术。你的QPS就几十个，有必要选用硬件负载F5、Radware、Array、NetScaler吗？有钱也需要从实际出发，要不然后期我们优化什么？