八种架构设计模式优缺点

1、软件架构

2、架构设计模式

2.1、单库单应用模式

2.2、内容分发模式

2.3、查询分离模式

2.4 微服务模式

2.5 多级缓存模式

1、软件架构

软件架构是指对软件系统整个结构和组成部分之间的关系进行抽象和定义的过程，旨在解决系统设计和实现过程中的复杂性问题，确保系统具有良好的可维护性、可扩展性、可靠性和安全性。它定义了系统的整体蓝图，指导开发团队在系统构建的各个阶段进行决策和实施。

2、架构设计模式

在进行软件架构设计时，通常考虑如下八种设计模式：

2.1、单库单应用模式

这是最简单的一种设计模式，其一般设计如下图所示。

这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是经过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。
缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。

2.2、内容分发模式

基本上所有的大型网站都有或多或少的采用这一种设计模式，常见的应用场景使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。其一般设计如下图所示。

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

上传的时候，用户选择本地机器上的一个图片进行上传
程序会把这个图片上传到云存储OSS上，并返回该图片的一个URL
程序把这个URL字符串存储在业务数据库中，上传完成。
查看的时候，程序从业务数据库得到该图片的URL
程序通过DNS查询这个URL的图片服务器
智能DNS会解析这个URL，得到与用户最近的服务器(或集群)的地址A
然后把服务器A上的图片返回给程序
程序显示该图片，查看完成。

由上可知，这个模式的关键是智能DNS，它能够解析出离用户最近的服务器。运行原理大致是：根据请求者的IP得到请求地点B，然后通过计算或者配置得到与B最近或通讯时间最短的服务器C，然后把C的IP地址返回给请求者。这种模式的优缺点如下：

优点：资源下载快、无需过多的开发与配置，同时也减轻了后端服务器对资源的存储压力，减少带宽的使用。
缺点：目前来说OSS，CDN的价格还是稍微有些贵，只适用于中小规模的应用，另外由于网络传输的延迟、CDN的同步策略等，会有一些一致性、更新慢方面的问题。

2.3、查询分离模式

这种模式主要解决单机数据库压力过大，从而导致业务缓慢甚至超时，查询响应时间变长的问题，也包括需要大量数据库服务器计算资源的查询请求。这个可以说是单库单应用模式的升级版本，也是技术架构迭代演进过程中的必经之路。其一般设计如下图所示。

优点：减少数据库的压力，理论上提供无限高的读性能，间接提高业务(写)的性能，专用的查询、索引、全文(分词)解决方案。
缺点：数据延迟，数据一致性的保证。

2.4 微服务模式

微服务模式是将应用程序划分为一组小型、独立的服务，每个服务运行在自己的进程中，通过轻量级的通信机制进行相互写作。每个微服务负责一个特定的业务领域，并且可以独立的进行开发、部署和扩展。

以实际场景为例，随着业务与人员的增加，我司遇到了如下的问题：

单机数据库写请求量大量增加，导致数据库压力变大
数据库一旦挂了，那么整个业务都挂了
业务代码越来越多，都在一个GIT里，越来越难以维护
代码腐化严重、臭味越来越浓
上线越来越频繁，经常是一个小功能的修改，就要整个大项目要重新编译
部门越来越多，该哪个部门改动大项目中的哪个东西，撕逼的厉害
其他一些外围系统直接连接数据库，导致一旦数据库结构发生变化，所有的相关系统都要通知，甚至对修改不敏感的系统也要通知
每个应用服务器需要开通所有的权限、网络、FTP、各种各样的，因为每个服务器部署的应用都是一样的
作为架构师，我已经失去了对这个系统的把控......

为了解决上述问题，我司使用了微服务模式，其一般设计如下图所示。

如上图所示，我把业务分块，做了垂直切分，切成一个个独立的系统，每个系统各自衍化，有自己的库、缓存、ES等辅助系统，系统之间的实时交互通过RPC，异步交互通过MQ，通过这种组合，共同完成整个系统功能。那么，这么做是否真的解决上述问题了呢？不玩虚的，一个个来说。对于问题一，由于拆分成了多个子系统，系统的压力被分散了，而各个子系统都有自己的数据库实例，所以数据库的压力变小。
对于问题二，一个子系统A的数据库挂了，只是影响到系统A和使用系统A的那些功能，不会所有的功能不可用，从而解决一个数据库挂了，导致所有功能不可用的问题。
问题三、四，也因为拆分得到了解决，各个子系统有自己独立的GIT代码库，不会相互影响。通用的模块可通过库、服务、平台的形式解决。
问题五，子系统A发生改变，需要上线，那么我只需要编译A，然后上线就可以了，不需要其他系统做同样的事情。
问题六，顺应了康威定律，我部门该干什么事、输出什么，也通过服务的形式暴露出来，我部只管把我部的职责、软件功能做好就可以。
问题七，所有需要我部数据的需求，都通过接口的形式发布出去，客户通过接口获取数据，从而屏蔽了底层数据库结构，甚至数据来源，我部只需保证我部的接口契约没有发生变化即可，新的需求增加新的接口，不会影响老的接口。
问题八，不同的子系统需要不同的权限，这个问题也优雅的解决了。
问题九，暂时控制住了复杂性，我只需控制好大的方面，定义好系统边界、接口、大的流程，然后再分而治之、逐个击破、合纵连横。
目前来说，所有问题得到解决！bingo! 但是，还有许多其他的副作用会随之产生，如RPC、MQ的超高稳定性、超高性能，网络延迟，数据一致性等问题，这里就不展开来讲了，太多了，一本书都讲不完。
另外，对于这个模式来说，最难把握的是度，切记不要切分过细，我见过一个功能一个子系统，上百个方法分成上百个子系统的，真的是太过度了。实践中，一个较为可行的方法是：能不分就不分，除非有非常必要的理由！。
优点：相对高性能，可扩展性强，高可用，适合于中等以上规模公司架构。
缺点：复杂、度不好把握。指不仅需要一个能在高层把控大方向、大流程、总体技术的人，还需要能够针对各个子系统有针对性的开发。把握不好度或者滥用的话，这个模式适得其反！

2.5 多级缓存模式

这个模式可以说是应对超高查询压力的一种普遍采用的策略，基本的思想就是在所有链路的地方，能加缓存就加缓存，如下图所示：

如上图所示，一般在三个地方加入缓存，一个是客户端处，一个是API网关处，一个是具体的后端业务处，下面分别介绍。
客户端处缓存：这个地方加缓存可以说是效果最好的---无延迟。因为不用经过长长的网络链条去后端业务处获取数据，从而导致加载时间过长，客户流失等损失。虽然有CDN的支持，但是从客户端到CDN还是有网络延迟的，虽然不大。具体的技术依据不同的客户端而定，对于WEB来讲，有浏览器本地缓存、Cookie、Storage、缓存策略等技术；对于APP来讲，有本地数据库、本地文件、本地内存、进程内缓存支持。以上提到的各种技术有兴趣的同学可以继续展开来学习。如果客户端缓存没有命中，那么就会去后端业务拿数据，一般来讲，都会有个API网关，在这里加缓存也是非常有必要的。
API网关处缓存：这个地方加缓存的好处是不用把请求发送到后方，直接在这里就处理了，然后返回给请求者。常见的技术，如http请求，API网关用的基本都是nginx，可以使用nginx本身的缓存模块，也可以使用Lua+Redis技术定制化。其他的也都大同小异。
后端业务处：这个我想就不用多说了，大家应该差不多都知道，什么Redis,Memcache,Jvm内等等。
实践中，要结合具体的实际情况，综合利用各级缓存技术，使得各种请求最大程度的在到达后端业务之前就被解决掉，从而减少后端服务压力、减少占用带宽、增强用户体验。至于是否只有这三个地方加缓存，我觉得要活学活用，**心法比剑法重要！**总结一下这个模式的优缺点：
优点：抗住大量读请求，减少后端压力。
缺点：数据一致性问题较突出，容易发生雪崩，即：如果客户端缓存失效、API网关缓存失效，那么所有的大量请求瞬间压向后端业务系统，后果可想而知。

2.6分库分表模式

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

如上图所示红色部分，把一张表分到了几个不同的库中，从而分担压力。

优点：减少数据库单表的压力。

缺点：事务保证困难、业务逻辑需要做大量改造。

2.7 弹性伸缩模式

这种模式主要解决突发流量的到来，导致无法横向扩展或者横向扩展太慢，进而影响业务，全站崩溃的问题。这个模式是一种相对来说比较高级的技术，也是各个大公司目前都在研究、试用的技术。截至今日，有这种思想的架构师就已经是很不错了，能够拿到较高薪资，更别提那些已经实践过的，甚至实现了底层系统的那些，所以，你懂得...... 这种模式的一般设计见下图：