关于海量用户访问的通用技术架构的一些思考

最近12306.cn网站事件引起了很多人对架构的思考。这种访问量巨大的网站究竟该如何来做架构，下面是我的想法：

　　因为要考虑到通用抛开业务单纯从技术层面分析，要承载海量用户的访问，要求网站高性能和高可用、安全可靠 、高可收缩性 、易于维护 等等一堆硬性的要求。对架构师来说是极大的考验。先上图：

一、对高性能的解决方案大多都是负载均衡，但负载均衡应该做在那一层或者哪几层呢？

1.1、首先是 DNS解析层面的负载均衡 ,  这一层不但可以做负载还可以做分网(电信、网通和教育网)路由 ， 和静态内容(图片之类的东西)路由 ,把静态内容独立出来本身就有利于做CDN、性能优化和日常维护。这一层的路由性能是最高的，当然硬件和网络等因素不考虑。

1.2、web前端的负载均衡 , 这一层的可以做硬件层面的负载均衡(eg:F5)或者软件层面的负载均衡(eg:Apache/LVS/ Nginx),选择还是比较多的。但这一层的负载均衡要考虑本身有需要的负载均衡 , 我这里采用Keep alived.

1.3、Web这一层如何提高性能， 固定性内容使用静态化 ， 动态内容提高性能原则是”剃刀原则”直接访问数据库或者缓存(包括本地和分布式缓存)。

　　看一个案例：

 

　　刚开始的架构图：

 

 

使用一段时间之后发现WCF应用服务是瓶颈 ，就想到这一层的负载均衡，怎么做呢？于是就有了如下的解决方案：

 

 

 

　　在应用服务器前面加了一个WCF路由和负载均衡的服务器。但是部署没多久就撤下去了。原因是WCF路由服务器成为了新的瓶颈，然后多层应用层面的路由对性能的损耗增加，稳定性反而下降,维护成本增加。

 

　　分析问题的本身为什么要用WCF？这里不是WCF这个技术不好，而是使用的场景不对. 本身简单的业务为什么要通过WCF服务访问数据库呢？为什么不直接访问数据库，然后把重复访问的数据提起出来做缓存。这样才真正符合“剃刀原则”。

 

1.4、数据库集群 ， 不同的数据做法相差很大。Oracle 本身有RAC的做起来比较方便。mySql也有自己的集群机制。这里说说对Sql Server 的一些思考：

 

 

前段放IP负载均衡(eg:LVS)，开发不用管后面数据的储存，只是将读写分离，写Master集群，读slave集群,集群之间通过 微软企业级解决方案实现： 

Master 集群之间做Row级别的同步 , Master-Master Row-Level Synchronization

Master to Slave 的数据同步Master-Subordinate Cascading Replication

 

 

二、安全可靠，我觉得可以从几个层面上去把握

2.1、网络布局的层面 ，一些安全机制薄弱的应该置于内网 ，边界位置的严格验证，防火墙等。

2.2、通信层面，对安全要求较高的数据传输要使用证书加密。

2.3、应用层面，严格对数据来源过滤和检查，对不可信数据拦截

2.4、数据库层面，敏感数据的储存方式需要高强度加密(比如SHA512+适当的Salt)。(不要让类似CSDN密码泄露事件发生在我设计的架构上)

2.5、OS层面，自动化的系统补丁安装，杀毒防御程序之类自动更新。

2.6、维护层面，维护人员的责任制

 

 

三、高可收缩性

      架构图上画一个集群，不一定部署一个真的集群，集群多大？最小一台，最大可以扩展到IP端能容纳的数据量 ， 如果多级负载加上集群就可以实现海量的集群就可以叫着“云”！

首先DNS 负载均衡 ，网站A记录可以指向多个Data Center , 最小可以只有一个。ningx集群 、 web集群 、 分布式缓存集群 和 数据库集群都可以很方便的进行收缩。

 

 

 

四、易维护

      主要是架构本身具备的容灾能力，然后有自动监控的平台，紧急情况通过Email或者短信通知维护人员进行相应的处理。

       偌大一个web集群，维护成本是很高的。降低维护成本就需要同组件去完成，web集群或者图片集群之间的内容同步 ， 数据库和缓存的集群一般都已经有成熟解决办法，不是很费事。

       紧急情况的预案等需要提前做好规划，每隔一段时间进行论证和更新。