如何开发高性能低成本的网站之技术选择

每个企业都是慢慢发展起来的，在起步阶段成本是一个不得不考虑的重大问题 。直接入正题：

 

前台框架:  ASP.NET MVC + Jquery + Json + Flash , ASP.NET MVC 高性能速度快，Jquery 简洁成熟的Js基础框架 , Json 数据格式体积小 ，传输快。Flash 用于开发复杂的页面交互应用。

 

缓存方案：

Memcached , 基于Key-Value的传统Cache储存方式 , 高性能 ， 而且它内置LRU（Least Recently Used）机制自动维护缓存数据,从而 提高缓存的性能和负载能力。

MongoDb , 数据库级别的缓存解决方案 , 适合海量的数据缓存 , 支持查询

 

权限模型:

基于ASP.NET MVC 的RBAC , 控制对象粒度到Action , 控制操作粒度 是否能访问。权限基于Cookie/缓存记录认证信息 , 在用户登录时就计算出该用户的所有权限并缓存。

(优点：直接通过AOP做横切面控制，不需要设置权限点 ；缺点：无法控制到同一个Action有增、删、改、查等更细的操作粒度，不同的操作需要制作不同的Action , 表面上要多几个Action , 其实这样做职责更加分离，更加符合OO的观点)

 

多语言解决方案：

         服务端, 基于资源文件，完美配合ASP.NET MVC 前段框架 ,进行各项数据验证及提示等

         客户端, 同样基于资源文件, 对Page页面采用script 导入序列化的资源文件 ,按名词空间引用 ，如Resources.Book.AreYouSure 的Js变量. 对于flash等可以通过Json 传递。

 

数据通信：

服务端，WCF , WebService

客户端,  HttpRequest 数据类型Json

 

数据访问层：标准接口化，不对数据实现依赖。

         Entity Framwork , 适合只使用SQL Server 的解决方案, 开发效率最高

         NHibernate , 支持多数据平台 ，开发效率较高 , 性能一般

         ADO.NET, 完全靠开发实现,开发效率低 , 性能较高

         性能和效率按正常水平评估

 

解耦办法：

         IOC , 依赖注入 ,

         AOP , 横切面拦截 ,权限中的推荐做法

 

负载均衡：

         Nginx , Web前端的负载均衡解决方案 , Nginx 开源免费，高性能 .

 

页面提速：

      实时性要求不高的页面可以做静态化 ，页面的部分动态内容可以通过SSI处理 ,然后数据更新就主动生成页面。页面静态化,通过XSLT的CMS生成机制可以对生成的页面内容进行压缩。

      静态资源文件拆分出去做独立站点,加上服务端的GZIP/Deflate压缩等操作,最好配上二级域名，已加快客户端HTTP下载.更加方便以后做CDN.

 

SSO:

      如果有多个站点，统一认证可以降低开发维护等成本.

 

数据库：

      Mysql ,  成熟，开源.

 

　　最近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集群或者图片集群之间的内容同步 ， 数据库和缓存的集群一般都已经有成熟解决办法，不是很费事。

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