每个企业都是慢慢发展起来的，在起步阶段成本是一个不得不考虑的重大问题 。直接入正题：
前台框架: 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应用服务是瓶颈 ，就想到这一层的负载均衡，怎么做呢？于是就有了如下的解决方案：
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集群或者图片集群之间的内容同步 ， 数据库和缓存的集群一般都已经有成熟解决办法，不是很费事。
紧急情况的预案等需要提前做好规划，每隔一段时间进行论证和更新。