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

gogo407

做好监控分析，调优
数据库给力
文件系统给力
连接数给力
缓存给力
千万不要简单问题复杂话。
天涯爆了明文密码4000kw。
所以现在安全才是最重要的
回过头来，有脑子才行啊，运维，架构，不简单啊

minyoni

回复 165# gogo407


     谢谢指点。
1.版本发布自动化，这个OP这边早就实现了，关键是，开发人员不愿意配合，每台机器打出的日志都不相同，并且resin重启时，jar包载入的顺序都有可能是错误的。这个很狗血……
2.我曾要求过主导部分改进工作，可惜领导不放权

总结：如果只是单纯的做技术这么简单也好了。

老男孩linux培训

to407 发表于 2011-12-13 11:16
赞一下哈哈

感谢啊，呵呵！

老男孩linux培训

chenyx 发表于 2011-12-12 17:56
回复 118# 老男孩linux培训

英雄所见 略同啊。嘿嘿！

老男孩linux培训

回复 150# yahoon
本帖最后由 yahoon 于 2011-12-16 17:14 编辑


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

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

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

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

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

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

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

老男孩评：
这个说的很好，赞！


   

老男孩linux培训

回复 152# minyoni
看了前面各位大牛的讨论，颇有感慨。
个人认为，所谓架构就是为了支撑业务发展（前提是针对业务特点定制架构）
本人从事运维行业也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目前的应用方案已经很成熟了，想必大家也都了解，今天看到大家讨论这个话题，吐吐苦水，还望楼主见谅
还是觉得“所谓架构就是为了支撑业务发展（前提是针对业务特点定制架构）”，这是必须的。  

老男孩评：
说的很好啊，LVS可以区分下 内外网，有些对内的业务（比如 给WEB SERVER提供服务的）就不需要外部IP了， CDN自建劳民伤财，还未必做好。你们的架构师 也太保守了（技术局限，也是性格局限）。如果采取一些改进措施，也许可能减1/3的服务器都能搞定你们的服务了。不过，你们的整体架构还是非常有技术含量的。希望以后能一起多交流。。。


   

minyoni

承蒙老男孩点评，非常感谢。日后一定多和大家交流。回复 170# 老男孩linux培训


   

minyoni

回复 170# 老男孩linux培训
看了前面各位大牛的讨论，颇有感慨。
个人认为，所谓架构就是为了支撑业务发展（前提是针对业务特点定制架构）
本人从事运维行业也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目前的应用方案已经很成熟了，想必大家也都了解，今天看到大家讨论这个话题，吐吐苦水，还望楼主见谅
还是觉得“所谓架构就是为了支撑业务发展（前提是针对业务特点定制架构）”，这是必须的。  

老男孩评：
说的很好啊，LVS可以区分下 内外网，有些对内的业务（比如 给WEB SERVER提供服务的）就不需要外部IP了， CDN自建劳民伤财，还未必做好。你们的架构师 也太保守了（技术局限，也是性格局限）。如果采取一些改进措施，也许可能减1/3的服务器都能搞定你们的服务了。不过，你们的整体架构还是非常有技术含量的。希望以后能一起多交流。。。

minyoni:
承蒙老男孩点评，非常感谢。之前一直在CU潜水，以后一定多和大家交流


   

9ding

看了 大牛们的 思路 获益匪浅啊
总结了下几点：稳定 安全 高效 实用

不过习惯了智能dns+keepalived+lvs前段缓存集群；后端nginx负载均衡

今天是菜鸟

{:3_186:}只能观望