vans&tnf架构方案

架构

架构优势

1.多品牌复用web服务器，减少服务器成本
2.根据流量切分服务器的使用占比，达到系统的稳定
3.针对大促等高并发需求，通过相对简单调整，来做应对，保证系统稳定

架构模式

项目采用当前流行成熟的B/S应用架构，系统采用Linux+Nginx+Mysql+Php的模式，为业务做服务支撑

业务开发模式

项目采用MVC模式开发，MVC即 模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

服务器安全

所有运维人员都通过堡垒机连接生产服务器，这样所有的指令都可以被监控。保证生产环境的安全性。

日常使用业务场景架构

1.用户访问系统的时候，进入对应的DDOS服务，进行TCP/IP协议级别的防护
2.数据经过DDOS的时候，接入到对应的防火墙，做应用层的防护
3.经过防火墙的请求数据，接入到对应的反向代理服务器。
反向代理服务器功能
①会做一层对应的页面缓存，减少应用服务器和数据的压力
②提供负载能力，找到后面接入的空闲的web应用服务器，保证系统的稳定，以及系统的扩展
4.经过反向代理的请求，会流转到对应的web应用服务器。除了提供对应的应用服务的同时，也会有一层数据的缓存。我们这边的web应用服务器，会组成对应的集群，来承担更多的访问请求和并发请求
5.在web应用服务器做数据访问的时候，我们会把一些经常读的数据，放置到redis这边的中间件中，起到快速读取，快速写入，减少最下层mysql数据库的压力
6.最下层，就是我们的数据库，也是系统在运行中，容易产生瓶颈的服务。
对此我们提供了对应的解决方式
①从用数据库主从的架构方式，主数据库做读写的操作，从数据库为只读实例，来缓解单一主数据库的压力。因为网站的操作，大多说为浏览读取的操作。
②如上所说，我们为了缓解读取的压力，在反向代理，物理机，中间件都有对应的缓存策略，最大限度的减少了数据库的压力

品牌大促时的架构方案

1.会在DDOS后面加一层SLB的服务。
原因: 因为日常使用的架构，从DDOS到防火墙到web应用服务器的时候，因阿里的限制，必须采用外网访问的限制，外网访问阿里有200M的限制，在大的流量并发的时候，会超过对应的限制，造成很多请求的无效和失败。
方案目的: 加上SLB服务的时候，即可采用内用访问web应用服务器的形式，上线为24G，相对于200M会有更大的空间，能支持较大的请求和并发
2.大促的品牌，可切换使用更多的web服务器的资源
原因: 如果VANS和TNF各采用3台服务器做集群的话，日常使用并没问题。但是假设VANS品牌做大促的时候，还采用此方案的话，会造成VANS的3台服务器压力过大，相对的TNF服务器可能有较大的服务器资源的闲置
方案目的: 此时可以采用VANS使用4台服务器，TNF使用2台服务器的的方式，做集群方案。能比较合理的使用资源
3.采用CDN技术
原因: 
①.网页中的图片，CSS样式，视频会占据大量的流量带宽
②.而且不同地区的用户，访问同一个服务的话，会有不同的网络延迟
方案目的: 
CDN会缓存对应的静态资源到不同地区的服务节点。这个时候，用户进行访问的时候，
①.可以减少主站服务器的压力，主站只处理动态的数据资源
②.可以路由寻址到自己最近的服务器，减少网络延迟
4.服务拆分
原因
①.访问的时候，不同的浏览器针对同域名有最大的连接数限制
②.如果所有的应用不做拆分的时候，比如订单服务的压力过大，成为瓶颈，会造成其他的服务也有访问的不稳定性
方案目的：
①.有些版本的chrome浏览器，同样的域名的最大连接数为6，如果把cdn的资源，切成不同的二级域名的话，则会有成倍连接数增加，提高页面的想一个速度(下面有对应的域名拆分实例表格)
②.更细致的拆分web服务，比如把预约服务拆在一台独立的服务中，这样的话，预约的服务即使压力很大，也不会影响对应的其他的服务。同样拆分的还有订单服务和登录服务

域名实例拆分表