八种架构设计模式及其优缺点.docx

《八种架构设计模式及其优缺点.docx》由会员分享，可在线阅读，更多相关《八种架构设计模式及其优缺点.docx（18页珍藏版）》请在三一办公上搜索。

1、八种架构设计模式及其优缺点八种架构设计模式及其优缺点概述（上）1. 什么是架构我想这个问题，十个人回答得有十一个答 案，因为另外的那一个是大家妥协的结果。哈哈， 我理解，架构就是骨架，如下图所示：人类的身体的支撑是主要由骨架来承担 的，然后是其上的肌肉、神经、皮肤。架构对于 软件的重要性不亚于骨架对人类身体的重要性。2. 什么是设计模式这个问题我问过的面试者不下于数十次， 回答五花八门，在我看来，模式就是经验，设计 模式就是设计经验，有了这些经验，我们就能在 特定情况下使用特定的设计、组合设计，这样可 以大大节省我们的设计时间，提高工作效率。作为一个工作10年以上的老码农，经历的 系统架构设计

2、也算不少，接下来，我会把工作中 用到的一些架构方面的设计模式分享给大家，望 大家少走弯路。总体而言，共有八种，分别是：1. 单库单应用模式：最简单的，可能大家都见 过2. 内容分发模式：目前用的比较多3. 查询分离模式：对于大并发的查询、业务4. 微服务模式：适用于复杂的业务模式的拆解5. 多级缓存模式：可以把缓存玩的很好6. 分库分表模式：解决单机数据库瓶颈7. 弹性伸缩模式：解决波峰波谷业务流量不均 匀的方法之一8. 多机房模式：解决高可用、高性能的一种方 法如上图所示，这种模式一般只有一个数据 库，一个业务应用层，一个后台管理系统，所有 的业务都是用过业务层完成的，所有的数据也都 是存储

3、在一个数据库中的，好一点会有数据库的 同步。虽然简单，但是也并不是一无是处。优点：结构简单、开发速度快、实现简单， 可用于产品的第一版等有原型验证需求、用户少 的设计。缺点：性能差、基本没有高可用、扩展性 差，不适用于大规模部署、应用等生产环境。4.内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模 式，常见的应用场景是使用CDN技术把网页、 图片、CSS、JS等这些静态资源分发到离用户 最近的服务器。这种模式的一般设计见下图:enw公存愤芯sI f卜载 I1上传*=T r. O客户端K客户端MP业聋教据庠上住壹御瞄f一:KDSII !码花原创I如上图所示，这种模式较单库单应用模

4、式多了一个CDN、一个云存储OSS（七牛、又拍等 雷同）。一个典型的应用流程（以用户上传、查看 图片需求为例）如下：1.上传的时候，用户选择本地机器上的一个图 片进行上传2程序会把这个图片上传到云存储OSS上， 并返回该图片的一个URL3. 程序把这个URL字符串存储在业务数据库 中，上传完成。4詹看的时候，程序从业务数据库得到该图片的URL5.程序通过DNS查询这个URL的图片服务器liiJ6. 智能DNS会解析这个URL，得到与用户最 近的服务器（或集群）的地址A7. 然后把服务器A上的图片返回给程序8. 程序显示该图片，查看完成。由上可知，这个模式的关键是智能DNS， 它能够解析出离用户

5、最近的服务器。运行原理大 致是：根据请求者的IP得到请求地点B，然后通过计算或者配置得到与B最近或通讯时间最 短的服务器C，然后把C的IP地址返回给请求 者。这种模式的优缺点如下：优点：资源下载快、无需过多的开发与配 置，同时也减轻了后端服务器对资源的存储压 力，减少带宽的使用。缺点：目前来说OSS，CDN的价格还是稍 微有些贵（虽然已经降价好几次了 ），只适用于中 小规模的应用，另外由于网络传输的延迟、CDN的同步策略等，会有一些一致性、更新慢方面的 问题八种架构设计模式及其优缺点概述（中）2017-03-31码农原创码农原创码农原创文章，适合程序员、工程师、架构师等一切与软件开发相关的工作

6、者阅读在上篇文章中tLH文中,介绍了八种架构设计模式中的两种，既：单库单应用模式、内容分发模式，没有读瞄同学请手动微信关注“码农原创”公众号，在历史消息中寻找。接下来继续介绍三种架构模式，分别是：查询分离模式微服务模式，多级缓存模式。1.查询分离模式这种模式主要解决单机数据库压力过大，从而导致业务缓慢甚至超时，查询响应时间变长的问题，也包括需要大量数据库服务器计算资源的查询请求。这 个可以说是单库单应用模式的升级版本皿技术架构迭代演进过程中的必经之路。这种模式的一般设计见下图:云布却DSSI皆屈台皆理系链K产宿江r概於上皓心夕娥据”褊我饼库LE) 4yW山务敷抓料fibHDS.丝度鞘如上图所示

7、，这种模式较单库单应用模式与内容分发模式多了几个部分, 一个是业务数据库的主从分离，一个是引入了 ES，为什么要这样？都解决了哪些痛点，下面具体结合业务需求场景进行叙述。场景一：全文关键词检索我想这个需求，绝大多数应用都会有，如果使用传统的数据库技术，大部 分可能都会使用like这种SQL语句，高级一点可能是先分词，然后通过分词 皿。乂相关的记录。SQL性能问题与全表扫描机制导致了非常严重的性 能问题，现在基本上很少见到。这里的ES是ElasticSearch的缩写，是一种查询引擎，类似的还有Solr 等，都差不多的技术，ES较Solr配置简单.使用方便，所以这里选用了它。另外，ES支持横向扩

8、展，理论上没有性能的瓶虱同时，还支持各种插件.自定 义分词器等，可扩展性较强在这里，使用ES不仅可以替代数据库完成全文检 素功能，还可以实现诸如分页.排序,分组、分面等功能具体的，请同学们自 行学习之那怎么使用呢？一个一般的流程是这样的:1. 服务端把一条业务数据落库2. 服务端异步把该条数据发送到ES3. ES瞬条记录按照规则,配置放入自己的索引库4. 客户端查询的时候，由服务端把这个请求发送到ES，得到数据后，根据需求拼装、组合数据，返回给客户端实际中怎么用，还请同学们根据实际情况做组合、取舍 场景二：大量的普通查询这个场景是瞄们的业务中的大部分辅助性的查询，如：取钱的时候先查 询一下余额

9、，根据用户的ID查询用户的记录，取得该用户最新的一条取钱记录 等,我们肯定是要天天要用的，而且用的还非常多，同时呢，我们的写入请求也 是非常多的，导致大量的写入、查询操作压向同一数据库，然后，数据庵桂了, 系统挂了，领导生气了，被开除了，还不起房贷了，露宿街头了，老婆跟别人 了，不敢想，所以要求我们必须分散数据库的压力，一个业界较成熟的方案就 是数据库的读写分离，写的时候入主库，读的时候读从库。这样就把压力分散到不同的数据库了，如果一个读库性能不行，扛不住的话，可以一主多从，横向扩 展。可谓是一剂良药啊！那怎么使用呢？一个一般的流程是这样的:1. 服务端把一条业务数据落库2. 数据库同步或异步

10、或半同步把该条数据复制到从库3. 服务端读数据的时候直接去从库瞄成的数据比较简单吧，一些聪明的、爱思考的，上进的同学可能发现问题了，也包 括上面介绍的场景一，就是延迟问题，如：数据还没有到从库，我就马上读，那 么是读不到的，会发生问唤对于这个问题，各家公司解决的思路不一样，方法不尽相同。一个普遍的 解决方案是：读不到就读主库，当然这么说也是有前提条件的，但具体的方案这 里就不展开了，我可能会在接下来的分享中详解各种方案。另外，关于数据库的复制模式，还请同学们自行学习，太多了，这里说不 清,该总结一下这种模式的优缺点的了，如下:优点：减少数据库的压力，理论上提供无限高的读性能，间接提高业务（写）

11、 的性能，专用的查询.素引,全文（分词）解决方案。缺点：数据延迟，数据一致性的保证。2.微服务模式上面的模式看似不错，解决了性能问题，我可以不用露宿街头了,老婆还 是我的，哈哈但是软件系统天生的复杂性决定了，除了性能，还有其他诸如高可用,健壮性 等大量问题等待我们解决，再加上各个部门间的撕逼.扯皮，更让珈码农上 加，所以花花继续吧 部服务模式可以说是最近的热点，花花绿氟 大大小国内国外的公司 都在鼓吹，实践这个模式，可是大部分都没有弄清楚为什么要这么做，也并不知 道这么做有什么好处、坏处，在这里，我将以我自己的亲身实践说_下我对这个模式的看法，不喜勿喷！随着业务与人员的增加，遇到了如下的问题:

12、1.单机数据库写请求大增加，导致数据库压力变大2.据库一旦挂了，那么整个业务都挂了3.业务代码越来越多，都在一个GIT里，越来越难以维护4.代码腐化严重、臭味越来越浓5.上线越来越频繁，经常是一个小功能的修改，就要整个大项目要新编译6.部门越来越多，该哪个部门改动大项目中的哪个东西，撕逼的厉害7.其他一些外围系统直接连接数据库，导致一旦数据库结构发生变化，所有的相关系统都要通知，甚至对修改不敏感的系统也要通知8.每个应用服务器需要开通所有的权限网络,FTP,各种各样的，因为每个服务0部署的应用都是一样的,g螂ga啤瞬，朝iy，biAi皿互沮诺，dm蕉疑互湖I胡，雌蜩峻S3 迎 WWQSB，栖早

13、号雌妙毒，嬲整咽WR3-承够，WHSXM，解&碰晦，零蚓BTIK珀esEE5泗把琅朝，导目旦I弟阵3B0BPH 3dd昔倒EdV:buj供础im 顺,:mmz脚岫, ati明琢*考砌咽瞩警犀啊福日塞，虹眦御 .6那么，这么做是否真的解决上述问题了呢？不玩虚的，一个个来说。对于 问题一，由于拆分成了多个子系统，系统的助被分散了，而各个子系统都有自 己的数据库实制，所以数据库的压力变小。对于问题二，一个子系统A的数据库挂了，只是影响到系统A和使用系统A的那些功能，不会所有的功能不可用，从而解决一个数据库桂了，导致所有功能不可用的问题.问题三、，也因为拆分得到了解决，各个子系统有自己独立的GIT代码

14、库，不会相互影响。通用的模块可通过库、服务平台的形式解决。问题五，子系统入发生改变，需要上线，那么我只需要编译A，然后上线 就可以了，不需要其他系统做同样的事情。问题六，顺成了康定律，我部门该干什么事,输出什么，也通过服务的 形式暴露出来，我部只管把我部的职责软件功能做好就可以问题七，所有需要我部数据的需求，都通过接口的形式发布出去，客户通 过接口获取数据，从而屏蔽了底层数据库结构，甚至数据来源，我部只需保证我 部的接口契约没有发生变化即可，新的需求增加新的接口，不会影响者的接口。问题八，不同的子系统需要不同的权限，这个问题也优雅的解决了。问题九，暂时控制住了复杂性，我只需控制好大的方面，定义

15、好系统边界、 接口、大的流程，然后再分而治之、逐个击破、合纵连航:些瞄LIK，颇睥副睇，啊咽别职蛔酬虹.，事邮一咽四塞i哲首岫瑙聿，呈哪囹SJWTfiBiaf州SKS，YM*SW 倒旧 算皿朝昭岫明a皿此围 *阳g 知:弥。瞅取mrm申壬，囹皿，G邕皿，hk : w匚, i甲懿咽蹄*非申做&坎&比31: g章咽强Ohk-申% swwm，咽蜒*旦 aw/g旦：r，蜒aws Btftan avusam imw跆 q 倍A 并蜒虹( amws-SH aswu MHS科飒岫 bN 割 rn，和Ng鲫01测1厦础咬，VSioBuiq i酒ns耕a旭|擘蛔神IB目-码残原创RPC HI共再理免如上图所示，

16、一般在三个地方加入缓存，一个是客户端处，一个是API网 关处，一个是具体的后端业务处，下面分别介绍。客户端处缓存：这个地方加缓存可以说是效果最好的-无延迟,因为不用 经过长长的网络链条去后端业务处获取数据，从而导致加载时间过长，客户流失 等损失。虽然有CDN的支持，但是从客户端到CDN还是有网络延迟的，虽然 不大。具体的技术依据不同的客户端而定，对于WEB来讲，有浏览器本地缓存、Cookie. Storage.缓存策略等技术；对科？来讲，有本地数据库.本地文件,本地内存.进程内缓存支持。以上提到的各种技术有兴趣的同学可以继续展开来学习,如果客户端缓存没有命中，那么就会去后端业务拿数据，一般来讲

17、， 都会有个API网关，在这里加缓存也是非常有必要的。API网关处缓存：这个地方加缓存的好处是不用把请求发送到后方，直接在这里就处理了，然后返回给请求者。常见的技术，如http请求，API网关用 的基本都是 nginx,可以使用nginx本身的缓存模块，也可以使用Lua+Redis技术定制化其他的也都大同小异。后端业务处：这个我想就不用多说了，大家应该差不多都知道，什么Redis,Memcache,Jvm 内等等，不熬述了。实践中，要结合具体的实际情况，综合利用各级缓存技术，使得各种请求 最大程度的在到达后端业务之前就被解决掉，从而减少后端服务压力，减少占用 带宽、增强用户体验至于是否只有这三个地方加缓存，我觉得要活学活用，心 法比剑法重要！总结一下这个模式的优缺点：优点：抗住大读请求，减少后端压力。 *缺点：数据一致性问题较突出，容易发生崩，即：如果客户端缓存失效、API网关缓存失效，那么所有的大请求瞬间压向后端业务系统扇果可想而知。本次分享的中篇到此结束，接下来的下篇将介绍最后三种模式：分库分表模式、弹性伸缩模式、多机房模式，相对来讲技术含更高，敬请期待!