免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
打印 上一主题 下一主题

千万级pv高性能高并发网站架构与设计交流探讨帖 活动结束 获奖名单公布 [复制链接]

论坛徽章:
1
15-16赛季CBA联赛之深圳
日期:2018-12-11 08:52:00
141 [报告]
发表于 2011-12-16 10:47 |只看该作者
php?

论坛徽章:
0
142 [报告]
发表于 2011-12-16 11:25 |只看该作者
感觉只谈千万级pv架构有点太宽泛了,毕竟不同的应用其需要解决的难点、瓶颈都是不一样的.
从各个层次来说前端的负载均衡是最容易解决的,常用的无非F5 netscaler nginx haproxy lvs等
其次相对容易解决的是cache层常见像 squid varshi nginx     mongodb  memcached membase redis等都有比较多的案例。
最困难的是数据库以及海量的大文件或者小文件横向的横向扩展。
架构不可能完全通用,所以如果各位大牛最好能给以案例的形式给出解决方案对大家的指导意义可能会个大一些。
比如sns网站、微博、新闻、电商这些类别的网站什么样的架构最合理,最可能产生瓶颈的地方以及解决方案。
期待大牛们的分享!

论坛徽章:
0
143 [报告]
发表于 2011-12-16 11:29 |只看该作者
好贴 关注学习中

论坛徽章:
0
144 [报告]
发表于 2011-12-16 12:49 |只看该作者
回复 136# 老男孩linux培训


    嗯,谢谢鼓励~我现在在看一些基础的LINUX知识,网站运维还有很长的路~~~

论坛徽章:
0
145 [报告]
发表于 2011-12-16 14:52 |只看该作者
千万PV

论坛徽章:
4
CU大牛徽章
日期:2013-03-13 15:32:35CU大牛徽章
日期:2013-03-13 15:38:15CU大牛徽章
日期:2013-03-13 15:38:52戌狗
日期:2013-12-27 15:08:11
146 [报告]
发表于 2011-12-16 15:33 |只看该作者
学习了又温习了下 很多东西不用又淡忘了

论坛徽章:
0
147 [报告]
发表于 2011-12-16 17:12 |只看该作者
本帖最后由 yahoon 于 2011-12-16 17:14 编辑

架构设计之前,首先是了解业务.
业务类型,当前的规模,投入与产出,未来的发展,可能的瓶颈在哪? 以后的扩展性如何?

很多时候就是做取舍,抓住主要矛盾,对业务最重要的点上投入最多的资源(包括硬件软件,人员,资金等)

甚至每隔2-3年需要重构! 技术的发展日新月异,不要想一个架构能够一直抗下去. 架构师要追技术发展, 业务发展到一定规模时, 当前架构无法满足要求时就该重构!

一般来说,架构要结合产品,并且要做压力测试!
你某个点(例如单纯的web或者db)满足高可用高性能了,并不代表整个系统就是高性能的.
级联效应,蝴蝶效应,在产品上线前中考虑到了没?

讨论了这么久发现那些技术和架构基本也就那么多(网上一搜一堆,基本上满足了"高可用高性能". 只要机器够用,大家都配得出来.但是很多人现在面临的实际问题是公司投入只有这么多,如何设计架构? 这种情况下可能某个部位的单点失效基本上是无法避免的,我们必须有取舍,有测试,关注核心功能. 我之前在做web网站时,常常会问开发人员,少了这个功能,或者这个部件出问题,用户会有什么样的影响? 我们的业务会有什么样的影响? 哪些是次优先级的.

千万级亿万级的网站有多少? 这样的网站轮到你设计的又有多少?  我们重要的是一种理念: 少花钱,尽量多办事,办成事,有了问题也是可控范围内. 有了这个理念, 你的业务不断增长,架构自然是不断扩展的.

选择当下及未来一段时间(你可预见的时间内)满足你和公司的架构吧! 至于技术细节,baidu or google.

论坛徽章:
0
148 [报告]
发表于 2011-12-16 21:50 |只看该作者
听一下,学习学习

论坛徽章:
0
149 [报告]
发表于 2011-12-18 21:13 |只看该作者
看了前面各位大牛的讨论,颇有感慨。
个人认为,所谓架构就是为了支撑业务发展(前提是针对业务特点定制架构)
本人从事运维行业也3年了,目前就职于一家移动互联网公司,负责的主要业务是垂直搜索,用户600W/日,pv3.5Y/日 左右。公司目前的架构是DNS view ->LVS->app->memcached->index->memcached->cassandra.代码实现C++和Java 这套架构运行了将近一年了,除了cassandra存储之外,其余没有改动过。实际上来说,这套架构已经跑了两年了。现在面临的问题是:
1.机房IP资源有限的情况下,LVS后端的APP扩展受到限制,机房也没有那么多公网IP提供
2.APP服务器多达60+,每次做版本发布OP人员都痛苦不堪,开发人员的代码质量难以恭维,发布后总是要盯着APP 输出的日志进行检查,哎……
曾经和公司的架构师(技术总监)提过,可以考虑两个点来解决我们目前的问题
1.前端改为 DNS view ->LVS->nginx/haproxy->app,请求进入七层后,通过内网转发,节省大量公网IP,对APP还有保护作用
2.可以考虑自建+采购 CDN,稍微提升请求的响应速度,并且减少部分APP服务器,提高版本发布的工作效率
可是,架构师说,nginx/haproxy,squid,varnish。他都没有用过,不敢上生成环境。所以决定这套架构一直跑下去。个人认为这样架构师不够尽职,如果没用过,可以进行调研。况且nginx/haproxy,squid目前的应用方案已经很成熟了,想必大家也都了解,今天看到大家讨论这个话题,吐吐苦水,还望楼主见谅
还是觉得“所谓架构就是为了支撑业务发展(前提是针对业务特点定制架构)”,这是必须的。

论坛徽章:
0
150 [报告]
发表于 2011-12-19 15:47 |只看该作者
原来大师都在这里。。。。。。。。。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP