做架构优化的方法 - 84年的矿泉水 - 博客园

来源:百度文库 编辑:神马文学网 时间:2024/04/28 02:17:57


        一直有很多人问做架构的方法。其实架构不是做出来的,而是改出来的。但是万变不离其宗啊--万事都是有规律和方法的嘛!去年我有幸做了一个分布式文件系统(DFS)优化的架构工作,和大家sharing。

         分布式文件系统(DFS),关于这个是什么东西,不知道的各位同仁请g之。

         首先要明白自己的问题在哪里?我们的问题在于图片的量太大,导致了站点很卡。这是外表现象,那么里面到底是什么问题呢?为什么要用DFS呢?他主要用来干什么呢?怎么用呢?

        DFS的作用说白了很简单。目前在我们的系统中,主要就是用来解决用户上传图片的问题(不是图片的问题吗,那就解决它)。是不是有人大惊小怪了?上传图片还要单独用一个DFS系统?这不是复杂设计了吗?你直接把文件上传到站点根目录不就完了吗?是的,这是一种解决方法。但是你有没有想过我们的图片有多大的量?我们的图片需要在线维护的少说是TB级别的。还有我们的Web服务器是由F5做负载均衡的,也就是说不是单独一台web服务器,所以你的图片必须要集中起来管理维护了。

       也许有人会说,直接把图片放到数据库!其实以前我们就是这么做的(因为以前的量不大)。这样的好处是管理方便,坏处是相当于给数据库安装了病毒(量大就卡)。当图片的量上来的时候,只能升级硬件,但是升级硬件那是一条死胡同,你早晚得把硬件策略换到软件策略,taobao就是一个很好的例子。

      还有解决方法吗?WS/emoting?!是的,如果速度够快的话也是一种,但是现实是很残酷的!我们曾经做过尝试,包括用net写了一个tcp的服务,最终还是选择了放弃。原因是速度实在不敢恭维,其二,windows的磁盘管理对于这种纯文件服务,不是太管用。

       那么这个时候,就想到了linux,天生的内存和文件服务器。但是要在linux上跑,你的选择就是c,c++,java,另外一些脚本语言的东西。语言和平台不重要?不,很重要。因为下面你要修改它,维护它,管理它。选择一个你不熟悉的语言和平台无疑就是噩梦的开始。对我们这个net团队而言,那个最可控呢?显然是c。c++是一门正房地位,二奶权益,野花诱惑的语言,很少能做到全局控制。java,这个……,还是不要了吧?!现在留下的唯一一个问题就是你是自己写?还是准备找一个开源的呢?答案是看看你有多少成本。

      成本不管是钱,还有时间和人。对我们而言,钱倒不是大问题,但是做DFS的时候,我们组只有两个人,另外一个还在那边做缓存的优化,根本没有时间做DFS,我自从学校出来后c已经基本上还给老师了。短时间无法接手c。所以自己写的话,时间长不说,风险还很大。我和他讨论后还是选择了开源。

      开源是一个不错的东西。每每在关键的时候能救你一把!当然了开源的软件不是商业软件,别要求太高,别指望它像MS的东西那样,拿来就用。你得根据你的需求自己去改。我们改了几处和我们需求不符合的地方。然后开源软件一定要测试。要做非常复杂和全面的测试。性能,功能,灾难等等,这些测试一定要做,而且要做的全。我们的做法是由我写测试用例,因为一般而言只有架构人员和开发人员才知道这个东西最可能出现的问题在哪里,那么就重点测。你的目标其实很简单,就是当你把你的测试用例发给测试人员的时候,测试人员能看懂这个文档并且“哭出来”,那么如果在这种情况下测试通过的话,这个开源软件基本上已经够用了。

       这里为什么要先把测试放在前面呢?开源软件很多时候都不是非常靠谱的,特别在一些极端情况下的功能和性能问题,所以一定要先测试,测试完了,能满足自己的功能和性能需求了,你再去真正开始做细致的业务分析,再怎么样去搞定这个东西。是不是有人会问,你不知道业务需求什么,你怎么选型,怎么安排测试?你肯定知道大概要什么吧?你不知道?开玩笑,你不知道要什么你优化这个干吗?你肯定是知道了问题再去解决这个问题的嘛!这个问题少说也占80%吧?下面的20%是细微的一些细节。做架构首要抓西瓜,实在不得已才丢芝麻。

      下一步就是怎么样优化你的系统。先要做一些调查。业务组是首当其冲,因为他们是一线的工作人员,他们对于客户需要什么,他们需要什么无比的了解。所以不要放过。第二个是谁?以前做架构的那个人,他肯定知道以前为什么怎么做,怎么做的好处和坏处,等等。所以这个人也有价值。第三个呢?你的领导啊!他对于这个东西肯定有自己的想法,比如一些性能问题的要求等等。把这些全部收集起来,然后一个一个看你测试的功能点能否满足?能,那么就万事大吉,不能?辛苦一下,自己动手改一下呗!

       这样,再经过测试人员测试一下,你的系统基本上已经没啥问题了。

      你上面去调查了细节的需求,你是不是对你这个东西很明白了?是不是可以做出最适合你的架构出来了?比如是否需要读写分离,是否需要热备份等等。这样架构图画出来后,和运维兄弟商量一下是不是就八九不离十了?

     那么你下面还要做什么?跟踪这个优化方案,至少1-2年,在这1-2年内,你还会碰到不同BT的需求,不管这些需求是因为你的疏忽,还是运维人员的管理方便等等原因。总之,总会有更改在等着你。也许你认为这些需求实在是太无语,但是存在即合理。所以面对它,解决它,这才是你一个人的价值体现。听过一句话吗?20%的人完成了公司80%有价值的工作,80%的人完成了公司20%有价值的工作。不管你做什么,总要做前面那个20%。