设计个网站系统(.net 3.5+sql 2005)，访问量并发量会很大，业务逻辑会有大量的数值计算以及逻辑判断，我本打算使用remoting(WCF)来架构业务逻辑层，但我可能更习惯于将这些逻辑在数据库的存储过程中实现，这样的话，remoting(WCF)这层基本上就没有什么计算量或者说压力，因为所有的计算逻辑都在数据库对象(存储过程,视图,函数,触发器)中实现的，压力就完全在数据库服务器上，remoting(WCF)应用服务器基本上没什么压力，如果把业务逻辑层单独搭建应用服务器则作用不大，而且会有数据传输上的性能损耗，因此我本来打算在remoting(WCF)这层做负载均衡就没意义，而数据库服务器负载均衡，我不是很了解，这个要涉及数据的同步，比较麻烦，如果不采用remoting(WCF)，而把业务逻辑集中写入数据库的存储过程，这样的话，我网站部署在web服务器上，前端的连接压力使用web服务器集群解决，数据库服务器是否使用数据库负载均衡？听说数据库可以做集群，但不能负载均衡，实现负载均衡，需要购买第三方软件或硬件来实现？请问各位以下两种方案：1.web服务器+remoting(WCF)应用服务器(业务逻辑)+数据库服务器
2.web服务器+数据库服务器(业务逻辑写入存储过程)那种比较适合访问量大，并发操作很大的网站？那种比较容易扩展？或者能指点下好的架构方式，
当然一定要给我分析下啊，请各位不吝指点下，谢谢！
2.web服务器+数据库服务器(业务逻辑写入存储过程)那种比较适合访问量大，并发操作很大的网站？那种比较容易扩展？或者能指点下好的架构方式，
当然一定要给我分析下啊，请各位不吝指点下，谢谢！
首先，业务逻辑最好不要放在SP里，之所以这么说，是出于三点考虑：
一，业务逻辑和数据库处理 混在一起，网站整体结构不好把握
二，不知道LZ有没有过这样的经历，如果不幸哪天你的数据库崩溃了，你的业务逻辑也随之湮没，运营网站的核心是什么？(虽然，你可能有备份数据库，但也不建议这样做，因为业务逻辑是相对数据库是易变的)
三，数据库的资源是很昂贵的，你应该更多让程序去读相对“便宜”的硬盘