技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统架构 --> 系统架构的一些思考

系统架构的一些思考

浏览:5614次  出处信息

    很久没更新博文了,主要还是觉得自己的思维没有进一步提高,今天简单记录下,以前总是以正向的方式去思考问题,其实对自己进行一些反向的思考收获可能更大.

    修改了下原文,原来有些话说的有点太感性,希望对于看到的人有帮助.

    1:对于Squid的使用思考

    缓存服务目前有很多种,可能并没有很多人意识到为什么用Squid或者Memcached.他们解决的应用场景其实不一样的.期望用缓存解决所有复杂的事情,其实带来的管理代价是无穷的.通过最近的分析发现,只要是用户被动触发打开的页面,其命中率都不会很高,比如有多少人会去点文章第二页的评论呢?一个文章列表页(按照不同分类,不同页码)有各种各样的表现形式.但是真正用户会去关心这些页面吗?答案是否定的,这些页面的浏览比例极低(相对的),命中率也极低(相对的).

    假如我们生生将这些页也生成Squid,其带来的复杂更新成本是无法衡量的.以前一直有个想法重新构建我们的Squid管理队列,现在想想确实没有必要,技术人员思考问题需要避免复杂化,就算实现了很复杂的管理算法,又能说明什么?仅仅满足自己内心的自豪感,我们应该更多关注工程理论,而不能沉浸在自己狭小的思维中。

    最后总结的是,用Squid做正确的事情,在产品功能越来越动态化的前提下,对核心页面做页面缓存就可以了.但是需要注意的是,虽然某些页面来说PV量很小,但是想看这些页面的用户确实非常重视的,所以这些页面的访问质量对用户的影响是极大的.

    

2:服务部署

    在数据量,访问量日益飞增的情况下,加上国内网络情况不同质,很多应用多趋向从中心化走向分布式.从长期来看,这是一条明智的路,虽然我们说简单化很重要.但是一个产品需要质变,同样技术理论也需要突破.那么分布式就是一条必经之路.

在这里我不想说分布式的工程理论,分布式部署解决的问题.只是想说我们在做这件事情上犯的一些基本错误.

    1)当我们的理论水平还不足以控制的时候,在做部署抉择的时候需要更加谨慎,简单来说就是我们没有找到做这件事情的关键,当然我们不跨出"尝试"这一步的话,很多事情就永远做不出来.

    2)在我们做完广州部署后,到我们真正想解决的问题到底有没有解决,缺少后期的跟踪和分析,其实很多时候我们不管做什么事情,"做"很容易,却最后发现我们并没有解决问题。

    比如在做广州部署这件事情上,一个原则就是任何数据尽量本地化存储,但是考虑到同步复杂度,资源部署的原因,某些数据没有能够外地部署(比如Api,Memcachedb),提供一个数字,跨IDC读取一般平均有80Ms(本IDC一般在20Ms),对于动态类程序来说,多进行几次这样的资源操作,整体程序的响应时间将会很大.

    发现广州核心程序的性能居然是北京的2倍.所以意识到在这件事情上犯了太多的错.

    总体来说,在做服务部署这件事情上缺乏更多的思考(这是经验和技能导致的),很多时候其实意识到了会有问题,重要的是如何抓住事物的本质。在这件事情上会继续推进下去,因为从结构性上来看这是趋势.只要我们在做每一步的时候知道自己想要解决的核心问题是什么,那么成功仅仅是时间.

    3:系统负载的问题.

    我们经常以系统负载高来衡量系统可能存在问题.经过最近的思考来来看,负载高不代表机器的处理能力有问题,一般web server的配置不存在"特高","特低"这样的区分,假如Cpu,I/O不是特别离谱的话,负载高仅仅说明机器的扩展能力不足,因为你这台机器接受的任务队列有限,另外一方面反映出程序处理复杂程度过高,需要优化,比如这次观察了一下我们的队列机,负载在40,但是其实程序运行的还是不错,只要不影响用户的感受,负载高仅仅说明我们需要去优化,不代表系统存在问题,这是一个长期的指标,需要找出负载高低的拐点,通过趋势变化发现事情的本质.比如通过负载变化我们知道下午1点到4点是访问高峰.

    4:结果论

    很高心现在能以技术人员的维度去推进我们这个产品的发展,尤其以前一直做开发,看到一个新功能出来,那种成就感是巨大的.而现在是以性能优化和系统架构设计作为自己的目标,等于说角色需要转变,在这个转变过程中需要做什么.

    1)定位已经变了,需要去适应,要面对现实,不管遇到何种情况,都不应该改变自己的初衷,信心是第一位的。

2) 系统架构包含很多,尤其要注重开发实现,不应该仅仅前期完成设计就可以,任何事情都有关联,需要更强的全局观.

    4)不同角色的需求是不一样的,要做的不是反抗,要做的也不是抵触,因为不同人员提的问题即使不对,那需要去想想他们为什么要提,他们提的背景是什么,对自己是个激励作用,对自己是个点拨作用.

    5) 激励是重要的,付出的同时收获是很大的,技术人员就要永远以"技术"为根本.

    6)不要说现在对代码不熟悉了,也不知道实现细节了,当遇到这样的情况,需要通过自己的方法去了解,去约束.

    7) 每个人的出发点和重心是不一样的,如何讨好,巴结,规范,指导其他人帮你去工作。

    8) 不管技术方案对不对(最后才能得知),和你配合的人一定要明确,假如一开始就存在分歧(但是也没说),那么结局一定是悲惨的.

    

    

5: 快速实施的好处与坏处.

    最近的一些工作情况让我对这个论题有比较深刻的认识,以前我有个习惯,发现问题立刻就去解决或者补救。这个过程不代表没有思考长期的解决方案,也不代表没有思考改造后带来的负面影响。也许有的解决方案现在看来很二逼,但是在那个时刻来看,其实并不傻。

    觉得同事说的不站而屈人之兵,厚积薄发很有意思,其实有的时候很重要,沉稳很重要,但是快速执行也很重要。那么重要的是什么呢?

    

6:带宽和下载速度

    最近在做一些项目,经常遇到同事说带宽不够,下载速度不理想,机器不够,其实还是没有把握事情的本质。

所谓的带宽是在某个时刻发送器能够传输数据的频率,带宽仅仅是是运营商做的策略,比如在交换机,网卡上具体的策略。为了控制数据的传输,而下载速度是最终的结果(数据包除以具体的时间),取决于很多因素。所以有的时候没有掌握事情的本质真的很恐怖。

    

说的有点乱,以后再总结。

建议继续学习:

  1. 浅析http协议、cookies和session机制、浏览器缓存    (阅读:15800)
  2. 分布式缓存系统 Memcached 入门    (阅读:14721)
  3. 强制刷新本地 DNS 缓存记录    (阅读:9242)
  4. 使用Squid缓存视频    (阅读:9176)
  5. php缓存与加速分析与汇总    (阅读:6287)
  6. Web应用的缓存设计模式    (阅读:5877)
  7. 浏览器缓存机制    (阅读:5773)
  8. 缓存设计的一些思考    (阅读:5731)
  9. 谈冷热数据    (阅读:5756)
  10. 使用memc-nginx和srcache-nginx构建高效透明的缓存机制    (阅读:5700)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1