六种常见系统架构 —— 进阶篇.docxVIP

六种常见系统架构 —— 进阶篇 2021-10-14 更多内容关注：fullstack888 常见的几种系统架构设计，接下来讲后面三个： 1、单库单应用架构：最简约的，可能大家都见过 2、内容分发架构：目前用的比较多 3、读写分别架构：对于大并发的查询、业务 4、微服务架构：适用于简单的业务模式的拆解 5、多级缓存架构：可以把缓存玩的很好 6、分库分表架构：处理单体数据库瓶颈 四、微服务架构 上面的模式看似不错，处理了功能问题，我可以不用鲁肃街头了、老婆还是我的，哈哈，但是软件系统天生的简单性打算了，除了功能，还有其他诸如高可用、健壮性等大量问题等待我们去处理，在加上各个部门的撕逼、扯皮，更让我们码农雪上加霜，所以，连续吧…… 微服务模式可以说是最近的热点，花花绿绿、大大小小、国内国外的公司都在鼓吹，实践这个模式，可是大部分都没有弄清为什么要这么做，也并不晓得这么做有什么好处、坏处，在这里，我将以我本人的亲身实践说一下我对这个模式的看法，不喜勿喷，随着业务与人员的添加，遇到的问题如下： 1、单体数据库写恳求量大量添加，导致数据库压力变大 2、数据库一旦挂了，那么整个业务都挂了 3、业务代码越来越多，都在一个GIT里，越来越难以维护 4、代码腐化严峻，臭味越来越浓 5、上线越来越频繁，经常是一个小功能的修改，就要整个大项目重新编译 6、部门越来越多，该哪个部门改动大项目中的哪个东西，撕逼的厉害 7、其他一些外围系统直接连数据库，导致一旦数据库结构发生变化，全部的相关系统都要通知，甚至对修改不敏感的系统也要通知 8、每个应用服务器需要开通全部权限、网络、FTP、各种各样的，由于每个服务器部署的应用都是一样的。 9、作为架构师，我已经得到了对这个系统的把控…… 为了处理上述问题，我司使用了微服务模式，这种模式的一般设计如下图： 如上图所示，我把业务分块，做了垂直切分，切成一个个独立的系统，每个系统各自衍化，有本人的库、缓存、ES等协助系统，系统之间的实时交互通过RPC，异步交互通过MQ，通过这种组合，共同完成整个系统功能。 那么，这么做能否真的能处理上述问题了呢？不玩虚的，一个一个来说。 对于问题一，由于拆分成多个子系统，系统的压力被分散了，而各个子系统都有本人的数据库实例，所以数据库的压力变小。 对于问题二，一个子系统A的数据库挂了，只是影响到系统A和使用系统A的那些功能，不会全部的功能不行用，从而处理一个数据库挂了，导致全部的功能都不行用的情况。 对于问题三、四，也由于拆分得到了处理，各个子系统都有本人独立的GIT代码库，不会相互影响。通用的模块可通过库、服务、平台的方式处理。 对于问题五，子系统A发生转变，需要上线，那么我们只需要编译A，然后上线就可以了，不需要其他系统做通向的事情。 对于问题六，顺应了康威定律，我部门该干什么事，输出什么，也通过服务的方式暴显露来，我部门尽管把我部的职责、软件功能做好就可以。 对于问题七，全部需要我部数据的需求，都通过接口的方式发不出去，客户通过接口猎取数据，从而屏蔽了底层数据库结构，甚至数据来源，我部只需保证我部的接口契约没有发生变化即可，新的需求添加新的接口，不会影响老的接口。 对于问题八，不同的子系统需要不同的权限，这个问题也优雅的处理了。 对于问题九，临时把握住简单性，我只需要把握好大方面，定义好系统边界、接口、大的流程，然后再分而治之、逐一击破、合纵连横。 目前来说，全部问题得到处理！bingo！ 但是，还有很多其他的副作用会随之产生，如RPC、MQ的超高稳定性、超高功能，网络延迟，数据全都性等问题，这个就不开放来讲了，太多了，一本书都讲不完。 另外，对于这个模式来说，最难把握的是度，切记不要切分过细，我见过一个功能一个子系统，上百个方法分成上百个子系统的，真的是太过度了。实践中，一个比较可行的方法是：能不分就不分，除非有格外必要的理由！ 优点：相对高功能，可扩展性强，高可用，适用于中等以上规模公司架构。 缺点：简单度不好把握。指不只需要一个能在高层把控大方向、大流程、总体技术的人，还需要能够针对各个子系统有针对性的开发。把握不好度或者滥用的话，这个模式适得其反！ 五、多级缓存架构 这个模式可以说是应对超高查询压力的一种普遍接受的策略，基本的思想就是在全部链路的地方，能加缓存的就加缓存，如下图所示： 如上图所示，一般在三个地方加入缓存，一个是客户端处，一个是API网关处，一个是具体的后端业务处，下面分别引见： 客户端处缓存：这个地方加缓存可以说是效果最好的一个——无延迟。由于不用经过长长的网络链条去后端业务处猎取数据，从而导致加载时间过长，客户流失等损失，虽然有CDN的支持，但是从客户端到CDN还是有网络延迟的，虽然不大，具体的技术依据不同的客户端而定，对于WEB来讲，