浅谈系统架构的几个方面

今天心血来潮,突然想起以前对于架构设计的理解,也是多年来总结的一个结果,分享给大家,欢迎拍砖!

我从三方面来阐述架构设计吧:

一、高性能(High Performance)

高性能我觉得分三个方面:

1. 基础软件的高效性:基础软件的服务能力,在很多程度上决定了系统的吞吐能力,因此将基础软件的性能提升到极致非常重要,可以大面积节省设备成本。往往解决同一个问题,可以有多种基础软件选择,比如web server,可选的基础软件也比较多,比如apache、lighthttpd, nginx等,如果解决同样的问题,那么选择性能好的就可以有更高的吞吐,我们公司大力发展自主研发的基础软件,因此也当不断提升基础软件的性能,效益大大的。

2. 缓存的设计:缓存的设计,对于任何一个需要提高性能和吞吐能力的系统,都是非常关键的要素。cpu架构体系如此,内存条架构如此,软件设计更是如此。针对不同的场景,应该设计不同的缓存工具,页面缓存用squid,数据键值对用memcache或redis。缓存工具应该根据应用场景的不同,提供不同的缓存工具,这样利于在特定场景中,将缓存的性能提升到极致。

3. cdn等服务的合理使用:如果是web程序,那么使用cdn太重要了,可以将访问量的85%以上由几百个cdn节点来分担,有效减轻主服务器的访问压力。

我个人不赞同用一种缓存软件,解决所有缓存问题,这样的情况,往往在某些场景下,性能不是最出色的。

一个缓存工具解决一类问题,我们可以将缓存类型进行分类,制作出不同种类的缓存工具,解决全方位的问题,并且保持非常高的性能。

有些数据量很大,需要的缓存也很大,如果全部用内存,那估计成本非常高;

有些数据量很小,但是访问量非常大,那就应该全部用内存;

有些数据量虽然很大,但是访问量大的集中在一小部分数据,那么这部分焦点缓存,就应该在内存中,根据合理的算法,让焦点进入缓存;

有些数据量很大,访问也非常分散,不可能全部放入内存,这个情况比较难办,但是总能设计出专有系统解决访问效率问题。

缓存设计中,有一个核心指标,就是缓存命中率。这个指标很关键,缓存设计是否成功,看这个指标就ok了。

3. 减少io、网络调用(或开销):一个高性能的系统,应该尽量减少io和网络调用,因为这些都是慢速设备,性能本身就不是很理想,如果调用量特别大的话,系统整体性能就降下来了。一个系统的整体性能如何,不是由最快的部分决定的,而是最慢的部分决定的。这个我们现实生活中也经常见到,一台电脑,cpu性能超高,就是内存很小,速度马上就下来了,因为需要大量的进行磁盘操作。因此,减少慢速设备的访问,基本做到没有io开销,这是理想的系统设计目标。

我个人对于互联网的架构体系中的逻辑层保持疑问?完全没必要跨网络访问,也同样可以做到分层开发,跨网络访问不但导致内部带宽使用量很高,而且性能上也不是最理想的,最恐怖的是跨机房模块调用,大量消耗网络带宽,降低系统整体性能。

    4. 数据库的访问性能优化:数据库索引的建立,数据库参数的调优也很关键,数据库是个典型的慢速设备,mysql之类的数据库都是很早以前设计的,在目前海量访问的背景下跑的比较吃力,腾讯云的云数据做了软硬件各方面的优化,qps最高可达24万,是个不错的选择。

5. 前端web类优化:前端web页面设计,我非常赞同yslow的14条,对于网站类产品,其实性能优化工作,对于页面进行优化是和后台性能优化同等重要的。除了yslow的14条之外,我个人觉得页面尺寸,js、css尺寸也要做相应的规范。腾讯在这方面做的很好,首屏页面打开时间都非常快。

二、高可靠性(High Available)

高可靠性,我所理解的就是容灾能力,当系统故障发生时,系统能够无间断的提供服务,这个业界是有些衡量方法的。

SLA(Service Level Agreement):服务品质协议。这个词运营那边应该会经常听到,但是架构设计时需要考虑可靠性的问题,再配合运营的一些手段。我们经常听到99.99%的可靠性,就是说允许:365天*0.01%=52.56(分钟),允许全年故障时间为53分钟,99.999%的可靠性就是全年故障时间5分钟。

为了做到上面的可靠性,在系统设计时,我们经常需要考虑的问题是:系统还有单点吗?系统故障时,能自动将故障机切换掉吗?我们是不是做了相应的冗备,是不是机房也做了冗备(成本有点高哦,但是公司总体做机房冗备,平均成本应该能下来)?我们的系统有健康检查机制吗,能不能在用户发现故障前,就已经探测到,脚本并且做了自动化切换?等等。

为了做到可靠性,现在也有不少工具,用于不同场景,lvs, haproxy, heartbeat, keepalived等等,如果没有现成的可用工具,那就自己写脚本实现健康检测吧。

要检测一个服务是否正常?用它,是最好的健康检测机制。

三、高扩展性(High Scalable)

扩展性:系统是否可以不断横向扩展下去,如果性能遭遇整体性能瓶颈,好的系统应该只要增加设备,就能扩大吞吐!

我们在设计系统时,每个层面都应该是可以横向扩展的。

今天就说这个多吧!

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏后端技术探索

58同城沈剑:好的架构源于不停地衍变,而非设计

对很多创业公司而言,很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时,如果系统初期就设计一个千万级并发的流量架构,很难有公司可以支...

9710
来自专栏资深Tester

软件测试人员:你们是如何测试需求变动频繁的项目?

25430
来自专栏子勰随笔

SDK之我理解的SDK

326100
来自专栏云计算D1net

多云应用性能:IT专业人士的移动目标

你的应用的设计好坏会在多云环境中对性能产生影响。使用以下这些监控和管理技术来避免应用的性能问题。 对于大多数IT组织来说,“性能”意味着响应时间或用户体验的质量...

27740
来自专栏web前端教室

有同学问了我一个很多前端都在担忧的问题

如图,这是今天一个先行者计划的成员,在同我聊天的时候提到的问题。这个问题确实是客观存在的,前端变化快,一会今天这个了,一会明天又那个了。 “我都有点动摇了,我原...

21080
来自专栏Java学习网

程序员需谨记的8条团队开发原则

  当你从学校出来,找到第一份软件开发工作的时候,你就不再是一个单独作战的程序员了,你将会有一个团队,你的一举一动也将直接影响团队的效率和产出。下面这8条团队开...

35550
来自专栏云计算D1net

混合云的性能管理状态

混合云的性能管理 如今,IT管理员在如何运行关键业务的工作负载方面比以往任何时候都有着更多的选择。其中包括物理,虚拟,本地,云计算,或一些组合。这就是为什么找...

33550
来自专栏EAWorld

普元DevOps5.2版本新特性发布

伴随新版本的发布,我们团队也对这次迭代做了些回顾,有值得分享的新特性与设计,也有一些需加强的能力,借此与大家分享。

35340
来自专栏云计算D1net

云原生机制的三个核心思想及其未来之路

摆脱临时性自动化方案之定位,发挥优势以实现可预测功能。 ? 您能否以每周为单位向客户发布各类新功能?甚至进一步达到以每天乃至每小时为单位?新晋开发人员能否在上班...

27340
来自专栏软件测试经验与教训

质量管理体系之如何使用测试文档模板?

40360

扫码关注云+社区

领取腾讯云代金券