细谈八种架构"设计模式"及其优缺点概述
全栈架构社区
共 8010字，需浏览 17分钟
·
2022-06-07 23:43
什么是架构
我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。哈哈，我理解，架构就是骨架，如下图所示：
人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。
什么是设计模式
单库单应用模式：最简单的，可能大家都见过
内容分发模式：目前用的比较多
查询分离模式：对于大并发的查询、业务
微服务模式：适用于复杂的业务模式的拆解
多级缓存模式：可以把缓存玩的很好
分库分表模式：解决单机数据库瓶颈
弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一
多机房模式：解决高可用、高性能的一种方法
单库单应用模式
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。 缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。
内容分发模式
上传的时候，用户选择本地机器上的一个图片进行上传 程序会把这个图片上传到云存储OSS上，并返回该图片的一个URL 程序把这个URL字符串存储在业务数据库中，上传完成。 查看的时候，程序从业务数据库得到该图片的URL 程序通过DNS查询这个URL的图片服务器 智能DNS会解析这个URL，得到与用户最近的服务器(或集群)的地址A 然后把服务器A上的图片返回给程序 程序显示该图片，查看完成。
优点：资源下载快、无需过多的开发与配置，同时也减轻了后端服务器对资源的存储压力，减少带宽的使用。 缺点：目前来说OSS，CDN的价格还是稍微有些贵(虽然已经降价好几次了)，只适用于中小规模的应用，另外由于网络传输的延迟、CDN的同步策略等，会有一些一致性、更新慢方面的问题。
查询分离模式
这种模式主要解决单机数据库压力过大，从而导致业务缓慢甚至超时，查询响应时间变长的问题，也包括需要大量数据库服务器计算资源的查询请求。这个可以说是单库单应用模式的升级版本，也是技术架构迭代演进过程中的必经之路。这种模式的一般设计见下图：
服务端把一条业务数据落库 服务端异步把该条数据发送到ES ES把该条记录按照规则、配置放入自己的索引库 客户端查询的时候，由服务端把这个请求发送到ES，得到数据后，根据需求拼装、组合数据，返回给客户端
服务端把一条业务数据落库 数据库同步或异步或半同步把该条数据复制到从库 服务端读数据的时候直接去从库读相应的数据
优点：减少数据库的压力，理论上提供无限高的读性能，间接提高业务(写)的性能，专用的查询、索引、全文(分词)解决方案。 缺点：数据延迟，数据一致性的保证。
微服务模式
单机数据库写请求量大量增加，导致数据库压力变大 数据库一旦挂了，那么整个业务都挂了 业务代码越来越多，都在一个GIT里，越来越难以维护 代码腐化严重、臭味越来越浓 上线越来越频繁，经常是一个小功能的修改，就要整个大项目要重新编译 部门越来越多，该哪个部门改动大项目中的哪个东西，撕逼的厉害 其他一些外围系统直接连接数据库，导致一旦数据库结构发生变化，所有的相关系统都要通知，甚至对修改不敏感的系统也要通知 每个应用服务器需要开通所有的权限、网络、FTP、各种各样的，因为每个服务器部署的应用都是一样的 作为架构师，我已经失去了对这个系统的把控......
优点：相对高性能，可扩展性强，高可用，适合于中等以上规模公司架构。 缺点：复杂、度不好把握。指不仅需要一个能在高层把控大方向、大流程、总体技术的人，还需要能够针对各个子系统有针对性的开发。把握不好度或者滥用的话，这个模式适得其反！
多级缓存模式
这个模式可以说是应对超高查询压力的一种普遍采用的策略，基本的思想就是在所有链路的地方，能加缓存就加缓存，如下图所示：
优点：抗住大量读请求，减少后端压力。 缺点：数据一致性问题较突出，容易发生雪崩，即：如果客户端缓存失效、API网关缓存失效，那么所有的大量请求瞬间压向后端业务系统，后果可想而知。
分库分表模式
主机：硬件，指一台物理机，或者虚拟机，有自己的CPU，内存，硬盘等。
实例：数据库实例，如一个MySQL服务进程。一个主机可以有多个实例，不同的实例有不同的进程，监听不同的端口。
库：指表的集合，如学校库，可能包含教师表、学生表、食堂表等等，这些表在一个库中。一个实例中可以有多个库。库与库之间用库名来区分。
表：库中的表，不必多说，不懂的就不用往下看了，不解释。
主机：这是最主要的也是最重要的点，本质上分库分表是因为计算与存储资源不够导致的，而这种资源主要是由物理机，主机提供的，所以在这里分是最基本的，毕竟没有可用的计算资源，怎么分效果都不是太好的。 实例：实例控制着连接数，同时受OS限制，CPU、内存、硬盘、网络IO也会受间接影响。会出现热实例的现象，即：有些实例特别忙，有些实例非常的空闲。一个典型的现象是：由于单表反应慢，导致连接池被打满，所有其他的业务都受影响了。这时候，把表分到不同的实例是有一些效果的。 库：一般是由于单库中最大单表数量的限制，才采取分库。 表：单表压力过大，索引量大，容量大，单表的锁。据以上，把单表水平切分成不同的表。
优点：减少数据库单表的压力。 缺点：事务保证困难、业务逻辑需要做大量改造。
弹性伸缩模式
这种模式主要解决突发流量的到来，导致无法横向扩展或者横向扩展太慢，进而影响业务，全站崩溃的问题。这个模式是一种相对来说比较高级的技术，也是各个大公司目前都在研究、试用的技术。截至今日，有这种思想的架构师就已经是很不错了，能够拿到较高薪资，更别提那些已经实践过的，甚至实现了底层系统的那些，所以，你懂得...... 这种模式的一般设计见下图：
优点：弹性、随需计算，充分优化企业计算资源。 缺点：应用要从架构层做到可横向扩展化改造、依赖的底层配套比较多，对技术水平、实力、应用规模要求较高。
多机房模式
优点：高可用、高性能、异地多活。 缺点：数据同步、数据一致性、请求路由。
作者：风平浪静如马
来源：juejin.cn/post/6844904007438172167
全栈架构社区交流群
「全栈架构社区」建立了读者架构师交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。
评论