系统架构的一些思考

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:带宽和下载速度

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

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

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