几种架构设计模式导论(上)
1.架构的概念是什么
这真是个不太好回答的问题，100个人回答得有101个答案，另外的那一个一定是大家妥协商量出来的结果。呵呵~~，我理解，架构就是骨骼，如下面的图所示：
人类包括动物的身体主要是由由骨骼来支撑的，然后是在其上的肌肉、神经、皮肤等。架构对于软件的重要性和意义不亚于骨架对人类身体的意义。
2. 设计模式的概念是什么
每当有同行来我司面试，这个问题我都会问，不下于数十次，回答五花八门、千奇百怪。不可谓不是群魔乱舞啊，呵呵~~~。但是，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况、前提下使用特定的设计、组合设计，这样可以大大节省我们的设计时间、简化我们的设计思路、提高工作效率。
时间如梭，作为一个老码农，已奉献10年有余，经历的系统架构设计不少，在这里来，我会把工作中使用到的一些架构方面的设计模式分享给大家，希望大家少走弯路，早日走上人生巅峰。总体而言，共有八种，分别是：
- 单库单应用模式：最简单的，最常见的，可能大家都见过，都用过
- 内容分发模式：目前用的比较多，大厂都在用
- 查询分离模式：应对于大并发的查询、业务处理
- 微服务模式：适用于非常复杂的业务的拆解
- 多级缓存模式：可以把各种缓存玩的非常好
- 分库分表模式：解决单机数据库、表瓶颈
- 弹性伸缩模式：解决波峰、波谷业务流量不均匀的方法之一
- 多机房模式：解决高可用、高性能的一种方法
3. 单库单应用模式
这是最简单的一种模式，可能我们大部分的本科毕业设计、一些课堂设计、小的应用，基本上都是这种模式，这种模式的一般设计见下图：
如上图，这种模式正常情况下一般只有一个数据库，一个业务层，一个管理系统，所有的业务都是用过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。虽然简单，但是也并不是一无是处。
- 优点：结构简单、开发快、实现简单，可用于产品的第一版或有原型验证需求、用户少的设计。
- 缺点：性能差、低可用、扩展性差，不适用于大规模部署、应用、流量等生产环境。
4. 内容分发模式
基本上所有的大型的网站、大厂都有或多或少的采用这一种模式，比较常见的应用场景是用CDN技术把网页、图片、CSS、JS、LIB等这些静态资源放到离用户最近的服务器。这种模式的一般设计见下图：
如上图，这种模式较单库单应用模式多了CDN、云存储OSS(七牛、又拍、S3等相似)。一个典型的应用流程(以用户上传、查看图片需求为例)如下：
- 上传的时候，用户A选择本地机器上的一张图片P上传
- 程序会把这个图片P上传到云存储OSS上面，并将该图片的URL返回
- 程序把这个URL字符串存储在数据库中，上传完成。
- 查看的时候，程序从数据库得到该图片的URL
- 程序通过DNS查询这个URL的图片服务器地址
- 智能DNS解析这个URL，得到与用户最近的服务器(或集群)的地址B
- 接下来把服务器B上的图片返回给程序
- 程序显示图片，查看完成。
由上可知，这个模式的关键是智能DNS，它能够解析出离用户最近的那个服务器。运行原理大致为：根据请求者的IP得到请求地点B，然后通过计算或者配置得到与B最近或通讯时间最短的服务器C，然后把C的IP地址返回给请求者。这种模式的优缺点如下：
- 优点：资源下载非常快、无需过多的开发与配置，同时也减轻了后端服务器对资源的存储压力，减少带宽的使用。
- 缺点：目前来说OSS，CDN的售价还是稍微有些贵(虽然已经降价好几次了)，只适用于中小规模的应用，另外，还有一些坏邻居(你懂的)。由于网络传输的延迟、CDN的同步策略等，会有一些一致性、更新速度慢方面的问题。
本次分享的上篇到此结束，接下来中篇将介绍以下三种模式：查询分离模式、微服务模式、多级缓存模式，敬请期待！
