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

关于海量用户访问的通用技术架构的一些思考 　　最近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集群 ，维护成本是很高的。降低维护成本