系统架构设计时的一些指导思想
一,分层分级,设计需要具有柔性。 分层就是说对系统进行多层次的切分,在常见的B/S架构设计中,我们常常分成:web接入层,逻辑处理层 ,数据层(可能又分成cache层和Db/file层)。上层的只能调用下层的服务而不能进行跨层调用,比如web接入层只能调用逻辑处理层,而不能直接调用数据层。上层保护下层,而下层通过接口为上层提供服务但永远不相信上层并且验证上层的输入。 有时候,我们
一,分层分级,设计需要具有柔性。
分层就是说对系统进行多层次的切分,在常见的B/S架构设计中,我们常常分成:web接入层,逻辑处理层
,数据层(可能又分成cache层和Db/file层)。上层的只能调用下层的服务而不能进行跨层调用,比如web接入层只能调用逻辑处理层,而不能直接调用数据层。上层保护下层,而下层通过接口为上层提供服务但永远不相信上层并且验证上层的输入。
有时候,我们对各个层可能还需要根据实际情况进行分级,比如逻辑处理层,可能再分成逻辑处理层
level1,level2.level3等。
各个层的设计需要具有柔性和大气(freeman语)。我的理解,柔性包括了几个方面:
1,可以快速植入新的逻辑而系统架构不需要过多的调整和重构,实现“既来之,则安之”;
2,可以根据需要快速而低成本的卸装不需要的逻辑和模块。
二,抓住主要模块并重点处理和实现好核心模块。
系统设计首先离不开系统分析,在分析中,我们首先对模块进行拆分,按优先级分成p0,p1,p2等,并且我们需要花精力重点处理和实现好核心模块,那什么是核心模块呢?就是说系统离开了这个模块根本跑不起来,根本玩不转。
三,让web接入层轻装上阵。
web接入层的运转需要web server的支持,或者说web进程是在web 容器中运转的,因此,web接入层的性能跟web 容器密切相关,在设计中,我们常常把更多的业务逻辑放到接入层来实现,在快速的实现和没有性能压力的情况下看似没问题,但我们不推荐这样的做法。顾名思义,web层的主要工作就是负责接入和转发,自己不处理业务逻辑。在实现中,web层只负责:输入参数验证,转发请求到后台(业务处理层)处理,接收后台数据输出并进行模板替换和数据显示等功能。
四,业务处理层。
业务处理层是系统的主要核心,主要由承担各个业务模块的server群组成,这些server分成:调用第三方接口的中转server,调用cache层的查询server,调用cache或者db/file的更新server等。这些server是可扩展的,可配置的,可运营的,可伸缩的,随着业务量的增加,能够快速实现部署上线。
server的设计需要考虑:是无状态的还是有状态的?支持多进程吗?支持多机器部署吗?
五,数据层。
根据需要可以分成cache层和db/file层。cache层需要考虑命中率,用户行为是否只需要cache 20%的活跃数据就可以达到80%的效果?数据的存储是使用db还是file,甚至只是内存?根据数据的重要性可以选择不同的存储介质,db需要主从备份吗?备份是冷备还是热备?各自的成本如何衡量和取舍?db层是否是可以根据号段多机器部署的。
六,区分用户行为和系统行为以及处理好两者的转化和统一。
在系统运转的触发类型上,可以分为用户行为和系统行为。用户行为触发系统的运转,比如用户点击页面某
个按钮触发系统文件下发,因此系统文件下发的行为是由于用户点击了下发按钮触发的,如果用户不点击,系
统就永远不触发这个行为,而用户每点击一次就触发一次。而对系统行为,则不是由于用户动作触发的,是系
统自身或者运营需要而线下触发的,比如定时批量生成静态页面。
在某种情况下,我们能够对两者进行转化,比如:用户A打开主页index.php,这是用户触发的行为,index.php则从后台开始取到所有需要的数据,然后进行模板替换后输出给用户,只要用户打开一次,index.php就得从后台拿一次数据进行显示,假如我们这里的数据更新是没必要实时的,则我们可以通过在线下先把数据拿出来直接替换成静态模板,生成静态页面文件index.html,这样用户打开首页,就只是触发拉取静态文件index.html进行显示,而从后台拉取数据和模板替换的行为已经跟用户触发的动作切断了,实现了用户行为到系统行为的转化,同理,我们也可以实现系统行为到用户行为的转化。
七,区分必要路径和非必要路径,重点处理好必要路径上每个环节的异常。
必要路径是系统要跑起来必须经过和执行的业务流程,离开这个执行路径系统就挂死,系统就玩不转,因此
我们称为必要路径,非必要路径是系统可以绕开也能正常跑的执行流程。我们期望系统的必要路径越少越好,
或者通过我们的努力和相关策略,实现必要路径到非必要路径的转化,或者弱化必要路径。但是,很遗憾的是
,在一个系统里面,我们没办法完全消除必要路径,因此处理好必要路径的每个环节就显得非常必要和重要,
这涉及到一个系统的容错性和健壮性,俗话说就是怎么玩也玩不死。下面举个例子:必要路径:
A-->B-->C, 如果A处理成功,就执行B, 如果B成功,就执行C, 但问题是如果A失败呢?这种情况下我们系统挂死还是有默认的处理策略使得在A失败的情况下系统仍然能够走到B而把必要流程继续执行下去?因此,重点处理好每个环节就是提高我们系统健壮性的用力点。
八:其他。
处理好更新操作和查询操作的分离
1,把更新操作和查询操作按操作对象进行切分,比如更新主db,查询备Db,
2,按号段切分,不同号码段范围的用户定位到不同的更新和查询对象;
3,按时间段切分,不同时段支持不同类型,比如A时段只能更新,B时段只能查询等。
系统的防雪崩考虑,Cache查询的保护,系统的投入/产出的衡量,收合自如的考虑(启用子域名进行DNS层的分离等)等等。
tenfyguo
2009年3月7日
更多推荐
所有评论(0)