系统架构的一些思考
很久没更新博文了,主要还是觉得自己的思维没有进一步提高,今天简单记录下,以前总是以正向的方式去思考问题,其实对自己进行一些反向的思考收获可能更大.
修改了下原文,原来有些话说的有点太感性,希望对于看到的人有帮助.
1:对于Squid的使用思考
缓存服务目前有很多种,可能并没有很多人意识到为什么用Squid或者Memcached.他们解决的应用场景其实不一样的.期望用缓存解决所有复杂的事情,其实带来的管理代价是无穷的.通过最近的分析发现,只要是用户被动触发打开的页面,其命中率都不会很高,比如有多少人会去点文章第二页的评论呢?一个文章列表页(按照不同分类,不同页码)有各种各样的表现形式.但是真正用户会去关心这些页面吗?答案是否定的,这些页面的浏览比例极低(相对的),命中率也极低(相对的).
假如我们生生将这些页也生成Squid,其带来的复杂更新成本是无法衡量的.以前一直有个想法重新构建我们的Squid管理队列,现在想想确实没有必要,技术人员思考问题需要避免复杂化,就算实现了很复杂的管理算法,又能说明什么?仅仅满足自己内心的自豪感,我们应该更多关注工程理论,而不能沉浸在自己狭小的思维中。
最后总结的是,用Squid做正确的事情,在产品功能越来越动态化的前提下,对核心页面做页面缓存就可以了.但是需要注意的是,虽然某些页面来说PV量很小,但是想看这些页面的用户确实非常重视的,所以这些页面的访问质量对用户的影响是极大的.
在数据量,访问量日益飞增的情况下,加上国内网络情况不同质,很多应用多趋向从中心化走向分布式.从长期来看,这是一条明智的路,虽然我们说简单化很重要.但是一个产品需要质变,同样技术理论也需要突破.那么分布式就是一条必经之路.
1)当我们的理论水平还不足以控制的时候,在做部署抉择的时候需要更加谨慎,简单来说就是我们没有找到做这件事情的关键,当然我们不跨出"尝试"这一步的话,很多事情就永远做不出来.
2)在我们做完广州部署后,到我们真正想解决的问题到底有没有解决,缺少后期的跟踪和分析,其实很多时候我们不管做什么事情,"做"很容易,却最后发现我们并没有解决问题。
比如在做广州部署这件事情上,一个原则就是任何数据尽量本地化存储,但是考虑到同步复杂度,资源部署的原因,某些数据没有能够外地部署(比如Api,Memcachedb),提供一个数字,跨IDC读取一般平均有80Ms(本IDC一般在20Ms),对于动态类程序来说,多进行几次这样的资源操作,整体程序的响应时间将会很大.
发现广州核心程序的性能居然是北京的2倍.所以意识到在这件事情上犯了太多的错.
总体来说,在做服务部署这件事情上缺乏更多的思考(这是经验和技能导致的),很多时候其实意识到了会有问题,重要的是如何抓住事物的本质。在这件事情上会继续推进下去,因为从结构性上来看这是趋势.只要我们在做每一步的时候知道自己想要解决的核心问题是什么,那么成功仅仅是时间.
3:系统负载的问题.
我们经常以系统负载高来衡量系统可能存在问题.经过最近的思考来来看,负载高不代表机器的处理能力有问题,一般web server的配置不存在"特高","特低"这样的区分,假如Cpu,I/O不是特别离谱的话,负载高仅仅说明机器的扩展能力不足,因为你这台机器接受的任务队列有限,另外一方面反映出程序处理复杂程度过高,需要优化,比如这次观察了一下我们的队列机,负载在40,但是其实程序运行的还是不错,只要不影响用户的感受,负载高仅仅说明我们需要去优化,不代表系统存在问题,这是一个长期的指标,需要找出负载高低的拐点,通过趋势变化发现事情的本质.比如通过负载变化我们知道下午1点到4点是访问高峰.
4:结果论
很高心现在能以技术人员的维度去推进我们这个产品的发展,尤其以前一直做开发,看到一个新功能出来,那种成就感是巨大的.而现在是以性能优化和系统架构设计作为自己的目标,等于说角色需要转变,在这个转变过程中需要做什么.
1)定位已经变了,需要去适应,要面对现实,不管遇到何种情况,都不应该改变自己的初衷,信心是第一位的。
4)不同角色的需求是不一样的,要做的不是反抗,要做的也不是抵触,因为不同人员提的问题即使不对,那需要去想想他们为什么要提,他们提的背景是什么,对自己是个激励作用,对自己是个点拨作用.
5) 激励是重要的,付出的同时收获是很大的,技术人员就要永远以"技术"为根本.
6)不要说现在对代码不熟悉了,也不知道实现细节了,当遇到这样的情况,需要通过自己的方法去了解,去约束.
7) 每个人的出发点和重心是不一样的,如何讨好,巴结,规范,指导其他人帮你去工作。
8) 不管技术方案对不对(最后才能得知),和你配合的人一定要明确,假如一开始就存在分歧(但是也没说),那么结局一定是悲惨的.
最近的一些工作情况让我对这个论题有比较深刻的认识,以前我有个习惯,发现问题立刻就去解决或者补救。这个过程不代表没有思考长期的解决方案,也不代表没有思考改造后带来的负面影响。也许有的解决方案现在看来很二逼,但是在那个时刻来看,其实并不傻。
觉得同事说的不站而屈人之兵,厚积薄发很有意思,其实有的时候很重要,沉稳很重要,但是快速执行也很重要。那么重要的是什么呢?
最近在做一些项目,经常遇到同事说带宽不够,下载速度不理想,机器不够,其实还是没有把握事情的本质。
建议继续学习:
- 浅析http协议、cookies和session机制、浏览器缓存 (阅读:15759)
- 分布式缓存系统 Memcached 入门 (阅读:14701)
- 强制刷新本地 DNS 缓存记录 (阅读:9224)
- 使用Squid缓存视频 (阅读:9162)
- php缓存与加速分析与汇总 (阅读:6249)
- Web应用的缓存设计模式 (阅读:5853)
- 浏览器缓存机制 (阅读:5755)
- 缓存设计的一些思考 (阅读:5708)
- 谈冷热数据 (阅读:5732)
- 使用memc-nginx和srcache-nginx构建高效透明的缓存机制 (阅读:5687)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:ywdblog 来源: 技术 总结 记录 生活 工作
- 标签: Squid 带宽 缓存
- 发布时间:2010-12-21 23:09:20
- [65] Oracle MTS模式下 进程地址与会话信
- [65] Go Reflect 性能
- [64] 如何拿下简短的域名
- [59] android 开发入门
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 图书馆的世界纪录
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则