系统架构设计的核心要素
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
系统架构设计的核心要素
目录
一、性能 (3)
(1)web前端性能优化: (3)
(2)应用服务器性能优化: (4)
(3)数据库层优化: (5)
(4)衡量网站性能的指标 (6)
二、安全性 (6)
三、可用性 (8)
四、扩展性 (9)
五、伸缩性 (10)
架构中五个重要的核心指标,分别是性能、可用性、伸缩性、扩展性和安全性这5个架构指标
一、性能
性能就是核心要素之一,不然我为什么架构设计?随随便便一个lowlow的系统上线就好了。
所以性能优化是很多小公司卖不去过的坎。这么说吧,当然优化网站性能的手段也非常多:(1)web前端性能优化:
1.浏览器访问优化(浏览器缓存、页面压缩传输、合理布局页面、减少Cookie传输)
∙减少http请求。避免建立太多通讯链路。将js、css、图片文件尽可能合并。避免太多请求。
同时,对于系统的后端请求也尽可能进行合理的设计,来避免出现太多交互。
∙使用浏览器的缓存。http头设置Cache-Control和Expires.js文件名比如可以带时间戳。一旦有更新则更新时间戳,否则缓存;同时尽量避免同一时间更新大量静态资源。
∙对静态资源进行压缩。
∙css放置在页面最上方,js放下最下面。以提前进行css渲染。同时避免js带来的页面阻塞。
但需要case by case。比如页面dom节点需要依赖js生成,则可视情况改变文件位置。
∙减少cookie传输。同时让静态资源有独立域名,发送静态资源请求时候不发送cookie。以此减少传输代价。cookie可以通过document.cookie获取。
2.CDN加速
∙缓存图片、文件、CSS以及script脚本。但是pc上的CDN加速效果要好于移动端。经过调研发现,last-mile的延迟越高,CDN的相对有效性越差(具体见文章为什么CDN对移动客户端加速“没有”效果)。
3.反向代理
可以提供七层负载均衡(http请求进行均衡策略),并且可以提供静态资源的缓存,请求转发,防止网络攻击等。比较流行的有nginx。
(2)应用服务器性能优化:
如果请求静态界面不卡了,但是动态数据还是卡,说明MySQL处理的请求太多了,可以使用服务器本地缓存和分布式缓存,也可以通过异步操作方式来加快响应,在高并发请求的情况下,可以将多台应用服务器组成一个集群共同对外服务,提高整体处理能力,改善性能,具体如下:
1.分布式缓存(网站性能优化的第一定律:优先考虑使用缓存优化性能)
1.一般来说,存入cache的数据的读写比在2:1以上;且应该是热点数据。
2.需要考虑如果采用缓存则可能带来的数据短期内的不一致,或者如果实时更新缓存可能带来的
性能和资源开销。
3.需要考虑cache一旦失效,大量请求直接命中DB可能带来的服务性能雪崩。所以可以对cac
he采用集群化部署,以此避免丢失过多数据造成服务压力陡增。
4.对于热点数据考虑进行缓存的预热加载。比如高峰期来临前,先将热点数据提前存入缓存。以
此提高高峰期的服务性能。
5.为了避免恶意攻击,一直query不存在的数据,导致cache无法命中而频繁访问DB,可以将
不存在的数据也进行缓存并定期清理。同时有机制对恶意请求进行识别和封禁。
6.分布式缓存应该去中心化并集中管理。通过不同实例间的互不通信和同构来保证可扩展性,并
降低系统复杂度。
2.异步化(任何可以晚点做的事情都应该晚点再做,感觉像懒加载)
通过分布式消息队列来实现削峰的目的。通过业务配合技术来解决问题。比如12306的排队。
3.集群
采用集群也是服务虚拟化的一个体现。用以避免单点问题,同时提供更加高可用,高性能的服务。
4.代码优化
1.多线程中,如果是密集型计算,线程数不宜超过CPU核数。如果是IO处理,则线程数=[任务
执行时间/(任务执行时间-IO等待时间)] * CPU核数。除此之外,我们应该将对象设计成无状态对象,多采用局部对象,适当将锁细化。
2.进行资源复用。比如采用单例模式,比如采用连接池。
3.合理设置JVM参数,以最大程度避免不合理的full gc。
5.存储性能优化
关系型数据库的索引采用B+树进行实现。而很多的nosql数据库则采用了LSM树进行存储。
LSM在内存中保留最新增删改查的数据,直到内存无法放下,则与磁盘的下一级LSM树进行merge。所以对于写操作较多,而读操作更多的是查询最近写入数据的场景,其性能远高于b +树;采用HDFS结合map reduce进行海量数据存储和分析。其能自动进行并发访问和冗余备份,具有很高的可靠性。其等于是实现了RAID的功能。
(3)数据库层优化:
1.数据库层其实是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截掉,数据库层只承
担“能力范围内”的访问请求,所以,我们通过在服务层引入队列和缓存,让最底层的数据库
高枕无忧。但是如果请求激增,还是有大量的查询压力到MySQL,这个时候就要想办法解决MyS QL的瓶颈了,这时候可用使用索引、缓存、SQL性能优化等手段,还可以使用NoSQL数据库来优化数据模型、存储结构等。详细内容可关注后查看我的【mysql优化专题】,共12篇,已完结。
(4)衡量网站性能的指标
(重要的有响应时间、TPS、系统性能计数器等,通过这些指标以确定系统设计是否达到目标)
1.响应时间。
2.并发数。如果暂时没有对应的准确监控,针对不同业务模型,可以有不一样的并发数的预估。
我们的系统进行峰值并发数预估的话,有一种比较粗略的计算方式,即全天请求平均每秒并发数* 3。但也需要case by case。
3.吞吐量。比较常见的有QPS(每秒查询数)、HPS(每秒http请求数)以及TPS(每秒处理事
务数)。
4.性能计数器。包括系统负载、线程数、cpu、内存使用情况等。可以用top、free、cat /proc
/cpuinfo等命令来查看。系统负载的定义为当前被CPU执行的线程数/等待被CPU执行的总线程数。当其值与逻辑cpu个数相同时是最佳状态,其代表所有的资源都被最大限度地被利用。
但也有人认为当负载为0.7倍逻辑CPU数时最佳。
二、安全性
互联网是开放的,任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击,保护网站的重要数据不被窃取。
安全的5个要素:机密性、完整性、可用性、可控性和可审查性。