【架构】一个大型高并发的WEB系统采用哪种架构更合理？

Question

 

设计一个大型的，高并发的WEB应用系统，迷茫采用何种方式的架构。请大伙帮忙提议提议，三层？ MVC？ ORM？ WCF? 又或者混合？

数据承载千万级，访问并发万级以上的互动WEB应用; sql server + c#.net ，明白架构不能决定一切，我觉得一个更合理的架构对开发速度，维护，性能都存在很多的影响。

我个人觉得此时webform不适合，但是用第三方视图引擎又怕性能问题，即使缓存视图也要付出很多代价。对MVC方面我没多少经验，还是请大伙帮忙建议下，从性能，维护，开发速度等多方面考虑。谢谢

Answer 1

看你的提问还没有明白怎么去做高并发，并不是语言框架的问题，而是基于每个小细节的优化以后的架构， 而且万级以上的并发，你得硬件和带宽够吗，这些往往比软件的瓶颈小的多的多，看你的提问来猜想你公司的硬件，我感觉你首先去考虑一下带宽和硬件，万级的并发最少带宽得100M以上

Answer 2

直接 html+javascript？

Answer 3

全部用ajax取动态数据? 这样开发速度慢,维护难,而且性能也一般吧.

Answer 4

性能的瓶颈不在这里，再说你能做多大的？google、百度那么大的？

Answer 5

哈哈,自然没那么大, 一般来说性能的瓶颈在于IO读取和数据库吧. 高并发恰巧要在IO读取和数据库读写上. 这方面可以做成分布式的磁盘IO读写,数据库也可以散列或分布式. 但在服务端的数据处理上, 顾老大以为哪种的程序架构比较好?

Answer 6

具体问题具体分析，这种问题没有固定答案。

Answer 7

问题基本很具体了,高并发高交互,类似论坛. 求相对答案. 只求相对的架构方式,不求实现,因为实现方式才真正是具体情况具体分析的

Answer 8

        先根据现有成熟技术储备搭建框架，优化等可以按照规划来做。     有时候不在于你用什么，而在于你怎么合理的使用。

Answer 9

是的，细节，处理方法很重要。但是也有一种情况是程序基本架构不合理，再处理使用中会有很多瓶颈很多冗余，要到那时候解决会多花许多时间和精力。我认为选择一个较好的基本架构就是造楼房的钢筋柱一样。

Answer 10

@clound: 呵呵，我的确缺少对高并发架构的自信，只能尝试。 问题中也是矛盾纠结的，所以拿来向大家求经，MVC没有很多的经验是可以学习和积累的，只要他更适合我。 特别是有这方面经验的朋友如果可以告诉我某个第三方视图引擎可行，或者MVC更合适，我会立马研究深入去。。 ：）