细谈八种架构设计模式及其优缺点概述（架构分析和设计）

我想如果有10个人这个问题就会有11个不同的答案。因为对方是大家妥协的结果。哈哈，原来架构是一个骨架，如下图所示。

人体主要由骨骼支撑，其次是肌肉、神经和皮肤。架构之于软件就像骨骼之于人体。

二、. 什么是设计模式

我曾多次向受访者询问这个问题，得到的答案却大相径庭。在我看来，模式就是经验，设计模式就是设计经验。这些经验将使您能够在特定情况下使用特定的设计和组合。设计，可以显着节省设计时间，提高工作效率。

作为一个工作了10多年的老程序员，我经历过很多系统架构设计。接下来我会分享一些我在工作中使用过的架构设计模式，避免走弯路。总体来说，有八种类型：

单库单应用模式：最简单的可能大家都见过内容分发模式：现在用的比较多查询隔离模式：大规模并发查询，业务微服务模式：适合复杂业务模型的多级拆解缓存模式：Sub – 数据库和表模式：解决单机数据库瓶颈。 弹性伸缩模式：解决业务流量不均的一种方式。高可用性和高性能问题。

三、单库单应用模式

这是最简单的设计模式，是本科生毕业项目和一些小型应用程序的基础。

如上图所示，这种模式一般只有一个数据库、一个业务应用层和一个后端管理系统，所有的业务都是通过业务层完成的，所有的数据都会存储在一个数据库中。数据库同步。虽然简单，但也不是没有好处。

优点：结构简单，开发速度快，易于实现。可用于产品的第一个版本或需要原型验证且用户很少的其他设计。缺点：性能差，本质上没有高可用性，可扩展性差，不适合大型部署、应用程序或其他生产环境。

四、内容分发模式

基本上所有大型网站都在某种程度上采用了这种设计模式。一个常见的应用场景是利用CDN技术将网页、图片、CSS、JS等静态资源分发到距离用户最近的服务器上。该模式的总体设计如下所示。

如上图所示，该模型比单数据库单应用模型多了1个CDN和1个云存储OSS（如七牛、优拍等）。一般申请流程（包括用户上传和展示照片的要求）如下：

上传时，用户在本机选择要上传的图片，程序将图片上传到云存储OSS，并将其URL字符串保存到业务数据库中。它完成了。显示时，程序从业务数据库中检索图片URL，通过DNS向图片服务器查询该URL，并解析该URL，获取距离用户最近的服务器（或集群）的地址A。并将图像返回给服务器A。在程序中显示图像就完成了显示。

正如你在上面看到的，这个模型的关键是智能DNS，它可以解析到距离用户最近的服务器。工作原理大致如下。根据请求者的IP获取请求位置B，计算或设置距离B最近或通话时间最短的服务器C，并将C的IP地址返回给请求者。该模型的优点和缺点是：

服务器以同步、异步或半同步的方式将业务数据放入数据库并复制到从库。服务器从数据库读取数据时，直接从数据库中读取对应的数据。

这个比较简单，一些聪明、有思想、有上进心的同学发现了诸如上面提出的场景之类的问题（例如，当数据还没有到达从库时）。到达后就变得不可读。

每个公司都有不同的思考和解决这个问题的方式。一个常见的解决方案是无法读取主库。当然，这是有前提条件的，但具体解决方案我这里就不赘述了。

此外，还要求学生自行学习数据库复制模式。这里有太多的功能无法介绍。该模型的优点和缺点总结如下。

好处：减少数据库的负载，理论上提供无限高的读性能，间接提升业务（写）性能，提供专门的查询、索引、全文（分词）解决方案来做。缺点：数据延迟，数据一致性保证。

五、查询分离模式

上面的模式看起来不错。它还解决了性能问题。不再露宿街头。我的妻子仍然是我的（笑）。但

软件系统固有的复杂性意味着除了性能之外，还有很多问题需要解决，包括高可用性和健壮性。而且，各个部门之间的矛盾和矛盾，进一步加剧了我们程序员的困难。 所以

继续.

微服务模式可以说是现在的热门话题，国内外各个公司都在倡导和实施这种模式，但是很多人不明白为什么要这样做或者不应该做什么。知道。这样做的好处就是坏处。这里我结合我个人的实践来谈谈我对这个模型的看法。如果你不喜欢它，就不要批评它。随着业务和人员的增长，出现了以下问题：

单机数据库写请求数量大幅增加，数据库负载增大，数据库宕机，整个业务宕机，越来越多的业务代码驻留在单个GIT内。代码变得更难维护，并且上线的Neng 越多，就越需要重新编译整个大型项目。在一个大项目中，哪个部门需要改变什么？其他外围系统直接连接到数据库，这意味着所有相关系统都需要得到通知，即使是那些对变化不敏感的系统。由于每台服务器上部署的应用都是一样的，所以通知每台应用服务器所有的权限、网络、FTP等都需要打开。作为一名架构师，我不再能够控制这个系统。

为了解决上述问题，我们采用微服务模型。该模型的总体设计如下图所示。

如上图所示，我们将业务进行了垂直细分，分离成独立的系统。每个系统都是独立演化的，都有自己的库、缓存、ES等支撑系统。这样结合RPC、通过MQ的异步交互，共同完成了整个系统的功能。

那么，这真的能解决上述问题吗？别废话了，我们一一来说吧。关于问题1，拆分为多个子系统，分散了系统的负载，并且每个子系统都有自己的数据库实例，减少了数据库的负载。

关于问题2，如果子系统A中的数据库出现故障，则只有系统A和使用系统A的功能受到影响。并非所有功能都将不可用。这解决了数据库宕机和所有功能不可用的问题。

问题3和问题4通过拆分解决。每个子系统都有自己独立的GIT代码库，互相不影响。公共模块可以以库、服务、平台的形式来解析。

问题5：子系统A已修改，需要上线。这种情况下，你只需要编译A然后上线即可。其他系统不需要做同样的事情。

问题六：根据康威定律，我们部门应该做什么、输出什么，也会以服务的形式公开。我们部门只需妥善完成其职责和软件功能即可。

问题七：我部门数据的所有需求都会以接口的形式发布。由于客户通过接口获取数据，所以我们部门必须保护底层数据库结构甚至数据源。但是，根据新需求添加新接口不会影响旧接口。

问题8：不同的子系统需要不同的权限，不过这个问题也被优雅的解决了。

问题9：我能够暂时控制复杂性。你要做的就是把控大的方面，定义好系统的边界、接口、大流程，然后分而治之，一一攻克，纵横结合。

至此，所有问题都解决了！答对了！

但还有很多其他的副作用，比如RPC和MQ的超高稳定性和超高性能、网络延迟、数据一致性等。我这里就不详细说了。这本书里有无穷无尽的内容。

此外，该模型最难理解的一点是，它不会过多地分解为一个函数和一个子系统，也不会将数百种方法分解为数百个子系统。事实上，一个更可行的选择是尽可能避免分手，除非有充分的理由。

优点：性能比较高，可扩展性强，可用性高，适合中型和大型企业架构。缺点：复杂，难以理解。这意味着你不仅需要能够高水平掌控总体方向、大规模流程、技术的人，还需要能够对各个子系统进行针对性开发的人。如果管理不当或滥用，这种模式可能会适得其反。

六、微服务模式

这种模式可以说是应对非常高的查询负载时常用的策略。基本思想是为所有链接添加尽可能多的缓存，如下图所示。

如上图所示，缓存通常添加在三个位置：客户端、API 网关以及特定后端位置，如下所述。

在客户端上缓存：在此处添加缓存可以消除延迟并提供最佳结果。数据不必通过长网络链到达后端办公室来检索数据，从而导致加载时间长和客户流失等损失。有CDN 支持，但从客户端到CDN 仍然存在网络延迟，尽管并不显着。具体技术因客户而异。对于Web，这包括浏览器本地缓存、cookie、存储和缓存策略；对于APP，这包括对本地数据库、本地文件、本地内存和进程内缓存的支持。对上面列出的各种技术感兴趣的学生可以继续学习。如果客户端缓存未命中，您最终会将数据检索到后端业务。一般来说，因为API网关的存在，这里添加缓存是非常有必要的。

现在我们知道了基本理论，我们该如何进行呢？现在让我们通过一个例子来解释一下。

这个要求很简单。用户表（users）数据量为1亿。我在查询、插入和存储方面遇到问题。我现在应该怎么做。

首先，分析问题。这显然是大数据量导致的问题。

然后您可以将您的设计方案分为10个库，并将每个库中的数据量减少到1KW。一张表1KW的数据量还是有点大，不适合未来的体量增长。因此，每个库分为100张表，每个单表有10W的数据，在查询、索引更新、单表文件大小、打开速度等方面都有几个好处。接下来，致电您的IT 部门并请求10 台物理机来扩展您的数据库。

最后，实现逻辑，这是你能找到最多知识的地方。首先，写入数据时，需要知道写入哪个子库、子表，读也是如此，需要将请求分发到不同的数据库进行转换。一般来说，有一个概念叫做路由规则。

你觉得怎么样，简单吗？哈哈，这也是义务。让我解释一下这个模型的问题。主要是发生交易问题。因为数据库是分表的，事务无法完成，分布式事务太麻烦，所以需要特定的策略来保证这一点。在这种情况下，您可以执行交易。采用的策略包括最终一致性、复制、特殊设计等。接下来是业务代码改造，需要改造一些相关的查询。另外，对于一些groupBy语句的单表orderBy问题，不可能用一两句话清楚地解释如何解决这些副作用。如果有机会我会单独谈谈这些。

该模型的优点和缺点总结如下。

优点：减少单个数据库表的负载。缺点：交易难以保证，需要对业务逻辑进行大量改动。

七、多级缓存模式

这种模式主要解决突然涌入的流量无法横向扩展或者横向扩展太慢，从而影响你的业务或者导致整个网站崩溃的问题。这种模式是比较先进的技术，目前各大公司都在研究和测试。到今天为止，有这种心态的建筑师已经很优秀了，可以赚到更高的薪水。不用说，已经有架构师做到了，并实现了底层系统。

该模式的总体设计如下所示。

如上图所示，还有一个额外的弹性伸缩服务，用于动态增减实例。原理很简单，但是这个模型解决什么问题呢？首先我们来说说它的由来和意义。

每年双11、6月18日，或者一些重大促销活动之前，请做好以下准备，为海量流量的到来做好准备。

提前准备一台至少10倍容量的机器，即使不使用也将其存放在安全的地方。这浪费了大量的资源。

为每台计算机配置、调试和路由流量，以便所有计算机都可以使用该流量。这样浪费了大量的人力物力，而且容易出错。

如果机器没有准备好，你就得加班并重复上述步骤。如果你这样做，你会很容易出错，你会对老板不满意，你将没有时间回家陪伴你的妻子，而她会.（你自己想想）

即使双十一之后，你仍然需要手动缩小尺寸，这是非常困难的。这真的很烦人，因为一年中通常会有多次促销，所以总是这样。

最严重的是，您可能对突然出现的流量激增毫无准备。因此，我们变得懒惰，必须准备更多的机器，结果是这样的：许多机器的CPU 使用率为1%。

我想如果你是我的老板你一定会感到震惊！

哈哈，那我们能做些什么来改变这种现状呢？请继续阅读

为了实现这个目标，所有的计算资源首先被整合到一个资源池的概念中，然后通过一些策略、监视器和服务从资源池中动态地检索资源，以便在其他系统中使用，这样就可以了。

具体实现上比较成熟的两种资源池解决方案是VM和Docker，各自都有自己强大的生态。监控点包括CPU、内存、硬盘、网络IO、服务质量等。在此基础上，通过使用一些保留、扩展和收缩策略，可以轻松实现自动伸缩。那个怎么样？是不是很神奇呢？深层内容我们将在程序员原创公众号文章中详细介绍。

该模型的优点和缺点总结如下。

优势：通过灵活的按需计算，全面优化企业计算资源。缺点：应用必须从架构层横向扩展，依赖很多底层支撑功能，对技术水平、实力和应用规模要求较高。

八、分库分表模式

该模型主要解决不同地域的高性能和高可用问题。

随着应用程序用户不断增长，如果用户群分布在世界各地，并且服务器位于一个地点（例如北京的机房），那么每次出现请求时，美国的用户都会使用该应用程序。这是特别耗时的。光缆必须穿过海底，铺设需要大约1秒（估计），这对用户体验产生非常负面的影响。你会怎么做？采用多机房部署。

该模式的总体设计如下所示。

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

用户请求链接

通过DNS智能解析距离用户最近的B机房。

B 使用机房服务链接A

是不是觉得很简单，没什么？事实上，这里的问题并不像看起来那么简单。让我们一一看看。

首先是数据同步的问题。中国产生的数据必须同步到美国。数据同步包括数据版本、一致性、丢弃更新、删除等问题。

第二个问题是将请求路由到一个位置的多个计算机房。典型的有中国的北京机房和杭州机房，如上图所示。如果北京机房宕机，所有请求都会发送到北京。机房需要通过路由转移到杭州机房。这个问题在其他地方也存在。

因此，多个机房，即不同地点的多种活动的模型并不是那么简单。具体的陷阱我会在另一篇文章中介绍。

该模型的优点和缺点总结如下。

优点：高可用性、高性能、远程位置的多种活动。缺点：数据同步、数据一致性、请求路由。

到目前为止，您已经用大约10,000 字完整地概述了八种架构设计模式及其优缺点。最后我想说的是，没有什么灵丹妙药，所以要灵活，互相鼓励！

# 以上8种架构设计模式及其优缺点的详细说明来自网络，仅供大家参考。相关信息请参见官方公告。