1。什么是建筑？这个问题我觉得十个人可以回答十一个答案，因为另一个是大家妥协的结果。哈哈，我明白建筑是人的骨骼。人体的支撑主要由骨骼承担，其次是骨骼之上的肌肉、神经和皮肤。架构之于软件就像骨骼之于人体一样重要。2.什么是设计模式？我问过面试官不下几十次，答案五花八门。在我看来，模式就是经验，所涉及的模式就是经验。有了这些经验，我们就可以在特定的情况下加以运用。具体设计、组合设计。这样可以大大节省我们的设计时间，提高工作效率。作为一个老coder，manager的系统架构设计也是功不可没。接下来，我将在工作中使用到的一些架构设计模式分享给大家，希望大家少走弯路。大体上有八种，分别是：1.单库单应用模式：最简单，可能大家都见过2.内容分发模式：目前使用较多3.查询分类模式：针对大并发查询，业务。4.微服务模式：适合复杂业务模型的拆解5.多级缓存模式：可以很好的发挥缓存6.分库分表模式：解决单体和数据库瓶颈7.弹性伸缩模式：解决波峰谷业务流量不均的方法之一8、多机房模式：解决高可用和高性能的方法3、单数据库、单应用模式这是最简单的设计模式。我们大部分的本科毕业设计，一些小应用基本上都是这种模式。该模式的总体设计如下图所示：如上图所示，该模式一般只有数据库、业务应用层和后台管理系统。所有的业务都是在业务层完成的，所有的数据也是存储在一个数据库中。更好的是，将有数据库同步。虽然简单，但也不是没有用。优点：结构简单，开发速度快，实现简单，可用于产品首版等原型验证需求。缺点：性能较差，基本没有高可用性，可扩展性差，不适合大规模部署、应用等生产环境。4.内容分发模式基本上所有的大型网站都或多或少地采用了这种设计模式。常见的应用场景是利用CDN技术将网页、图片、CSS、JS等静态资源分发给远程用户。近期服务器的总体设计，这种模式如下图所示：如上图，这种模式相对于单一的数据库和云存储OSS（类似七牛和优拍等）有一个CDN和一个云存储OSS。单一应用模式。一个经典的应用流程（以用户需要上传和查看图片为例：）1.上传时，用户在本机选择一张图片上传2.程序会将图片上传到云存储OSS并返回图片的一个URL3.程序将这个URL字符串存入业务数据库，上传完成4.查看时，程序从业务数据库中获取图片的URL5.程序查询该URL的图片服务器通过DNS6.SmartDNS会解析这个URL，得到离用户最近的服务器（或集群）的地址A7，然后把服务器A上的图片返回给程序8.程序显示图片，视图完成了。从上面可以看出，这种模式的关键是智能DNS。它可以解析离用户最近的服务器。其工作原理大致是：根据请求者的IP获取请求位置B，然后通过计算或配置获取距离B最近或通信时间最短的服务器C，再将C的IP地址返回给请求者。这种模式的优缺点如下：优点：资源下载速度快，不需要过多的开发和配置，同时也减轻了后端服务器资源的存储压力，减少了带宽的使用。缺点：目前OSS和CDN的价格还是有点贵，只适合中小规模的应用。另外，由于网络传输延迟和CDN同步策略，会存在一些一致性和更新慢的问题。5、查询分离模式该模式主要解决单体和数据库压力过大导致业务变慢甚至超时，以及查询影响时间变长的问题。它还包括需要大量数据库服务器计算资源的查询请求。这可以说是一个单一的数据库。应用模式的升级版本也是技术架构迭代演进过程中的必由之路。这种模式的总体设计如下图所示：如上图所示，这种模式比单体数据库多了几个部分，就是应用模式和内容分发模式。一是业务数据库的主从分离，二是ES的引入。你为什么要这样做？？解决了哪些痛点，下面结合业务需求场景进行详细介绍。场景一：全文关键词检索我想大多数应用都会有这个需求。如果使用传统的数据库技术，大部分可能会使用likelike的SQL语句。比较高级的是先分词，再跟分词索引Record相关。SQL语句的性能问题和全表扫描机制造成了非常严重的性能问题，现在基本已经很少见了。ES比Solr配置更简单，使用更方便，所以这里选择它。另外，ES支持横向扩展，理论上不存在性能瓶颈。同时还支持各种插件、自定义分词器等，扩展性强。在这里，使用ES不仅可以代替数据库完成完整的搜索功能，还可以实现分页、排序、分组、分面等功能。具体请自行学习，如何使用？一个大致的流程是这样的：1.服务器将一条业务数据放入数据库中。2.服务端异步向ES3发送数据，ES将记录按照规则和配置放入自己的索引库中4.客户端查询时，服务端将请求发送给ES。拿到数据后，按照要求对数据进行组装、组合，返回给客户端。如何在实践中使用它？同学们根据实际情况进行组合选择场景二：大量普通查询该场景指的是我们业务中的大部分辅助查询，比如：提现时，先查看余额，根据用户ID查询到用户ID记录，获取用户最新的提现记录等，我们每天都要用到，而且用得很多。同时，我们也有大量的写请求，导致大量的写和查询操作被压到同一个数据库上。然后，数据库挂了，系统挂了，领导生气，被开除，还不起房贷。露宿街头，老婆跟人跑了……想都不敢想，一定要分散数据库的压力。业界比较成熟的方案是数据库的读写分离。写的时候存入主库，读的时候在分库读。.这样就把压力分散到了不同的数据库上。如果一个数据库读取性能不好，处理不过来，可以一主多从，可谓一剂良药！那么如何使用呢？一个大致的过程是这样的1.服务器向数据库中放入一条数据。2、数据库以同步或异步或半同步方式将此数据复制到从库。3、服务端读取数据时，直接从数据库中读取相应的数据，比较简单。聪明、有思想、有上进心的同学可能已经发现问题了，包括上面说的第一种场景，就是延迟问题。比如数据还没到从库，我就马上去读，那就读不到了，就发生了。可疑的。对于这个问题，每个公司都有不同的思路和方法来解决这个问题。常见的解决办法是：看不懂就看主库。当然，这也是有前提的，但是具体的解决办法就不在这里了。我可能会在接下来的分享中，一一详细讲解各种解决方案。另外，关于数据库复制模式，也请同学们自学。太多了，这里就不一一解释了。是时候总结一下这种模式的优缺点了，如下：优点：减轻数据库压力，理论上提供无限高读性能，引入提高业务（写）性能，专用查询，索引，全文（分词）解决方案。缺点：数据延迟，数据一致性保证。六、微服务模型上面的模型貌似不错，解决了性能问题。不能再在街上用鲁肃了，老婆还是我的，哈哈，但是软件系统先天的复杂性决定了除了性能，还有诸如高可用性等大量问题和健壮性等着我们去解决，再加上各个部门的撕逼和扯皮，让我们码农雪上加霜，那我们继续吧……微服务模型可以说是最新的热点，多姿多彩，大片大片。大大小小的国内外企业都在提倡和实践这种模式，但大多数企业并没有搞清楚自己为什么要这样做，也不知道这样做的利弊。在这里，我就用自己的亲身实践，说说我对这个模式的看法，不喜欢就不要讨厌。随着业务和人员的增多，遇到的问题如下：1、订单和数据库写请求量明显增加，导致数据库压力增大。2.一旦数据库宕机，那么整个业务就宕机了。3、业务代码越来越多，都在一个git里，越来越难维护。4.代码严重损坏，气味越来越浓。5.上线越来越频繁，往往一个小功能的修改，需要重新编译整个大项目。6、部门越来越多。大项目哪个部门改哪个东西，很撕逼。7、其他一些外围系统直接连接到数据库，导致数据库结构一旦发生变化，必须通知所有相关系统，即使是对变化不敏感的系统也必须通知。相同。9.作为一个架构师，我已经失去了对这个系统的控制……为了解决以上问题，我们公司采用了微服务模型。这个模型的总体设计如下图所示：如上图所示，我把业务分块，做垂直切分，切分成独立的系统，每个系统独立衍生，有自己的库，缓存，ES等辅助系统，系统之间的实时交互是通过RPC，异步交互是通过MQ。组合起来共同完成整个系统的功能。那么，这真的能解决上述问题吗？让我们一一谈谈。对于问题一，由于拆分成多个子系统，分散了系统的压力，每个子系统都有自己的数据库实例，所以数据库的压力变小了。问题2，子系统A的数据库宕机，只影响系统A和使用系统A的那些功能，并不是所有的功能都不可用，从而解决一个数据库宕机，所有功能不可用的问题。至于问题3和4，因为拆分了，每个子系统都有自己独立的GIT代码库，不会互相影响。公共模块可以通过库、服务、平台的形式解决。问题五，子系统A发生变化，需要上线，那么我们只需要编译A，然后上线即可，不需要其他系统做主导的事情。对于问题6，按照康威定律，我们部门应该做什么，输出什么，也会以服务的形式暴露出来。我们部门只需要做好本部门的职责和软件功能即可。对于问题7，我们部门数据的所有需求都是通过接口发布，客户通过接口获取数据，从而屏蔽了底层的数据库结构，甚至是数据源。我们部门只需要保证我们部门的接口契约没有变化即可。即为新需求增加新接口，不影响旧接口。问题八，不同的子系统需要不同的权限，这个问题也优雅的解决了。第九题，暂时控制复杂度，我只需要控制大的方面，定义系统边界、接口、大流程，然后分而治之，一一分解，纵横结合。目前，所有问题都已解决！答对了！但是，随之而来的还有很多其他的副作用，比如RPC、MQ的超高稳定性、超高性能、网络延迟、数据一致性等问题，这个就不一一说了，太多了，而且我无法在一本书中完成它。另外，对于这款车型来说，最难把握的就是速度了。切记不要分得太细。我见过一个函数一个子系统，几百个方法分到几百个子系统。实在是太多了。在实践中，一个比较可行的方法是：不能区分，除非有非常必要的理由！优点：性能比较高，扩展性强，可用性高，适合中型及以上公司架构。缺点：复杂，难以掌握。是指不仅需要一个能够高水平把控大方向、大流程、整体技术的人，还需要能够针对各个子系统进行有针对性的开发。如果不把握度或者滥用，这种模式会适得其反！7、多级缓存模式这种模式可以说是应对超高查询压力的常用策略。基本思路是所有链接都加缓存如果要加缓存，如下图：如上图，一般在三个地方加缓存，一个在客户端，一个在API网关，另一个是在具体的后端业务。下面分别介绍一下：clientCacheatthisplace：在这个地方加缓存可以说是最好的了——没有延迟。因为不需要经过很长的网络链从后端业务获取数据，导致加载时间长，客户流失等损失。虽然有CDN支持，但是从客户端到CDN还是有网络延迟的，虽然不是很大。具体技术取决于不同的客户。对于WEB，有浏览器本地缓存、Cookie、Storage、缓存策略等技术；对于APP，有本地数据库、本地文件、本地内存、进程内缓存支持，对上述各种技术感兴趣的同学可以继续学习。如果客户端缓存没有命中，那么他们就会去后端业务获取数据。一般来说，都会有一个API网关。这里添加缓存也很重要。重要的。后台业务处理：这个不用我多说。Redis、Memcache、Jvm等大家应该都知道，就不赘述了。在实践中，需要结合具体的实际情况，综合利用各级缓存技术，让各种请求在到达后端业务之前得到最大程度的解决，从而减轻后端的压力。端服务器，减少带宽使用，增强用户体验。至于是否只有这三个地方可以加缓存，我觉得还是要灵活学习和使用的。心比剑重要！总结一下这种模式的优缺点：优点：抵抗大量读请求，减轻后端压力。缺点：数据一致性问题比较突出，容易出现雪崩，即如果客户端缓存失效，API网关缓存失效，所有大量请求瞬间压到后端业务系统，而后果可想而知。8、分库分表模式该模式主要解决单表写入、读取、存储压力过大，导致业务缓慢甚至超时、事务失败、容量不足等问题。一般有水平切分和垂直切分两种。这里主要介绍水平切分。这种模式也是技术架构迭代演进的必由之路。这种模式的总体设计如下图所示：如上图红色部分所示，将一张表分成几个不同的库来分担压力。是不是很一般？哈哈，接下来详细解释一下，先明确几个概念，如下：host：硬件，指物理机，或者虚拟机，有自己的CPU，内存，硬盘等。instance：数据库实例，比如作为一个MySql服务进程，一个宿主机可以有多个实例，不同的实例有不同的进程，监听不同的端口。图书馆：指的是一张表的集合，比如学校图书馆，里面可能有教师表、学生表、食堂表等，这些表都在一个图书馆里。一个实例中可以有多个库，以库名来区分库。表：图书馆的表，不用多说，不懂就别往下看，不解释。那么如何分散单表呢？如何分配？分发到哪里？它是由于计算和存储资源不足造成的，而这些资源主要由物理机和主机提供。毕竟没有可用的计算资源，划分出来的效果也不是很好。实例：实例控制连接数，同时受OS限制，CPU、内存、硬盘、网络IO也会受到间接影响。会出现热实例现象，即：有的实例很忙，有的实例很闲。一个典型的现象是：由于单表响应慢，导致连接池爆满，影响其他业务。这时候把表分成不同的实例就有些作用了。数据库：由于单个数据库最大单表数的限制，一般采用分库。表：单表压力太大，索引量大，容量大，单表加锁。根据以上，单表横向划分为不同的表。在大型应用中，一台主机上只有一个实例，一个实例中只有一个库。library==instance==host，所以就有了分库分表的简称。既然你知道了这个基本理论，你是怎么做到的呢？逻辑如何运作？接下来，我将举例说明。这个要求很简单。用户表（user）数据量1亿，查询、插入、存储都存在问题。我应该怎么办？先分析问题，很明显是数据量大导致的。其次，设计方案可以划分为10个数据库，使每个数据库的数据量减少到1KW。单表1KW的数据量还是有点大，不利于以后体量的增长，所以每个数据库分成100张表，这样每个单表的数据量是10W，查询、索引更新、单表文件大小、打开速度都有些溢出。接下来打电话给IT部门，要10台物理机来扩充数据库……最后是逻辑实现，这应该是最有学问的地方了。首先是写入数据。你需要知道写入哪个分库分表。阅读也是如此。因此，需要有一个请求路由器，负责将请求分发和转换到不同的数据库表中。一般有路由规则的概念。.怎么样，容易吗？哈哈。再说说这个模型的问题，主要是因为交易的问题。因为分库分表，无法完成事务，分布式事务过于繁琐，所以这里需要有一定的策略来保证这种情况下的事务。能够完成。采用的策略如：最终一致性、复制、特殊设计等。然后是业务代码的改造，一些关联查询需要改造，一些单表orderBy问题需要特殊处理，包括groupBy语句。如何解决这些副作用，不是一两句话能说清楚的。以后有空再单独说。这些。是时候总结一下这种模式的优缺点了，如下：优点：减轻数据库中单表的压力。缺点：事务保障困难，业务逻辑需要大量修改。9.ElasticSc??alingMode该模式主要解决突发流量的到来导致无法横向扩展或者横向扩展太慢进而影响业务，导致整个站点崩溃的问题。这种模式是比较先进的技术，也是目前各大公司正在研究和试用的技术。发展到今天，有这种思维的架构师已经很优秀了，可以获得更高的薪水，更何况是那些已经实践甚至实现了底层系统的人，所以，你懂的……这个模型的基础总体设计如下：如上图所示，增加一个弹性伸缩服务，动态增减实例。原理很简单，但是这个模型解决了什么问题呢？先说起源和意义吧。在每年的双11、618或者一些大促之前，我们会针对大流量的到来做如下工作：提前准备10倍以上的机器，即使不用也留在那里。以防万一，这样会浪费很多资源。每台机器都配置、调试、放线，让所有机器都可用，浪费大量的人力物力，也更容易出错。如果机器没有准备好，那你就得加班加点，重复上面的工作，特别容易出错，导致领导不满，你就没时间回家陪老婆，然后你老婆就...哈哈双十一过后，我们还有手动缩小音量还是很辛苦的。一般一年会有很多促销活动，所以我们总是这样，真的很烦人！最严重的，突然爆发的大流量会让我们措手不及，半夜起来扩容很正常。为此，我们如果偷懒，需要更多的机器，就会出现大量CPU使用率为1%的机器。相信我，如果你是老板，你一定被震撼了！哈哈，如何改变这种情况呢？请继续阅读。为此，首先将所有的计算资源整合到资源池的概念中，然后通过一些策略、监控、服务，动态地从资源池中获取资源，使用后放回池中，供其他系统使用。实现上比较成熟的两个资源池解决方案是VM和docker，各自都有自己强大的生态。监控点包括CPU、内存、硬盘、网络IO、服务质量等，基于这些，结合一些预留、扩容、缩容策略，可以简单的实现自动缩容。如何？是不是很神奇？深入的内容我会在后面的文章中详细介绍，是时候总结一下这种模式的优缺点了。具体如下：优点：弹性大，按需计算，充分优化企业计算资源。缺点：应用需要从架构层横向扩展，依赖大量的底层配套，对技术水平、实力、应用规模要求比较高。10、多机房模式该模式主要解决不同地域的高性能和高可用问题。随着应用用户的不断增加，用户群体分布在世界各地。如果服务器部署在一个地方，比如北京，那么美国的用户在使用应用的时候会很慢，因为每次请求都需要经过海底光缆大约一秒左右，这对用户来说是极其不利的。用户体检。我应该怎么办？使用多房间部署。这种模式一般设计如下图所示：如上图所示，一个典型的用户请求流程如下：用户请求连接A通过DNS智能解析到离用户最近的机房B，使用B的机房服务连接A，是不是觉得很简单？，没有什么？其实这里的问题并不像表面上那么简单。让我们一一看看。首先是数据同步问题。中国产生的数据必须同步到美国，美国也是如此。数据同步会涉及到数据版本、一致性、兼容性、更新丢弃、删除等问题。二是一个地方多个机房的请求路由问题。通常，如上图所示，中国的北京机房和杭州机房，如果北京机房宕机，那么所有发送到北京机房的请求，都必须通过路由转发到杭州机房。也有这个问题。所以，多机房模式，也就是异地多活动，就没有那么简单了。这只是一个开始。具体的陷阱会在后面的文章中介绍。是时候总结一下这个模型的优缺点了，如下：优点：高可用、高性能、异地多活动。缺点：数据同步、数据一致性、请求路由。
