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

八种架构设计模式及其优缺点概述(上)

1. 什么是架构

我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。哈哈，我理解，架构就是骨架，如下图所示：

人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。

2. 什么是设计模式

这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。

作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。总体而言，共有八种，分别是：

1. 单库单应用模式：最简单的，可能大家都见过

2. 内容分发模式：目前用的比较多

3. 查询分离模式：对于大并发的查询、业务

4. 微服务模式：适用于复杂的业务模式的拆解

5. 多级缓存模式：可以把缓存玩的很好

6. 分库分表模式：解决单机数据库瓶颈

7. 弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一

8. 多机房模式：解决高可用、高性能的一种方法

3. 单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：

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

优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。

缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。

4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是使用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的同步策略等，会有一些一致性、更新慢方面的问题

八种架构设计模式及其优缺点概述(中)

2017-03-31码农原创码农原创

码农原创文章，适合程序员、工程师、架构师等一切与软件开发相关的工作者阅读在上篇文章中，介绍了八种架构设计模式中的两种，既：单库单应用模式、内容分发模式，没有读过的同学请手动微信关注“码农原创”公众号，在历史消息中寻找。接下来继续介绍三种架构模式，分别是：查询分离模式、微服务模式、多级缓存模式。

1. 查询分离模式

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

这种模式的一般设计见下图：

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

场景一：全文关键词检索

我想这个需求，绝大多数应用都会有，如果使用传统的数据库技术，大部分可能都会使用like这种SQL语句，高级一点可能是先分词，然后通过分词index相关的记录。SQL语句的性能问题与全表扫描机制导致了非常严重的性能问题，现在基本上很少见到。

这里的ES是ElasticSearch的缩写，是一种查询引擎，类似的还有Solr 等，都差不多的技术，ES较Solr配置简单、使用方便，所以这里选用了它。另外，ES支持横向扩展，理论上没有性能的瓶颈。同时，还支持各种插件、自定义分词器等，可扩展性较强。在这里，使用ES不仅可以替代数据库完成全文检索功能，还可以实现诸如分页、排序、分组、分面等功能。具体的，请同学们自行学习之。那怎么使用呢？一个一般的流程是这样的：

1.服务端把一条业务数据落库

2.服务端异步把该条数据发送到ES

3.ES把该条记录按照规则、配置放入自己的索引库

4.客户端查询的时候，由服务端把这个请求发送到ES，得到数据后，根据

需求拼装、组合数据，返回给客户端

实际中怎么用，还请同学们根据实际情况做组合、取舍。

场景二：大量的普通查询

这个场景是指我们的业务中的大部分辅助性的查询，如：取钱的时候先查询一下余额，根据用户的ID查询用户的记录，取得该用户最新的一条取钱记录等。我们肯定是要天天要用的，而且用的还非常多。同时呢，我们的写入请求也是非常多的，导致大量的写入、查询操作压向同一数据库，然后，数据库挂了，系统挂了，领导生气了，被开除了，还不起房贷了，露宿街头了，老婆跟别人跑了，......