八种架构设计模式及其优缺点Word格式文档下载.docx
- 文档编号:20686396
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:10
- 大小:21.73KB
八种架构设计模式及其优缺点Word格式文档下载.docx
《八种架构设计模式及其优缺点Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《八种架构设计模式及其优缺点Word格式文档下载.docx(10页珍藏版)》请在冰豆网上搜索。
3.查问分别模式:
对于大并发的查问、业务
4.微服务模式:
合用于复杂的业务模式的拆解
5.多级缓存模式:
能够把缓存玩的很好
6.分库分表模式:
解决单机数据库瓶颈
7.弹性伸缩模式:
解决波峰波谷业务流量不平均的方法之一
8.多机房模式:
解决高可用、高性能的一种方法
3.单库单应用模式这是最简单的一种设计模式,我们的大多半本科毕业
设计、一些小的应用,基本上都是这类模式,这类模式的一般设计见下列图:
如上图所示,这类模式一般只有一个数据库,一个业务应用层,一个后台
管理系统,全部的业务都是用过业务层达成的,全部的数据也都是储存在一个数据库中的,
好一点会有数据库的同步。
固然简单,但是也其实不是一无所取。
长处:
构造简单、开发速度快、实现简单,可用于产品的初版等有原型
考证需求、用户少的设计。
弊端:
性能差、基本没有高可用、扩展性差,不合用于大规模部署、应用
等生产环境。
4.内容散发模式基本上全部的大型的
网站都有或多或少的采纳这一种设计模式,常有的应用处景是使用CDN技术把网页、图片、
CSS、JS等这些静态资源散发到离用户近来的服务器。
这类模式的一般设计见下列图:
如上图所示,这类模式较单库单应用模式多了一个CDN、一个云储存
OSS(七牛、又拍等相同)。
一个典型的应用流程(以用户上传、查察图片需求为例)以下:
1.上传的时候,用户选择当地机器上的一个图片进行上传
2.程序会把这个图片上传到云储存OSS上,并返回该图片的一个URL
3.程序把这个URL字符串储存在业务数据库中,上传达成。
4.查察的时候,程序从业务数据库获得该图片的URL
5.程序经过DNS查问这个URL的图片服务器
6.智能DNS会分析这个URL,获得与用户近来的服务器(或集群)的地址A
7.而后把服务器A上的图片返回给程序
8.程序显示该图片,查察达成。
由上可知,这个模式的重点是智能
器。
运转原理大概是:
依据恳求者的IP获得恳求地址
DNS,它能够分析出离用户近来的服务
B,而后经过计算或许配置获得与
B
近来或通信时间最短的服务器
C,而后把
C的
IP
地址返回给恳求者。
这类模式的优弊端如
下:
资源下载快、无需过多的开发与配置,同时也减少了后端服务器对资源的储存压力,减少带宽的使用。
当前来说OSS,CDN的价钱仍是略微有些贵(固然已经降价好几次了),只合用于中小规模的应用,此外因为网络传输的延缓、CDN的同步策略等,会有一些一致性、更新慢方面的问题
八种架构设计模式及其优弊端概括(中)
2017-03-31码农原创码农原创
码农原创文章,合适程序员、工程师、架构师等全部与软件开发有关的工作者阅
读
在上篇文章中,介绍了八种架构设计模式中的两种,既:
单
库单应用模式、内容散发模式,没有读过的同学请手动微信关注“码农原创”公
众号,在历史信息中找寻。
接下来持续介绍三种架构模式,分别是:
查问分别模
式、微服务模式、多级缓存模式。
1.查问分别模式
这类模式主要解决单机数据库压力过大,进而致使业务迟缓甚至超时,查问响应时间变长的问题,也包含需要大批数据库服务器计算资源的查问恳求。
这个能够说是单库单应用模式的升级版本,也是技术架构迭代演进过程中的必经之路。
如上图所示,这类模式较单库单应用模式与内容散发模式多了几个部分,一个是业务数据库的主从分别,一个是引入了ES,为何要这样?
都解决了哪些痛点,下边详细联合业务需求场景进行表达。
场景一:
全文重点词检索
我想这个需求,绝大多半应用都会有,假如使用传统的数据库技术,大多半可能都会使用like这类SQL语句,高级一点可能是先分词,而后经过分词index有关的记录。
SQL语句的性能问题与全表扫描体制致使了特别严重的性能问题,此刻基本上极少见到。
这里的ES是ElasticSearch的缩写,是一种查问引擎,近似的还有Solr等,都差不多的技术,ES较Solr配置简单、使用方便,因此这里采纳了它。
此外,ES支持横向扩展,理论上没有性能的瓶颈。
同时,还支持各
种插件、自定义分词器等,可扩展性较强。
在这里,使用ES不单能够代替数据库达成全文检索功能,还能够实现诸如分页、排序、分组、分面等功能。
详细的,请同学们自行学习之。
那怎么使用呢?
一个一般的流程是这样的:
1.服务端把一条业务数据落库
2.服务端异步把该条数据发送到ES
3.ES把该条记录依照规则、配置放入自己的索引库
4.客户端查问的时候,由服务端把这个恳求发送到ES,获得数据后,依据需求拼装、组合数据,返回给客户端
实质中怎么用,还请同学们依据实质状况做组合、弃取。
场景二:
大批的一般查问
这个场景是指我们的业务中的大多半协助性的查问,如:
取钱的时候先查问一下余额,依据用户的ID查问用户的记录,获得该用户最新的一条取钱记录等。
我们一定是要每日要用的,并且用的还特别多。
同时呢,我们的
写入恳求也是特别多的,致使大批的写入、查问操作压向同一数据库,而后,数据库挂了,系统挂了,领导生气了,被开除了,还不起房贷了,露宿街头了,老
婆跟他人跑了,......
不敢想,因此要求我们一定分别数据库的压力,一个业界较成熟的方案就是数据库的读写分别,写的时候入主库,读的时候读从库。
这样就把压力分别到不同的数据库了,假如一个读库性能不可以,扛不住的话,能够一主多从,横向扩展。
堪称是一剂良药啊!
2.数据库同步或异步或半同步把该条数据复制到从库
3.服务端读数据的时候直接去从库读相应的数据
比较简单吧,一些聪慧的、爱思虑的、长进的同学可能发现问题了,也包含上边介绍的场景一,就是延缓问题,如:
数据还没有到从库,我就立刻读,那么是读不到的,会发生问题的。
对于这个问题,各家企业解决的思路不相同,方法不尽相同。
一个广泛的解决方案是:
读不到就读主库,自然这么说也是有前提条件的,但详细的方案这里就不一一睁开了,我可能会在接下来的分享中详解各种方案。
此外,对于数据库的复制模式,还请同学们自行学习,太多了,这里说不清。
该总结一下这类模式的优弊端的了,以下:
减少量据库的压力,理论上供给无穷高的读性能,间接提升业务(写)的性能,专用的查问、索引、全文(分词)解决方案。
数据延缓,数据一致性的保证。
2.微服务模式
上边的模式看似不错,解决了性能问题,我能够不用露宿街头了、妻子仍是我的,哈哈。
但是
软件系统天生的复杂性决定了,除了性能,还有其余诸如高可用、强健性等大批问题等候我们解决,再加上各个部门间的撕逼、扯皮,更让我们码农火上浇油,因此
持续吧......
微服务模式能够说是近来的热门,花花绿绿、大大小小、国内外国的企业都在鼓动,实践这个模式,但是大多半都没有弄清楚为何要这么做,也其实不知道这么做有什么利处、弊端,在这里,我将以我自己的亲自实践说一下我对这个模式的见解,不喜勿喷!
跟着业务与人员的增添,碰到了以下的问题:
1.单机数据库写恳求量大批增添,致使数据库压力变大
2.数据库一旦挂了,那么整个业务都挂了
3.业务代码愈来愈多,都在一个GIT里,愈来愈难以保护
4.代码腐化严重、臭味愈来愈浓
5.上线愈来愈屡次,常常是一个小功能的改正,就要整个大项目要从头编译
6.部门愈来愈多,该哪个部门变动大项目中的哪个东西,撕逼的厉害
7.其余一些外头系统直接连结数据库,致使一旦数据库构造发生变化,全部的有关系统都要通知,甚至对改正不敏感的系统也要通知
8.每个应用服务器需要开通全部的权限、网络、FTP、各种各种的,因为每个服务器部署的应用都是相同的
9.作为架构师,我已经失掉了对这个系统的把控......
为认识决上述问题,我司使用了微服务模式,这类模式的一般设计见下列图:
如上图所示,我把业务分块,做了垂直切分,切成一个个独立的系统,每个系统各自衍化,有自己的库、缓存、ES等协助系统,系统之间的及时交互经过RPC,异步交互经过MQ,经过这类组合,共同达成整个系统功能。
那么,这么做能否真的解决上述问题了呢?
不玩虚的,一个个来说。
对于问题一,因为拆分红了多个子系统,系统的压力被分别了,而各个子
系统都有自己的数据库实例,因此数据库的压力变小。
对于问题二,一个子系统A的数据库挂了,不过影响到系统A和使用系统A的那些功能,不会全部的功能不可以用,进而解决一个数据库挂了,致使全部功能不可以用的问题。
问题三、四,也因为拆分获得认识决,各个子系统有自己独立的GIT代码库,不会互相影响。
通用的模块可经过库、服务、平台的形式解决。
问题五,子系统A发生改变,需要上线,那么我只要要编译A,而后上线就能够了,不需要其余系统做相同的事情。
问题六,适应了康威定律,我部门该干什么事、输出什么,也经过服务的形式裸露出来,我部尽管把我部的职责、软件功能做好就能够。
问题七,全部需要我部数据的需求,都经过接口的形式公布出
去,客户经过接口获得数据,进而障蔽了基层数据库构造,甚至数据根源,我部
只要保证我部的接口契约没有发生变化即可,新的需求增添新的接口,不会影响
老的接口。
问题八,不同的子系统需要不同的权限,这个问题也优雅的解
决了。
问题九,临时控制住了复杂性,我只要控制好大的方面,定义好系统界限、接口、大的流程,而后再分而治之、逐一击破、合纵连横。
当前来说,全部问题获得解决!
bingo!
但是,还有很多其余的副作用会随之产生,如RPC、MQ的超高稳固性、超高性能,网络延缓,数据一致性等问题,这里就不睁开来讲了,太多
了,一本书都讲不完。
此外,对于这个模式来说,最难掌握的是度,牢记不要切分过细,我见过一个功能一个子系统,上百个方法分红上百个子系统的,真的是太甚分了。
实践中,一个较为可行的方法是:
能不分就不分,除非有特别必需的原因!
。
相对高性能,可扩展性强,高可用,合适于中等以上规
模企业架构。
复杂、度不好掌握。
指不单需要一个能在高层把控大方向、大流程、整体技术的人,还需要能够针对各个子系统有针对性的开发。
掌握不好度或许滥用的话,这个模式事与愿违!
3.多级缓存模式
这个模式能够说是应付超高查问压力的一种广泛采纳的策略,基本的思想就是在全部链路的地方,能加缓存就加缓存,以下列图所示:
如上图所示,一般在三个地方加入缓存,一个是客户端处,一个是API网关处,一个是详细的后端业务处,下边分别介绍。
客户端处缓存:
这个地方加缓存能够说是成效最好的---无延缓。
因为不用经过长长的网络链条去后端业务处获得数据,进而致使加载时间过长,客户流失等损失。
固然有CDN的支持,但是从客户端到CDN仍是有网络延缓的,固然不大。
详细的技术依照不同的客户端而定,对于WEB来讲,有阅读器当地缓存、Cookie、Storage、缓存策略等技术;
对于APP来讲,有当地数据库、当地文件、当地内存、进度内缓存支持。
以上提到的各种技术有兴趣的同学能够持续睁开来学习。
假如客户端缓存没有命中,那么就会去后端业务拿数据,一般来讲,都会有个API网关,在这里加缓存也是特别有必需的。
API网关处缓存:
这个地方加缓存的利处是不用把恳求发送到
后方,直接在这里就办理了,而后返回给恳求者。
常有的技术,如http恳求,API网关用的基本都是nginx,能够使用nginx自己的缓存模块,也能够使用Lua+Redis技术定制化。
其余的也都迥然不同。
后端业务处:
这个我想就不用多说了,大家应当差不多都知道,什么Redis,Memcache,Jvm内等等,不熬述了。
实践中,要联合详细的实质状况,综合利用各级缓存技术,使得各种恳求最大程度的在抵达后端业务以前就被解决掉,进而减少后端服务压力、减少占用带宽、加强用户体验。
至于能否只有这三个地方加缓存,我感觉要活学活用,心法比剑法重要!
总结一下这个模式的优弊端:
抗住大批读恳求,减少后端压力。
数据一致性问题较突出,简单发生雪崩,即:
假如客户端缓存无效、API网关缓存无效,那么全部的大批恳求瞬时压向后端业务系统,结果可想而知。
本次分享的中篇到此结束,接下来的下篇将介绍最后三种模式:
分库分表模式、弹性伸缩模式、多机房模式,相对来讲技术含量更高,敬请期望!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 架构 设计 模式 及其 优缺点