关于后端:几种常见的架构模式

本文曾经收录到 Github 仓库，该仓库蕴含 计算机根底、Java 根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享 等外围知识点，欢送 star~

Github 地址

如果拜访不了 Github，能够拜访 gitee 地址。

gitee 地址

分享一些工作中会用到的一些架构方面的设计模式。总体而言，共有八种，别离是：

1. 单库单利用模式：最简略的，可能大家都见过
2. 内容散发模式：目前用的比拟多
3. 查问拆散模式：对于大并发的查问、业务
4. 微服务模式：实用于简单的业务模式的拆解
5. 多级缓存模式：能够把缓存玩的很好
6. 分库分表模式：解决单机数据库瓶颈
7. 弹性伸缩模式：解决波峰波谷业务流量不平均的办法之一
8. 多机房模式：解决高可用、高性能的一种办法

三、单库单利用模式

这是最简略的一种设计模式，咱们的大部分本科毕业设计、一些小的利用，基本上都是这种模式，这种模式的个别设计见下图：

最全面的 Java 面试网站

如上图所示，这种模式个别只有一个数据库，一个业务应用层，一个后盾管理系统，所有的业务都是用过业务层实现的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。尽管简略，然而 也并不是一无是处。

• 长处：构造简略、开发速度快、实现简略，可用于产品的第一版等有原型验证需要、用户少的设计。
• 毛病：性能差、根本没有高可用、扩展性差，不适用于大规模部署、利用等生产环境。

四、内容散发模式

基本上所有的大型的网站都有或多或少的采纳这一种设计模式，常见的利用场景是应用 CDN 技术把网页、图片、CSS、JS 等这些动态资源散发到离用户最近的服务器。这种模式的个别设计见下图：

如上图所示，这种模式较单库单利用模式多了一个 CDN、一个云存储 OSS(七牛、又拍等雷同)。一个典型的利用流程 (以用户上传、查看图片需要为例) 如下：

1. 上传的时候，用户抉择本地机器上的一个图片进行上传
2. 程序会把这个图片上传到云存储 OSS 上，并返回该图片的一个 URL
3. 程序把这个 URL 字符串存储在业务数据库中，上传实现。
4. 查看的时候，程序从业务数据库失去该图片的 URL
5. 程序通过 DNS 查问这个 URL 的图片服务器
6. 智能 DNS 会解析这个 URL，失去与用户最近的服务器 (或集群) 的地址 A
7. 而后把服务器 A 上的图片返回给程序
8. 程序显示该图片，查看实现。

由上可知，这个模式的要害是智能 DNS，它可能解析出离用户最近的服务器。运行原理大抵是：依据请求者的 IP 失去申请地点 B，而后通过计算或者配置失去与 B 最近或通信工夫最短的服务器 C，而后把 C 的 IP 地址返回给请求者。这种模式的优缺点如下：

• 长处：资源下载快、无需过多的开发与配置，同时也加重了后端服务器对资源的存储压力，缩小带宽的应用。
• 毛病：目前来说 OSS，CDN 的价格还是略微有些贵(尽管曾经提价好几次了)，只实用于中小规模的利用，另外因为网络传输的提早、CDN 的同步策略等，会有一些一致性、更新慢方面的问题。

五、查问拆散模式

这种模式次要解决单机数据库压力过大，从而导致业务迟缓甚至超时，查问响应工夫变长的问题，也包含须要大量数据库服务器计算资源的查问申请。这个能够说是单库单利用模式的降级版本，也是技术架构迭代演进过程中的必经之路。这种模式的个别设计见下图：

如上图所示，这种模式较单库单利用模式与内容散发模式多了几个局部，一个是 业务数据库的主从拆散 ，一个是 引入了 ES，为什么要这样？都解决了哪些痛点，上面具体联合业务需要场景进行叙述。

场景一：全文关键词检索

我想这个需要，绝大多数利用都会有，如果应用传统的数据库技术，大部分可能都会应用 like 这种 SQL 语句，高级一点可能是先分词，而后通过分词 index 相干的记录。SQL 语句的性能问题与全表扫描机制导致了十分重大的性能问题，当初基本上很少见到。这里的 ES 是 ElasticSearch 的缩写，是一种查问引擎，相似的还有 Solr 等，都差不多的技术，ES 较 Solr 配置简略、使用方便，所以这里选用了它。另外，ES 反对横向扩大，实践上没有性能的瓶颈。同时，还反对各种插件、自定义分词器等，可扩展性较强。在这里，应用 ES 不仅能够代替数据库实现全文检索性能，还能够实现诸如分页、排序、分组、分面等性能。具体的，请同学们自行学习之。那怎么应用呢？一个个别的流程是这样的：

1. 服务端把一条业务数据落库
2. 服务端异步把该条数据发送到 ES
3. ES 把该条记录依照规定、配置 放入本人的索引库
4. 客户端查问的时候，由服务端把这个 申请发送到 ES，失去数据后，依据需要拼装、组合数据，返回给客户端

理论中怎么用，还请同学们依据理论状况做组合、取舍。

场景二：大量的一般查问

这个场景是指咱们的业务中的大部分辅助性的查问，如：取钱的时候先查问一下余额，依据用户的 ID 查问用户的记录，获得该用户最新的一条取钱记录等。咱们必定是要天天要用的，而且用的还十分多。同时呢，咱们的写入申请也是十分多的，导致 大量的写入、查问操作压向同一数据库，而后，数据库挂了，零碎挂了，领导怄气了，被开革了，还不起房贷了，露宿街头了，老婆跟他人跑了，……

不敢想，所以要求咱们必须扩散数据库的压力，一个业界较成熟的计划就是数据库的读写拆散，写的时候入主库，读的时候读从库。这样就把压力扩散到不同的数据库了，如果一个读库性能不行，扛不住的话，能够一主多从，横向扩大。堪称是一剂良药啊！那怎么应用呢？一个个别的流程是这样的：

1. 服务端把一条业务数据落库
2. 数据库同步或异步或半同步把该条数据 复制 到从库
3. 服务端读数据的时候间接去 从库读 相应的数据

比较简单吧，一些聪慧的、爱思考的、上进的同学可能发现问题了，也包含下面介绍的场景一，就是提早问题，如：数据还没有到从库，我就马上读，那么是读不到的，会产生问题的。对于这个问题，各家公司解决的思路不一样，办法不尽相同。一个广泛的解决方案是：读不到就读主库，当然这么说也是有前提条件的，但具体的计划这里就不一一开展了，我可能会在接下来的分享中详解各种计划。另外，对于数据库的复制模式，还请同学们自行学习，太多了，这里说不清。该总结一下这种模式的优缺点的了，如下：

• 长处 ：缩小数据库的压力，实践上提供有限高的读性能，间接进步业务(写) 的性能，专用的查问、索引、全文 (分词) 解决方案。
• 毛病：数据提早，数据一致性的保障。

六、微服务模式

下面的模式看似不错，解决了性能问题，我能够不必露宿街头了、老婆还是我的，哈哈。然而

软件系统天生的复杂性决定了，除了性能，还有其余诸如高可用、健壮性等大量问题期待咱们解决，再加上各个部门间的撕逼、扯皮，更让咱们码农雪上加霜，所以

持续吧 ……

微服务模式能够说是最近的热点，花花绿绿、大大小小、国内国外的公司都在宣扬，实际这个模式，可是大部分都没有弄清楚 为什么 要这么做，也并不知道这么做有什么 益处、害处，在这里，我将以我本人的亲自实际说一下我对这个模式的认识，不喜勿喷！随着业务与人员的减少，遇到了如下的问题：

1. 单机数据库写申请量大量减少，导致数据库压力变大
2. 数据库一旦挂了，那么整个业务都挂了
3. 业务代码越来越多，都在一个 GIT 里，越来越难以保护
4. 代码腐化重大、臭味越来越浓
5. 上线越来越频繁，常常是一个小性能的批改，就要整个大我的项目要从新编译
6. 部门越来越多，该哪个部门改变大我的项目中的哪个货色，撕逼的厉害
7. 其余一些外围零碎间接连贯数据库，导致一旦数据库构造发生变化，所有的相干零碎都要告诉，甚至对批改不敏感的零碎也要告诉
8. 每个应用服务器须要开明所有的权限、网络、FTP、各种各样的，因为每个服务器部署的利用都是一样的
9. 作为架构师，我曾经失去了对这个零碎的把控 ……

为了解决上述问题，我司应用了微服务模式，这种模式的个别设计见下图：

如上图所示，我把 业务分块，做了垂直切分，切成一个个独立的零碎，每个零碎各自衍化，有本人的库、缓存、ES 等辅助零碎，零碎之间的实时交互通过 RPC，异步交互通过 MQ，通过这种组合，共同完成整个零碎性能。 那么，这么做是否真的解决上述问题了呢？不玩虚的，一个个来说。对于问题一，因为拆分成了多个子系统，零碎的压力被扩散了，而各个子系统都有本人的数据库实例，所以数据库的压力变小。

对于问题二，一个子系统 A 的数据库挂了，只是影响到零碎 A 和应用零碎 A 的那些性能，不会所有的性能不可用，从而解决一个数据库挂了，导致所有性能不可用的问题。

问题三、四，也因为拆分失去了解决，各个子系统有本人独立的 GIT 代码库，不会相互影响。通用的模块可通过库、服务、平台的模式解决。

问题五，子系统 A 产生扭转，须要上线，那么我只须要编译 A，而后上线就能够了，不须要其余零碎做同样的事件。

问题六，适应了 康威定律，我部门该干什么事、输入什么，也通过服务的模式裸露进去，我部只管把我部的职责、软件性能做好就能够。

问题七，所有须要我部数据的需要，都通过接口的模式公布进来，客户通过接口获取数据，从而屏蔽了底层数据库构造，甚至数据起源，我部只需保障我部的接口契约没有发生变化即可，新的需要减少新的接口，不会影响老的接口。

问题八，不同的子系统须要不同的权限，这个问题也优雅的解决了。

问题九，临时管制住了复杂性，我只需管制好大的方面，定义好零碎边界、接口、大的流程，而后再分而治之、一一击破、合纵连横。

目前来说，所有问题失去解决！bingo! 然而，还有许多其余的副作用会随之产生，如 RPC、MQ 的超高稳定性、超高性能，网络提早，数据一致性等问题，这里就不开展来讲了，太多了，一本书都讲不完。

另外，对于这个模式来说，最难把握的是 度，切记 不要切分过细 ，我见过一个性能一个子系统，上百个办法分成上百个子系统的，真的是太适度了。实际中，一个较为可行的办法是： 能不分就不分，除非有十分必要的理由！。

• 长处：绝对高性能，可扩展性强，高可用，适宜于中等以上规模公司架构。
• 毛病：简单、度不好把握。指不仅须要一个能在高层把控大方向、大流程、总体技术的人，还须要可能针对各个子系统有针对性的开发。把握不好度或者滥用的话，这个模式事与愿违！

七、多级缓存模式

这个模式能够说是应答超高查问压力的一种广泛采纳的策略，根本的思维就是在所有链路的中央，能加缓存就加缓存，如下图所示：

最全面的 Java 面试网站

如上图所示，个别在三个中央退出缓存，一个是客户端处，一个是 API 网关处，一个是具体的后端业务处，上面别离介绍。

客户端处缓存：这个中央加缓存能够说是成果最好的 — 无提早。因为不必通过长长的网络链条去后端业务处获取数据，从而导致加载工夫过长，客户散失等损失。尽管有 CDN 的反对，然而从客户端到 CDN 还是有网络提早的，尽管不大。具体的技术根据不同的客户端而定，对于 WEB 来讲，有浏览器本地缓存、Cookie、Storage、缓存策略等技术；对于 APP 来讲，有本地数据库、本地文件、本地内存、过程内缓存反对。以上提到的各种技术有趣味的同学能够持续开展来学习。如果客户端缓存没有命中，那么就会去后端业务拿数据，一般来讲，都会有个 API 网关，在这里加缓存也是十分有必要的。

API 网关处缓存：这个中央加缓存的益处是不必把申请发送到前方，间接在这里就解决了，而后返回给请求者。常见的技术，如 http 申请，API 网关用的根本都是 nginx，能够应用 nginx 自身的缓存模块，也能够应用 Lua+Redis 技术定制化。其余的也都大同小异。

后端业务处：这个我想就不必多说了，大家应该差不多都晓得，什么 Redis,Memcache,Jvm 内等等，不熬述了。

实际中，要联合具体的理论状况，综合利用各级缓存技术，使得各种申请最大水平的在达到后端业务之前就被解决掉，从而缩小后端服务压力、缩小占用带宽、加强用户体验。至于是否只有这三个中央加缓存，我感觉要活学活用，心法比剑法重要！总结一下这个模式的优缺点：

• 长处：抗住大量读申请，缩小后端压力。
• 毛病：数据一致性问题较突出，容易产生雪崩，即：如果客户端缓存生效、API 网关缓存生效，那么所有的大量申请霎时压向后端业务零碎，结果可想而知。

八、分库分表模式

这种模式次要解决单表写入、读取、存储压力过大，从而导致业务迟缓甚至超时，交易失败，容量不够的问题。个别有程度切分和垂直切分两种，这里次要介绍程度切分。这个模式也是技术架构迭代演进过程中的必经之路。这种模式的个别设计见下图：

如上图所示红色局部，把一张表分到了几个不同的库中，从而分担压力。是不是很抽象？哈哈，那咱们接下来就具体的解说一下。首先廓清几个概念，如下：主机 ：硬件，指一台物理机，或者虚拟机，有本人的 CPU，内存，硬盘等。 实例 ：数据库实例，如一个 MySQL 服务过程。一个主机能够有多个实例，不同的实例有不同的过程，监听不同的端口。 库：指表的汇合，如学校库，可能蕴含老师表、学生表、食堂表等等，这些表在一个库中。一个实例中能够有多个库。库与库之间用库名来辨别。表：库中的表，不用多说，不懂的就不必往下看了，不解释。

那么怎么把单表扩散呢？到底怎么个散发呢？散发到哪里呢？以下是几个工作中的实际，分享一下：主机：这是最次要的也是最重要的点，实质上分库分表是因为计算与存储资源不够导致的，而这种资源次要是由物理机，主机提供的，所以在这里分是最根本的，毕竟没有可用的计算资源，怎么分成果都不是太好的。实例：实例管制着连接数，同时受 OS 限度，CPU、内存、硬盘、网络 IO 也会受间接影响。会呈现热实例的景象，即：有些实例特地忙，有些实例十分的闲暇。一个典型的景象是：因为单表反馈慢，导致连接池被打满，所有其余的业务都受影响了。这时候，把表分到不同的实例是有一些成果的。库：个别是因为单库中最大单表数量的限度，才采取分库。表：单表压力过大，索引量大，容量大，单表的锁。据以上，把单表程度切分成不同的表。

大型利用中，都是一台主机上只有一个实例，一个实例中只有一个库，库 == 实例 == 主机，所以才有了分库分表 这个简称。

既然晓得了根本实践，那么具体是怎么做的呢？逻辑是怎么跑的呢？接下来以一个例子来解说一下。这个需要很简略，用户表(user)，单表数据量 1 亿，查问、插入、存储都呈现了问题，怎么办呢？

首先，剖析问题，这个显著是因为数据量太大了而导致的问题。其次，设计方案，能够分为 10 个库，这样每个库的数据量就降到了 1KW，单表 1KW 数据量还是有些大，而且不利于当前量的增长，所以每个库再分 100 个表，这个每个单表数据量就为 10W 了，对于查问、索引更新、单表文件大小、关上速度，都有一些好处。接下来，给 IT 部门打电话，要 10 台物理机，扩大数据库 …… 最初，逻辑实现，这里应该是最有学识的中央。首先是写入数据，须要晓得写到哪个分库分表中，读也是一样的，所以，须要有个申请 路由层，负责把申请散发、转换到不同的库表中，个别有路由规定的概念。

怎么样，简略吧？哈哈，too 那任务。说说这个模式的问题，次要是带来了事务上的问题，因为分库分表，事务实现不了，而 分布式事务 又太轻便，所以这里须要有肯定的策略，保障在这种状况下事务可能实现。采取的策略如：最终一致性、复制、非凡设计等。再有就是业务代码的革新，一些关联查问要革新，一些单表 orderBy 的问题须要非凡解决，也包含 groupBy 语句，如何解决这些副作用不是一句两句能说分明的，当前有工夫，我独自讲讲这些。

该总结一下这种模式的优缺点的了，如下：

• 长处：缩小数据库单表的压力。
• 毛病：事务保障艰难、业务逻辑须要做大量革新。

九、弹性伸缩模式

这种模式次要解决突发流量的到来，导致无奈横向扩大或者横向扩大太慢，进而影响业务，全站解体的问题。这个模式是一种相对来说比拟高级的技术，也是各个大公司目前都在钻研、试用的技术。截至今日，有这种思维的架构师就曾经是很不错了，可能拿到较高薪资，更别提那些曾经实际过的，甚至实现了底层零碎的那些，所以，你懂得 …… 这种模式的个别设计见下图：

如上图所示，多了一个弹性伸缩服务，用来动静的减少、缩小实例。原理上非常简单，然而这个模式到底解决什么问题呢？先说说由来和意义。

每年的双 11、六一八或者一些大促到来之前，咱们都会为大流量的到来做以下几个方面的工作: 提前准备 10 倍甚至更多的机器，即应用不上也要放在那里备着，以防万一。这样节约了大量的资源。每台机器配置、调试、引流，以便让所有的机器都可用。这样节约了大量的人力、物力，更容易出错。如果机器筹备不充沛，那么还要加班加点的反复下面的工作。这样做特地容易出错，引来领导的不满，没工夫回家陪老婆，而后你的老婆就 ……(本人想)

在双十一之后，咱们还要人工做缩容，十分的辛苦。个别一年中会有屡次促销，那么咱们就会始终这样，切实是烦！

最重大的，忽然间的大流量暴发，会让咱们触不迭防，中午起来扩容是在失常不过的事件，为此，咱们偷懒起来，要更多的机器备着，也就呈现了大量的 cpu 利用率为 1% 的机器。

我置信，如果你是老板肯定很 震惊 吧！！！哈哈，那么如何扭转这种状况呢？请接着看

为此，首先把所有的计算资源整合成资源池的概念，而后通过一些策略、监控、服务，动静的从资源池中获取资源，用完后在放回到池子中，供其余零碎应用。具体实现上比拟成熟的两种资源池计划是 VM、docker，每个都有着本人弱小的生态。监控的点有 CPU、内存、硬盘、网络 IO、服务质量等，依据这些，在配合一些预留、扩张、膨胀策略，就能够简略的实现主动伸缩。怎么样？是不是很神奇？深刻的内容咱们会在的码农原创的公众号文章中具体介绍。

该总结一下这种模式的优缺点的了，如下：

• 长处：弹性、随需计算，充沛优化企业计算资源。
• 毛病：利用要从架构层做到可横向扩大化革新、依赖的底层配套比拟多，对技术水平、实力、利用规模要求较高。

十、多机房模式

这种模式次要解决 不同地区高性能、高可用 的问题。

随着利用用户一直的减少，用户群体散布在寰球各地，如果把服务器部署在一个中央，一个机房，比方北京，那么美国的用户应用利用的时候就会特地慢，因为每一个申请都须要通过海底光缆走上个那么一秒钟 (预估) 左右，这样对用户体验及其不好。怎么办？应用多机房部署。

这种模式的个别设计见下图：

如上图所示，一个典型的用户申请流程如下：

用户申请一个链接 A 通过 DNS 智能解析到离用户最近的机房 B 应用 B 机房服务链接 A

是不是感觉很简略，没啥？其实这外面的问题没有外表这么简略，上面一一道来。首先是 数据同步 问题，在中国产生的数据要同步到美国，美国的也一样，数据同步就会波及数据版本、一致性、更新抛弃、删除等问题。其次是一地多机房的申请 路由 问题，典型的是如上图，中国的北京机房和杭州机房，如果北京机房挂了，那么要可能通过路由把所有发往北京机房的申请转发到杭州机房。异地也存在这个问题。

所以，多机房模式，也就是异地多活并不是那么的简略，这里只是起了个头，具体的有哪些坑，会在另一篇文章中介绍。

该总结一下这种模式的优缺点的了，如下：

• 长处：高可用、高性能、异地多活。
• 毛病：数据同步、数据一致性、申请路由。

至此，整个对于 八种架构设计模式及其优缺点概述 就介绍完了，大概 1W 字左右。最初，我想说的是没有银弹、灵活运用，共勉！

参考链接：https://juejin.cn/post/6844904007438172167

最初给大家分享一个 Github 仓库，下面有大彬整顿的 300 多本经典的计算机书籍 PDF，包含 C 语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生 等，能够 star 一下，下次找书间接在下面搜寻，仓库继续更新中~

Github 地址